IDEA是好东西，可以说是地球上最好的Java开发工具，但偶尔也会卡顿。 仔细想想，IDEA也是Java开发的，不是和GC有关吗？ 因此，接下来有时会调谐IDEA的GC。
IDEA的默认JVM参数：
-Xms128m
-Xmx750m
-XX:MaxPermSize=350m
- xx : reservedcodecachesize=240 m
-XX: UseConcMarkSweepGC
- xx : softreflrupolicymspermb=50
首次优化
使用默认参数启动完成后，在jstat -gcutil pid 3s中检查GC状况：
Paste_Image.png
图中反映了一个Old区域扩大的非常明显的问题。 这是因为Xms和Xmx的值不一致； 因此，JVM参数的第一个优化点是Xms和Xmx；
第一次优化后的JVM参数如下：
-Xms1024m
-Xmx1024m
-Xmn372m
-XX:MaxPermSize=350m
- xx : reservedcodecachesize=240 m
-XX: UseConcMarkSweepGC
- xx : softreflrupolicymspermb=50
第二次优化
第一次优化后，重新启动IDEA以获取类似于以下内容的GC日志：
Paste_Image.png
因为Metaspace显然会扩大，所以第二个优化点是-XX:MetaspaceSize和-XX:MaxMetaspaceSize
第二次优化后的JVM参数如下：
-Xms1024m
-Xmx1024m
-Xmn372m
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=512m
- xx : reservedcodecachesize=240 m
-XX: UseConcMarkSweepGC
- xx : softreflrupolicymspermb=50
说明：因为我使用的是JDK8，所以删除参数-XX:MaxPermSize=350m，改为-XX:MetaspaceSize=256m和-XX:MaxMetaspaceSize=512m 读者们
总结
经过第二次优化，启动IDEA的GC的情况如下。
Paste_Image.png
图显示，GC情况较健康，无FGC，GCT明显下降。 唯一的缺点是YGC的平均时间太长。 这是因为我的电脑结构低，CPU是双核的。 在典型的生产Linux服务器上，YGC的时间为几十毫秒，如果超过100ms，则需要检查有无问题。
最后写
添加一些经验性参数后，最终的JVM参数如下所示。
-Xms1024m
-Xmx1024m
-Xmn372m
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=512m
- xx : reservedcodecachesize=240 m
-XX: UseConcMarkSweepGC
- xx :用户parnewgc
- xx : cmsparallelremarkenabled
- xx : cmsscavengebeforeremark
- xx : cmsinitiatingoccupancyfraction=75
- xx : usecmsinitiatingoccupancyonly
- xx : usecmscompactatfullcollection
- xx : cmsfullgcsbeforecompaction=3
- xx : softreflrupolicymspermb=50
说明：
- xx : useparnewgc :可以声明也可以不显示young区的垃圾回收算法。 (为了便于理解JVM参数而显示宣言)，因为如果Old喜欢的溪流是CMS GC，则young区的默认值为parnew )；
- xx : cmsparallelremarkenabled:CMS的重新标记阶段多线程并行处理； 默认情况下，此参数为true，因此在此仅显示声明；
- xx : cmsscavengebeforeremark :在cmsgc之前运行一次Minor GC，即YGC；
- xx : cmsinitiatingoccupancyfraction=75 :如果old区域声明为CMS GC，则此参数的默认值为92，相对较大，小于75，表示升级故障概率
- xx : usecmsinitiatingoccupancyonly :只有当old区域达到75%时才会触发CMS GC。 如果不声明，CMS GC还有很多其他条件可以触发；
- xx : usecmscompactatfullcollection:CMS是一种标签清理算法，每次重用时都存在内存碎片问题，此参数组织内存碎片，但在暂停时间
- xx : cmsfullgcsbeforecompaction=3:指示通过foregroundcmsgc多少次后压缩Old区域一次。 由于名为UseCMSCompactAtFullCollection的参数进行true内存碎片整理会影响性能，因此碎片整理问题也需要得到解决或缓解。 因此，设定适当调整该参数的值，在执行多次前端CMS GC之后压缩Old区域；
最后写。 常见的CMS GC是Backgroud CMS GC，它经历了五个常见的：初始化标记-并行标记-重新标记-并行清理-并行重置。 foreground CMS GC启动后，停止所有java线程，同时退出Backgroud CMS GC，串行回收Old区域的垃圾，对系统的吞吐量和性能有非常大的影响；
作者：紧张的鸡翅博客
资料来源： https://www.Jian Shu.com/p/ba 2d 613 df 94 f
正文版权归作者所有。 转载时，请注明出处
转载注意：转载自《Java极客技术学习》https://www.javajike.com