解决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
# JIT 参数
# 设置用于编译的编译器线程数
-XX:CICompilerCount=2
# 开启分层编译
-XX:TieredStopAtLevel=1
# 控制最大数量嵌套调用内联
-XX:MaxInlineLevel=3
-XX:Tier4MinInvocationThreshold=100000
-XX:Tier4InvocationThreshold=110000
-XX:Tier4CompileThreshold=120000
如果以上操作还是不能解决CPU过高的话，还可以打开
1、打开idea设置 File–>Settings–> Build,Execution,Deployment --> Compiler
2、调整 Shared build process heap size(Mbytes) 大小，默认值700，可修改至 1024（或者自定义数值）
至于网上还有提出的插件，或者代码检查我们也可以去尝试一下，通过修改里面的配置结合idea自带的监控来快速准确定位问题，但是也告诉我们，要对症下药，有自带的工具去帮你，何乐而不为呢？