34 | JVM GC原理及调优的基本思路
李号双
该思维导图由 AI 生成，仅供参考
和 Web 应用程序一样，Tomcat 作为一个 Java 程序也跑在 JVM 中，因此如果我们要对 Tomcat 进行调优，需要先了解 JVM 调优的原理。而对于 JVM 调优来说，主要是 JVM 垃圾收集的优化，一般来说是因为有问题才需要优化，所以对于 JVM GC 来说，如果你观察到 Tomcat 进程的 CPU 使用率比较高，并且在 GC 日志中发现 GC 次数比较频繁、GC 停顿时间长，这表明你需要对 GC 进行优化了。
在对 GC 调优的过程中，我们不仅需要知道 GC 的原理，更重要的是要熟练使用各种监控和分析工具，具备 GC 调优的实战能力。CMS 和 G1 是时下使用率比较高的两款垃圾收集器，从 Java 9 开始，采用 G1 作为默认垃圾收集器，而 G1 的目标也是逐步取代 CMS。所以今天我们先来简单回顾一下两种垃圾收集器 CMS 和 G1 的区别，接着通过一个例子帮你提高 GC 调优的实战能力。
CMS vs G1
CMS 收集器将 Java 堆分为年轻代（Young）或年老代（Old）。这主要是因为有研究表明，超过 90％的对象在第一次 GC 时就被回收掉，但是少数对象往往会存活较长的时间。
CMS 还将年轻代内存空间分为幸存者空间（Survivor）和伊甸园空间（Eden）。新的对象始终在 Eden 空间上创建。一旦一个对象在一次垃圾收集后还幸存，就会被移动到幸存者空间。当一个对象在多次垃圾收集之后还存活时，它会移动到年老代。这样做的目的是在年轻代和年老代采用不同的收集算法，以达到较高的收集效率，比如在年轻代采用复制 - 整理算法，在年老代采用标记 - 清理算法。因此 CMS 将 Java 堆分成如下区域：
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
JVM垃圾收集（GC）原理及调优是优化Java应用性能的关键。本文首先介绍了CMS和G1两种垃圾收集器的设计思路和区别，以及GC调优的总体原则。针对CMS收集器，重点在于合理设置年轻代和年老代的大小，而对于G1收集器，则建议适当调大Java堆。通过实例演示了Java堆设置过小导致频繁GC的问题，并提出了相应的解决方案。总的来说，本文强调了GC调优的重要性，以及针对不同垃圾收集器的调优策略。读者在课后思考时应注意，如果将年轻代和年老代都设置得很大，可能会引发一些问题。这篇文章对于读者快速了解JVM GC原理及调优提供了重要的技术特点和指导。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《深入拆解 Tomcat & Jetty 》，新⼈⾸单¥68
《深入拆解 Tomcat & Jetty 》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(24)
- 最新
- 精选
新世界设置过大，回收频率会降低，导致单次回收时间过长，因为需要回收的对象更多，导致GC stop the world时间过长，卡顿明显，导致请求无法及时处理作者回复: 对的，主要是会引起gc停顿时间过长
2019-07-30329
-W.LI-李老师好!感觉老师今天偷懒了，CMS负责老年代回收，年轻代一般配合parNew使用。 大概啥情况下使用G1比较好啊?之前看见网上说，大堆多核，jdk9以及以上可以使用G1，jdk8的话除非cms满足不了需求不然不建议使用G1。 G1不太了解老师能推荐下资料么? 我觉得工具，可以提高效率，初学者优先搞清楚原理扎实基础比较好。作者回复: g1实现很复杂，有人专门写了本书来讲，原理入门可以看看这篇文章：https://yq.aliyun.com/articles/444436
2019-07-30514- 弃老师，我想问个问题:在docker中运行的springboot(使用默认的tomcat容器)，如何查看tomcat的gc日志?
作者回复: 可以登到容器内去看，不过一般会把容器的日志目录mount到主机的某个目录
2019-07-302 
本杰明执行命令：java -Xmx2048m -Xss256k -verbosegc -Xlog:gc*,gc+ref=debug,gc+heap=debug,gc+age=trace:file=gc-%p-%t.log:tags,uptime,time,level:filecount=2,filesize=100m -jar target/demo-0.0.1-SNAPSHOT.jar java -Xmx2048m -Xss256k -verbosegc -Xlog:gc*,gc+ref=debug,gc+heap=debug,gc+age=trace:file=gc-%p-%t.log:tags,uptime,time,level:filecount=2,filesize=100m -jar target/demo-0.0.1-SNAPSHOT.jar 报错： Unrecognized option: -Xlog:gc*,gc+ref=debug,gc+heap=debug,gc+age=trace:file=gc-%p-%t.log:tags,uptime,time,level:filecount=2,filesize=100m作者回复: 要采用最新jvm版本12
2019-08-0121
锦对于CMS来说，设置很大的堆内存，在导致单次STW时间长，会导致服务不可用，定时器出问题？对响应敏感的系统来说不太友好，但堆内存设置太小又会导致频道GC，所以需要综合评估。那么如何使用超大机器内存呢？可以使用集群方式部署，单个应用设置较小的堆内存。 对于G1来说，文中有提到可以设置较大内存，因为G1是局部收集，但极端情况下，区域之间的对象引用关系非常多，也会导致大面积回收，STW时间会较长。 目前Java8使用CMS的较多，那么G1普及可能还需要时间吗？作者回复: 随着java9 普及开，就默认用g1了
2019-07-303- -W.LI-年轻代设置过大: 1.生命周期长的对象会长时间停留在年轻代，在S0和S1来回复制，增加复制开销。 2.年轻代太大会增加YGC每次停顿的时间，不过通过根节点遍历，OopMap，old scan等优化手段这一部分的开销其实比较少。 3.浪费内存。内存也是钱啊虽然现在租的很便宜 老年代设置过大: 1.降低FGC频率，有些堆外内存比如直接内存，需要靠FGC辅佐回收的，就会无法释放。万一剩余的堆外内存不够程序也会宕机的吧 2.单次FGC时间变长，如果在夜深人静的时候主动触发FGC内啥影响，如果白天业务繁忙的时候就凉凉 3.增加YGC的时间，old scan阶段会扫描老年代，而且这个阶段耗时在YGC总比重很大。 最好别让太多老年代对象引用年轻代对象，这个坑很痛。2019-07-3045
业余草需要实际操作一遍，光看是记不住的，过一段时间就忘记了。2019-07-306
nightmare分情况，如果是G1大年轻代和大老年代没什么问题 如果是cms parnew的话 也需要看情况 如果你的并发比较大并且很快占满eden区 或者 用jstat监控 supervisor区占比一直高于百分之70这个时候 这个时候加大新生代就没有什么问题 如果要很久才占满eden区 或者supervisor区占比比较小 这个时候就要把 新生代 设置小一点 减少新生代回收时间 老年代也要看年轻代晋升到老年代平均占多大 如果晋升很快并且对象占比较大 大一点没问题 否则就需要减少老年代2019-07-304
QQ怪设置过大回收频率降低，单次回收的对象量大，回收stw时间过长，设置大也不好，过小也不好，设置适合的才是最好的2019-07-303
James一句话：纸上谈兵终觉浅 绝知此事要躬行2021-03-271
收起评论
