记一次IDEA的优化

首先放一下博主的电脑性能，博主的电脑性能不能说勉强够用，简直是能打能抗，但跑一个小小的idea竟然经常会出现卡顿！我不能忍，于是就想着着手研究一下idea的优化，就有了这篇博客

---

不认真的搜索

随便搜索了一下，大概说的就是 调大堆内存啊，之类的。然后我就随便把 最大堆和最小堆变成了 4g。

-Xms4g
-Xmx4g

好吧，看到这里如果你对JVM有一些了解你就会知道，堆越大单次GC时间越长。随意我这个"优化"其实是反作用，优化了个寂寞。于是我打开了arthas准备好好看看。

首先是IDEA和用户JVM参数

-Xms4g
-Xmx4g
-XX:ReservedCodeCacheSize=256m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-XX:CICompilerCount=2
-Dsun.io.useCanonPrefixCache=false
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow

稍微动了点脑子

似乎也看不出什么 都是蛮正常的一个操作。
接下来是arthas的面板

一共6次老年代GC 竟然就用了24秒 CMS平均耗时4秒？ 这是CMS吗还？ 说好的优先减少停顿时间呢？我理解为我的堆太大了，然后我又设置了一个参数

-XX:CMSInitiatingOccupancyFraction=95

意味着当老年代占用95%以上时 才会触发FullGc (因为我的堆比较大，我觉得很少会真正的触发一次)

结果是 仍然没解决

IDEA有没有官方推荐的策略呢？

---

于是就搜到了上面这个结果。。 推荐JDK是11。
然后我又用JDK11 跑了一会IDEA,又打开了 arthas

似乎没什么问题？ 成功了？？
然而跑了一会，发现：

好吧真的没什么变化

在我盯着这个结果图陷入沉思的时候。 突然想到 jdk11默认的gc不是g1吗？？？ 为什么我换了JDK 仍然是CMS + Parallel new 的组合？
让我看到了罪魁祸首

-XX:+UseConcMarkSweepGC

好吧 果断注释掉，使用 G1当垃圾收集器

搭配上一个200ms的期待停顿时间

跑了一段时间，美滋滋。

可以舒服的写代码了。。。。

---

总结

• 尽量使用JDK11环境跑IDEA
• IDEA默认JVM参数使用CMS作为垃圾回收器！ 是大坑
• G1GC 可以设置期望的STW时间，我们作为IDEA的用户，期待的是低延迟。 可以凭自己感觉优化期望时间