文章目录
-
- [🍊 JVM调优](#🍊 JVM调优)
-
- [🎉 增大Eden 空间大小](#🎉 增大Eden 空间大小)
- [🎉 如果MinorGC 频繁，且容易引发 Full GC](#🎉 如果MinorGC 频繁，且容易引发 Full GC)
-
- [📝 S1 区大小 < MGC 存活的对象大小，对象的年龄才1岁](#📝 S1 区大小 < MGC 存活的对象大小，对象的年龄才1岁)
- [📝 相同年龄的对象所占总空间大小>s1区空间大小的一半](#📝 相同年龄的对象所占总空间大小>s1区空间大小的一半)
- [📝 解决方案](#📝 解决方案)
-
- [🔥 调整年龄阈值](#🔥 调整年龄阈值)
- [🔥 增加S区的大小](#🔥 增加S区的大小)
- [🔥 改变对象分配的位置](#🔥 改变对象分配的位置)
- [🎉 大对象创建频繁](#🎉 大对象创建频繁)
-
- [📝 代码层面无法优化](#📝 代码层面无法优化)
-
- [🔥 调高-XX： PretenureSizeThreshold参数的大小](#🔥 调高-XX： PretenureSizeThreshold参数的大小)
- [🔥 大对象必须进入老年代](#🔥 大对象必须进入老年代)
- [🎉 MGC 与 FGC 停顿时间长](#🎉 MGC 与 FGC 停顿时间长)
-
- [📝 gc 真实回收过程时间长](#📝 gc 真实回收过程时间长)
- [📝 gc真实回收时间 real time 并不长](#📝 gc真实回收时间 real time 并不长)
- [🎉 内存泄漏导致的MGC和FGC频繁，最终引发oom](#🎉 内存泄漏导致的MGC和FGC频繁，最终引发oom)
- [🎉 JVM调优步骤](#🎉 JVM调优步骤)
-
- [📝 1. 收集数据](#📝 1. 收集数据)
- [📝 2. 分析数据](#📝 2. 分析数据)
- [📝 3. 制定优化方案](#📝 3. 制定优化方案)
- [📝 4. 验证优化效果](#📝 4. 验证优化效果)
- [📝 5. 持续监控](#📝 5. 持续监控)
📕我是廖志伟，一名Java开发工程师、Java领域优质创作者、CSDN博客专家、51CTO专家博主、阿里云专家博主、清华大学出版社签约作者、产品软文创造者、技术文章评审老师、问卷调查设计师、个人社区创始人、开源项目贡献者。🌎跑过十五公里、徒步爬过衡山、🔥有过三个月减肥20斤的经历、是个喜欢躺平的狠人。
📘拥有多年一线研发和团队管理经验，研究过主流框架的底层源码(Spring、SpringBoot、Spring MVC、SpringCould、Mybatis、Dubbo、Zookeeper)，消息中间件底层架构原理(RabbitMQ、RockerMQ、Kafka)、Redis缓存、MySQL关系型数据库、 ElasticSearch全文搜索、MongoDB非关系型数据库、Apache ShardingSphere分库分表读写分离、设计模式、领域驱动DDD、Kubernetes容器编排等。🎥有从0到1的高并发项目经验，利用弹性伸缩、负载均衡、报警任务、自启动脚本，最高压测过200台机器，有着丰富的项目调优经验。
📙经过多年在CSDN创作上千篇文章的经验积累，我已经拥有了不错的写作技巧。同时，我还与清华大学出版社签下了四本书籍的合约，并将陆续在明年出版。这些书籍包括了基础篇、进阶篇、架构篇的📌《Java项目实战---深入理解大型互联网企业通用技术》📌，以及📚《解密程序员的思维密码--沟通、演讲、思考的实践》📚。具体出版计划会根据实际情况进行调整，希望各位读者朋友能够多多支持！
希望各位读者大大多多支持用心写文章的博主，现在时代变了，信息爆炸，酒香也怕巷子深，博主真的需要大家的帮助才能在这片海洋中继续发光发热，所以，赶紧动动你的小手，点波关注❤️，点波赞👍，点波收藏⭐，甚至点波评论✍️，都是对博主最好的支持和鼓励！
💡在这个美好的时刻，本人不再啰嗦废话，现在毫不拖延地进入文章所要讨论的主题。接下来，我将为大家呈现正文内容。
🍊 JVM调优
JVM调优情况十分复杂，各种情况都可能导致垃圾回收不能够达到预想的效果。对于场景问题，可以从如下几个大方向进行设计：
🎉 增大Eden 空间大小
大访问压力下，MGC 频繁一些是正常的，只要MGC 延迟不导致停顿时间过长或者引发FGC ，那可以适当的增大Eden 空间大小，降低频繁程度，同时要保证，空间增大对垃圾回收产生的停顿时间增长是可以接受的。
🎉 如果MinorGC 频繁，且容易引发 Full GC
需要从如下几个角度进行分析。
📝 S1 区大小 < MGC 存活的对象大小，对象的年龄才1岁
每次MGC存活的对象的大小，是否能够全部移动到 S1区，如果S1 区大小 < MGC 存活的对象大小，这批对象会直接进入老年代。注意 了，这批对象的年龄才1岁，很有可能再多等1次MGC 就能被回收了，可是却进入了老年代，只能等到Full GC 进行回收，很可怕。这种情况下，应该在系统压测的情况下，实时监控MGC存活的对象大小，并合理调整eden和s 区的大小以及比例。
📝 相同年龄的对象所占总空间大小>s1区空间大小的一半
还有一种情况会导致对象在未达到15岁之前，直接进入老年代，就是S1区的对象，相同年龄的对象所占总空间大小>s1区空间大小的一半，所以为了应对这种情况，对于S区的大小的调整就要考虑：尽量保证峰值状态下，S1区的对象所占空间能够在MGC的过程中，相同对象年龄所占空间不大于S1区空间的一半， 因此对于S1空间大小的调整，也是十分重要的。
📝 解决方案
🔥 调整年龄阈值
可以通过设置 JVM 参数"-XX:MaxTenuringThreshold"来调整年龄阈值。该参数指定对象晋升老年代的最大年龄，通常默认值为15岁。可以逐渐增加该值，以减少老年代中相同年龄对象的数量。
请注意，调整年龄阈值需要根据具体应用程序的情况来确定。如果将年龄阈值设置得太高，可能会导致年轻代中的对象数量过多，从而增加Young GC的频率，进而影响系统性能。
🔥 增加S区的大小
如果S区足够大，那么S1区所占的比例就会更小。这样可以降低相同年龄段对象的总空间大小，从而使其不大于S1区的一半。
🔥 改变对象分配的位置
- 设置对象的大小阈值。通过调整对象分配的大小阈值，可以让 JVM 将较大的对象分配到老年代中，减少新生代中对象数量，从而减少垃圾回收的频率。可以通过 -XX:PretenureSizeThreshold 参数来设置对象的大小阈值。
- 调节新生代大小。通过调整新生代的大小，可以增加对象在新生代中的寿命，从而让更多的对象进入老年代，减少在新生代中对象的数量。可以通过调整 -Xmn 参数来设置新生代的大小。
- 调节垃圾回收器参数。不同的垃圾回收器有不同的参数，可以根据具体的情况调节垃圾回收器的参数，以达到更好的效果。比如使用 G1 垃圾回收器，可以通过调节 -XX:G1HeapRegionSize 参数来控制 region 的大小，从而控制对象在不同 region 中的分配情况。
🎉 大对象创建频繁
由于大对象创建频繁，导致Full GC 频繁。对于大对象，JVM专门有参数进行控制，-XX： PretenureSizeThreshold。超过这个参数值的对象，会直接进入老年代，只能等到full GC 进行回收，所以在系统压测过程中，要重点监测大对象的产生。如果能够优化对象大小，则进行代码层面的优化，优化如：根据业务需求看是否可以将该大对象设置为单例模式下的对象，或者该大对象是否可以进行拆分使用，或者如果大对象确定使用完成后，将该对象赋值为null，方便垃圾回收。
📝 代码层面无法优化
如果代码层面无法优化，则需要考虑：
🔥 调高-XX： PretenureSizeThreshold参数的大小
调高-XX： PretenureSizeThreshold参数的大小，使对象有机会在eden区创建，有机会经历MGC以被回收。但是这个参数的调整要结合MGC过程中Eden区的大小是否能够承载，包括S1区的大小承载问题。
🔥 大对象必须进入老年代
这是最不希望发生的情况， 如果必须要进入老年代，也要尽量保证，该对象确实是长时间使用的对象，放入老年代的总对象创建量不会造成老年代的内存空间迅速长满发生Full GC，在这种情况下，可以通过定时脚本，在业务系统不繁忙情况下，主动触发full gc。
🎉 MGC 与 FGC 停顿时间长
MGC 与 FGC 停顿时间长导致影响用户体验。其实对于停顿时间长的问题无非就两种情况：
📝 gc 真实回收过程时间长
gc 真实回收过程时间长，即real time时间长。这种时间长大部分是因为内存过大导致，从标记到清理的过程中需要对很大的空间进行操作，导致停顿时间长。这种情况，要考虑减少堆内存大 小，包括新生代和老年代，比如之前使用16G的堆内存，可以考虑将16G 内存拆分为4个4G的内存区域，可以单台机器部署JVM逻辑集群，也可以为了降低GC回收时间，进行4节点的分布式部署，这里的分布式部署是为了降低 GC垃圾回收时间。
📝 gc真实回收时间 real time 并不长
gc真实回收时间 real time 并不长，但是user time(用户态执行时间) 和 sys time（核心态执行时间）时间长，导致从客户角度来看，停顿时间过长。这种情况，要考虑线程是否及时达到了安全点，通过-XX：+PrintSafepointStatistics和-XX： PrintSafepointStatisticsCount=1去查看安全点日志，如果有长时间未达到安全点的线程，再通过参数-XX： +SafepointTimeout和-XX：SafepointTimeoutDelay=2000两个参数来找到大于2000ms到达安全点的线程，这里 的2000ms可以根据情况自己设置，然后对代码进行针对的调整。除了安全点问题，也有可能是操作系统本身负载比较高，导致处理速度过慢，线程达到安全点时间长，因此需要同时检测操作系统自身的运行情况。
🎉 内存泄漏导致的MGC和FGC频繁，最终引发oom
纯代码级别导致的MGC和FGC频繁。如果是这种情况，那就只能对代码进行大范围的调整，这种情况就非常多了，而且会很糟糕。如大循环体中的new 对象，未使用合理容器进行对象托管导致对象创建频繁，不合理的数据结构使用等等。 总之，JVM的调优无非就一个目的，在系统可接受的情况下达到一个合理的MGC和FGC的频率以及可接受的回收时间。
🎉 JVM调优步骤
📝 1. 收集数据
使用命令或GUI工具收集JVM内存和处理器使用信息，并生成堆转储快照。
📝 2. 分析数据
使用工具分析收集到的数据，计算GC吞吐量和新生代大小等，分析堆中对象的分布情况，查看是否有内存泄漏等问题。
📝 3. 制定优化方案
根据分析的数据确定具体的优化方案，比如调整内存大小、垃圾回收机制、优化代码等。尝试调整GC算法、分配大对象空间、增加GC并行度等进行GC调优，尝试减少对象的创建、复用对象等进行内存调优。
📝 4. 验证优化效果
使用性能测试工具进行压力测试，验证优化效果是否符合预期。
📝 5. 持续监控
持续监控应用程序，及时发现并解决新问题，进行JVM调优。
🔔如果您需要转载或者搬运这篇文章的话，非常欢迎您私信我哦~
希望各位读者大大多多支持用心写文章的博主，现在时代变了，信息爆炸，酒香也怕巷子深，博主真的需要大家的帮助才能在这片海洋中继续发光发热，所以，赶紧动动你的小手，点波关注❤️，点波赞👍，点波收藏⭐，甚至点波评论✍️，都是对博主最好的支持和鼓励！
📥博主的人生感悟和目标
- 🍋程序开发这条路不能停，停下来容易被淘汰掉，吃不了自律的苦，就要受平庸的罪，持续的能力才能带来持续的自信。我本身是一个很普通程序员，放在人堆里，除了与生俱来的盛世美颜，就剩180的大高个了，就是我这样的一个人，默默写博文也有好多年了。
- 📺有句老话说的好，牛逼之前都是傻逼式的坚持，希望自己可以通过大量的作品、时间的积累、个人魅力、运气、时机，可以打造属于自己的技术影响力。
- 💥内心起伏不定，我时而激动，时而沉思。我希望自己能成为一个综合性人才，具备技术、业务和管理方面的精湛技能。我想成为产品架构路线的总设计师，团队的指挥者，技术团队的中流砥柱，企业战略和资本规划的实战专家。
- 🎉这个目标的实现需要不懈的努力和持续的成长，但我必须努力追求。因为我知道，只有成为这样的人才，我才能在职业生涯中不断前进并为企业的发展带来真正的价值。在这个不断变化的时代，我必须随时准备好迎接挑战，不断学习和探索新的领域，才能不断地向前推进。我坚信，只要我不断努力，我一定会达到自己的目标。