聊聊JVM如何优化
首先应该明确的是JVM调优不是常规手段,JVM的存在本身就是为了减轻开发对于内存管理的负担,当出现性能问题的时候第一时间考虑的是代码逻辑与设计方案,以及是否达到依赖中间件的瓶颈,最后才是针对JVM进行优化。
1.JVM内存模型
针对JAVA8的模型进行讨论,JVM的内存模型主要分为几个关键区域:堆、方法区、程序计数器、虚拟机栈和本地方法栈。堆内存进一步细分为年轻代、老年代,年轻代按其特性又分为E区,S1和S2区。关于内存模型的一些细节就不在这里讨论了,如下是从网上找的内存模型图:
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-05-28-16-5050AOuLl6a650Vgu750.png)
接下来从内存模型简单流转来看一个对象的生命周期,对JVM的回收有一个概念,其中弱化堆栈和程序计数器
1.首先我们写的.java文件通过java编译器javac编译成.class文件
2.类被编译成.class文件后,通过类加载器(双亲委派模型)加载到JVM的元空间中
3.当创建对象时,JVM在堆内存中为对象分配空间,通常首先在年轻代的E区(这里只讨论在堆上分配的情况)
4.对象经历YGC后,如果存活移动到S区,多次存活后晋升到老年代
5.当对象不再被引用下一次GC,垃圾收集器会回收对象并释放其占用的内存。
1.1 年轻代回收原理
对象创建会在年轻代的E区分配内存,当失去引用后,变成垃圾存在E区中,随着程序运行E区不断创建对象,就会逐步塞满,这时候E区中绝大部分都是失去引用的垃圾对象,和一小部分正在运行中的线程产生的存活对象。这时候会触发YGC(Young Gc)回收年轻代。然后把存活对象都放入第一个S区域中,也就是S0区域,接着垃圾回收器就会直接回收掉E区里全部垃圾对象,在整个这个垃圾回收的过程中全程会进入Stop the Wold状态,系统代码全部停止运行,不允许创建新的对象。YGC结束后,系统继续运行,下一次如果E区满了,就会再次触发YGC,把E区和S0区里的存活对象转移到S1区里去,然后直接清空掉E区和S0区中的垃圾对象
1.2 、那么对象什么时候去老年代呢?
1.2.1、对象的年龄
躲过15次YGC之后的对象晋升到老年代,默认是15,这个值可以通过-XX:MaxTenuringThreshold设置
这个值设置的随意调整会有什么问题?
现在java项目普遍采用Spring框架管理对象的生命周期。Spring默认管理的对象都是单例的,这些对象是长期存活的应该直接放到老年代中,应该避免它们在年轻代中来回复制。调大晋升阀值会导致本该晋升的对象停留在年轻代中,造成频繁YGC。但是如果设置的过小会导致程序中稍微存在耗时的任务,就会导致大量对象晋升到老年代,导致老年代内存持续增长,不要盲目的调整晋升的阀值。
1.2.2、动态对象年龄判断
JVM都会检查S区中的对象,并记录下每个年龄段的对象总大小。如果某个年龄段及其之前所有年龄段的对象总大小超过了S区的一半,则从该年龄段开始的所有对象在下一次GC时都会被晋升到老年代。假设S区可以容纳100MB的数据。在进行一次YGC后,JVM统计出如下数据:
此时,年龄1至3的对象总共占用了60MB,超过了S区一半的容量(50MB)。根据动态对象年龄判断规则,所有年龄为3及以上的对象在下一次GC时都将被晋升到老年代,而不需要等到它们的年龄达到15。(注意:这里S区指的是S0或者S1的空间,而不是总的S,总的在这里是200MB)
这个机制使得JVM能够根据实际情况动态调整对象的晋升策略,从而优化垃圾收集的性能。通过这种方式,JVM尽量保持S区空间的有效利用,同时减少因年轻代对象过多而导致的频繁GC。
1.2.3.大对象直接进入老年代
如果对象的大小超过了预设的阈值(可以通过-XX:PretenureSizeThreshold参数设置),这个对象会直接在老年代分配,因为大对象在年轻代中经常会导致空间分配不连续,从而提早触发GC,避免在E区及两个S区之间来回复制,减少垃圾收集时的开销。
1.2.4.临时晋升
在某些情况下,如果S区不足以容纳一次YGC后的存活对象,这些对象也会被直接晋升到老年代,即使它们的年龄没有达到晋升的年龄阈值。这是一种应对空间不足的临时措施。
1.3老年代的GC触发时机
一旦老年代对象过多,就可能会触发FGC(Full GC),FGC必然会带着Old GC,也就是针对老年代的GC 而且一般会跟着一次YGC,也会触发永久代的GC,但具体触发条件和行为还取决于使用的垃圾收集器,文章的最后会简单的介绍下垃圾收集器。
当老年代空间不足以分配新的对象时,会触发FGC,这包括清理整个堆空间,即年轻代和老年代。
当老年代的使用达到某个阈值(默认情况下是68%)时,开始执行CMS收集过程,尝试清理老年代空间。如果在CMS运行期间老年代空间不足以分配新的对象,可能会触发一次Full GC。 启动CMS的阈值参数:-XX:CMSInitiatingOccupancyFraction=75,-XX:+UseCMSInitiatingOccupancyOnly
G1收集器将堆内存划分为多个区域(Region),包括年轻代和老年代区域。当老年代区域中的空间使用率达到一定比例(基于启发式方法或者显式配置的阈值)默认45%时,G1会计划并执行Mixed GC,这种GC包括选定的一些老年代区域和所有年轻代区域的垃圾收集。
Mixed GC的阈值参数-XX:InitiatingHeapOccupancyPercent=40,-XX:MaxGCPauseMillis=200
2.JVM优化调优目标:
2.1JVM调优指标
但是不同目标在实现是本身时有冲突的,为什么难以同时满足?
2.2如何权衡
在实际应用中,根据应用的需求和特性,开发者和运维工程师需要在这三个目标之间做出权衡:
2.2.1Web应用和微服务 - 低延迟优先
场景描述:对于用户交互密集的Web应用和微服务,快速响应是提供良好用户体验的关键。在这些场景中,低延迟比高吞吐量更为重要。
推荐收集器:大内存应用推荐G1,内存偏小可以使用CMS,CMS曾经是低延迟应用的首选,因其并发回收特性而被广泛使用。不过由于CMS在JDK 9中被标记为废弃,并在后续版本中被移除可以使用极低延迟ZGC或Shenandoah。这两种收集器都设计为低延迟收集器,能够在大内存堆上提供几乎无停顿的垃圾回收,从而保证应用的响应速度,但是支持这两个回收器的JDK版本较高,在JDK8版本还是CMS和G1的天下。
2.2.2 大数据处理和科学计算 - 高吞吐量优先
场景描述:大数据处理和科学计算应用通常需要处理大量数据,对CPU资源的利用率要求极高。这类应用更注重于高吞吐量,以完成更多的数据处理任务,而不是每个任务的响应时间。
推荐收集器:Parallel GC。这是一种以高吞吐量为目标设计的收集器,通过多线程并行回收垃圾,以最大化应用吞吐量,非常适合CPU资源充足的环境。
2.2.3. 大型内存应用 - 大内存管理优先
场景描述:对于需要管理大量内存的应用,例如内存数据库和某些缓存系统,有效地管理大内存成为首要考虑的因素。这类应用需要垃圾回收器能够高效地处理大量的堆内存,同时保持合理的响应时间和吞吐量。
推荐收集器:G1 GC或ZGC。G1 GC通过将堆内存分割成多个区域来提高回收效率,适合大内存应用且提供了平衡的延迟和吞吐量。ZGC也适合大内存应用,提供极低的延迟,但可能需要对应用进行调优以实现最佳性能。
3.JVM优化一般是针对于两种场景
3.1新应用上线,通过预估核心接口流量进行压测,观察JVM的GC情况并调优
压测需要观察那些重要的指标呢
通过jstat观察出来上述JVM运行指标!
3.2老应用通过监控收到JVM异常反馈,或者程序出现下列问题进行优化
3.2.1应用出现OutOfMemory等内存异常
(1)堆内存溢出 Java heap space
对象持续创建而不被回收或者来不及回收,导致堆内存耗尽。
(2)元空间溢出 Metaspace
元空间的溢出通常是因为加载的 class 数目太多或体积太大
例如:动态生成大量Class对象,比如某些框架(如OSGi、ASM)动态生成大量的类,这些类占用的空间可能超过了元空间的限制,或者加载了大量的第三方库,这些库中包含的类和常量占用了大量的方法区空间。如果是正常类加载需要调大元空间-XX:MaxMetaspaceSize,否则需要导出DUMP文件,分析是否存在重复类
(3)虚拟机栈和本地方法栈溢出
线程请求的栈深度超过了虚拟机栈和本地方法栈允许的最大深度。这种情况通常发生在深度递归调用的情况下(-Xss参数设置栈的大小)。
应用创建了过多线程,超出了系统承载能力,尤其是在32位系统上,每个线程的栈空间(默认1MB)会占用一定的地址空间,可能会导致系统无法分配足够的地址空间给新的线程。
(4)直接内存溢出 Direct buffer memory
Java 允许应用程序通过 Direct ByteBuffer 直接访问堆外内存,许多高性能程序通过 Direct ByteBuffer 结合内存映射文件(Memory Mapped File)实现高速 IO。Direct ByteBuffer 的默认大小为 64 MB
3.2.2 Heap内存(老年代)持续上涨达到设置的最大内存值;
老年代持续上涨是JVM优化的重要指标,但是老年代持续上涨有多种原因
内存泄漏:最开始的表现也是老年代的持续上涨,触发FGC无法回收抛出OOM,系统宕机!
正常情况:可能是因为流量徒增导致年轻代处理不过来,临时移入老年代,执行FGC后内存明显下降!
大对象:大对象直接分配在老年代,触发FGC后内存明显下降!
年轻代的S区设置过小:E区正常回收后存活的对象,在S区放不下直接晋升到老年代,有一个大坑就是JAVA8默认收集器Parallel Scavenge为了处理更大的吞吐量会动态调整S区,在线上运行一段时间后S区会变得很小,导致大量对象进入到老年代,我在优化实战中排查过这个问题
3.2.3 FGC 次数频繁
频繁进行FGC如果出现OOM按照3.2.1进行排查
频繁FGC但是内存能被回收按照3.2.2进行排查
3.2.4 GC 停顿时间长
YGC停顿
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-05-28-16-50t386biRrIGMxwlLa.png)
可以看看这篇文章总结的挺好的:JVM性能调优--YGC
FGC停顿
FGC的触发一般是老年代或者元空间内存不足,FGC执行本身是比较耗时的操作,会回收整个堆内存以及元空间,我们在优化JVM尽量避免FGC,或者尽量少的FGC。FGC停顿指标需要结合FGC执行频率,以及历史执行时间来看如果是因为内存空间大导致回收慢可以选择G1针对大内存进行处理
总结:
JVM优化没有拿过来直接用的方案,所有好的JVM优化方案都是在当前应用背景下的,还是开头那句话 JVM调优不是常规手段,如果没有发现问题尽量不主动优化JVM,但是一定要了解应用的JVM运行情况,这时候好的监控就显得格外重要。
那么好的JVM应该是什么样的呢?简单的说就是尽量让每次YGC后的存活对象小于S区域的50%,都留存在年轻代里。尽量别让对象进入老年代。尽量减少FGC的频率,避免频繁FGC对JVM性能的影响。
了解了JVM优化的基本原理之后,实战就需要在日常中积累了,墨菲定律我觉得在这个场景很适用,不要相信线上的机器是稳定的,如果观察到监控有异常,过一会可能恢复了就不了了之,要敢于去排查问题,未知的总是令人恐惧的,在排查的过程中会加深自己对JVM的理解的同时,也会对应用更有信心。
4.线上优化实战:
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-07-29-18-098S6wHs6a699uesV.png)
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-07-29-18-1010eINdh7Di15sNmGz.png)