idea启动后CPU飙升的问题解决

解决idea 启动后CPU飙升的问题

CPU飙升是因为idea产生了某种疯狂消耗CPU资源，可以通过idea自带的监控来来观察到底是什么进程占用了CPU的资源

其实网上大部分讲的都是因为JIT（just in time,即时编译技术）导致CPU飙升，但是经过我的检测发现，JIT也仅仅是我的idea卡顿的一部分原因。

配置前：

配置后：

可以观测到idea CPU还是会飙升，但是JIT所占用的CPU大幅度下降，说明还是很有效果的。

# JIT 参数

# 设置用于编译的编译器线程数
-XX:CICompilerCount=2
# 开启分层编译
-XX:TieredStopAtLevel=1
# 控制最大数量嵌套调用内联
-XX:MaxInlineLevel=3
-XX:Tier4MinInvocationThreshold=100000
-XX:Tier4InvocationThreshold=110000
-XX:Tier4CompileThreshold=120000

后续又发现是因为不断地在进行GC导致CPU飙升，因为每次GC都会消耗99%的CPU资源，于是想着修改JVM参数来解决这个问题。

因为我的idea是新装的，他的堆大小参数为：

-Xms128m
-Xmx2048m

然后查阅资料得知，当Xms设置值比较小时，会频繁的触发GC，而GC又会出现STW的情况，所以idea一直GC，那你的idea也必然是一卡一卡的，同时大部分都推荐相同值，这是为什么呢？

这是为了避免在由于heap内存扩大或缩小导致应用停顿，降低延迟，同时避免每次垃圾回收完成后JVM 重新分配内存。

所以修改后的堆的大小为：

-Xms2048m
-Xmx2048m

然后又发现自己的GC收集器使用的是CMS，那么读过JVM这本书的都知道，CMS采用标记-清理的算法，标记出垃圾对象，清除垃圾对象。算法是基于老年代执行的，因为新生代产生无法接受该算法产生的碎片垃圾。他的缺点是：

无法清理浮动垃圾，并发收集会造成内存碎片过多
由于并发标记和并发清理阶段都是并发执行，所以会额外消耗CPU资源

基于此，我将垃圾收集器也替换为了G1，G1的优势是：

可控制回收垃圾的时间
和CMS一样采用标记-清理的算法，但是G1不会产生空间碎片（G1从整体来讲是基于标记-整理来实现垃圾回收从局部来讲，又是把整个堆，切割为大小均匀的多个region，region与region之间采用标记-复制算法实现），这样就有效的使用了连续空间，不会导致连续空间不足提前造成GC的触发。

最后贴出完整的JVM参数：

-server
-XX:MetaspaceSize=128M
-XX:MaxMetaspaceSize=512M
-XX:+AlwaysPreTouch
-Xms2048m
-Xmx2048m
-XX:ReservedCodeCacheSize=512m
-XX:+UseG1GC
-XX:+UseStringDeduplication
-XX:AutoBoxCacheMax=20000
-ea
-Dsun.io.useCanonCaches=false
-Dsun.awt.keepWorkingSetOnMinimize=true
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=\”\”
-Djsse.enablesSNIExtension=false
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-Dfile.encoding=UTF-8