如何优化JVM内存分配?

JVM 调优是一个系统而又复杂的过程,但我们知道,在大多数情况下,我们基本不用去调

整 JVM 内存分配,因为一些初始化的参数已经可以保证应用服务正常稳定地工作了。
但所有的调优都是有目标性的,JVM 内存分配调优也一样。没有性能问题的时候,我们自
然不会随意改变 JVM 内存分配的参数。那有了问题呢? 有了什么样的性能问题我们需要对
其进行调优呢?又该如何调优呢? 这就是我今天要分享的内容。
JVM 内存分配性能问题 谈到 JVM 内存表现出的性能问题时,你可能会想到一些线上的 JVM 内存溢出事故。但这
方面的事故往往是应用程序创建对象导致的内存回收对象难,一般属于代码编程问题。
但其实很多时候,在应用服务的特定场景下,JVM 内存分配不合理带来的性能表现并不会
像内存溢出问题这么突出。可以说如果你没有深入到各项性能指标中去,是很难发现其中隐
藏的性能损耗。
JVM 内存分配不合理最直接的表现就是频繁的 GC,这会导致上下文切换等性能问题,从
而降低系统的吞吐量、增加系统的响应时间。因此, 如果你在线上环境或性能测试时,发现
频繁的 GC,且是正常的对象创建和回收,这个时候就需要考虑调整 JVM 内存分配了,
而减少 GC 所带来的性能开销。
对象在堆中的生存周期
了解了性能问题,那需要做的势必就是调优了。但先别急,在了解 JVM 内存分配的调优过
程之前,我们先来看看一个新创建的对象在堆内存中的生存周期,为后面的学习打下基础。
第 20 讲 中,我讲过 JVM 内存模型。我们知道,在 JVM 内存模型的堆中,堆被划分为
新生代和老年代,新生代又被进一步划分为 Eden 区和 Survivor 区,最后 Survivor 由
From Survivor 和 To Survivor 组成。
当我们新建一个对象时,对象会被优先分配到新生代的 Eden 区中,这时虚拟机会给对象定
义一个对象年龄计数器(通过参数 -XX:MaxTenuringThreshold 设置)。
同时,也有另外一种情况,当 Eden 空间不足时,虚拟机将会执行一个新生代的垃圾回收
(Minor GC)。这时 JVM 会把存活的对象转移到 Survivor 中,并给对象的年龄 +1。对
象在 Survivor 中同样也会经历 MinorGC,每经过一次 MinorGC,对象的年龄将会 +1。
当然了,内存空间也是有设置阈值的,可以通过参数 -XX:PetenureSizeThreshold 设置直
接被分配到老年代的最大对象,这时如果分配的对象超过了设置的阀值,对象就会直接被分
配到老年代,这样做的好处就是可以减少新生代的垃圾回收。
查看 JVM 堆内存分配
我们知道了一个对象从创建至回收到堆中的过程,接下来我们再来了解下 JVM 堆内存是如
何分配的。在默认不配置 JVM 堆内存大小的情况下,JVM 根据默认值来配置当前内存大 小。我们可以通过以下命令来查看堆内存配置的默认值:
1 java -XX:+PrintFlagsFinal -version | grep HeapSize
2 jmap -heap 17284

 Version:0.9 StartHTML:0000000105 EndHTML:0000006521 StartFragment:0000000141 EndFragment:0000006481

通过命令,我们可以获得在这台机器上启动的 JVM 默认最大堆内存为 1953MB,初始化大
小为 124MB。
在 JDK1.7 中,默认情况下年轻代和老年代的比例是 1:2,我们可以通过–XX:NewRatio 重
置该配置项。年轻代中的 Eden 和 To Survivor、From Survivor 的比例是 8:1:1,我们可
以通过 -XX:SurvivorRatio 重置该配置项。
在 JDK1.7 中如果开启了 -XX:+UseAdaptiveSizePolicy 配置项,JVM 将会动态调整 Java
堆中各个区域的大小以及进入老年代的年龄,–XX:NewRatio 和 -XX:SurvivorRatio 将会失
效,而 JDK1.8 是默认开启 -XX:+UseAdaptiveSizePolicy 配置项的。
还有,在 JDK1.8 中,不要随便关闭 UseAdaptiveSizePolicy 配置项,除非你已经对初始
化堆内存 / 最大堆内存、年轻代 / 老年代以及 Eden 区 /Survivor 区有非常明确的规划了。
否则 JVM 将会分配最小堆内存,年轻代和老年代按照默认比例 1:2 进行分配,年轻代中的
Eden 和 Survivor 则按照默认比例 8:2 进行分配。这个内存分配未必是应用服务的最佳配
置,因此可能会给应用服务带来严重的性能问题。
JVM 内存分配的调优过程
我们先使用 JVM 的默认配置,观察应用服务的运行情况,下面我将结合一个实际案例来讲
述。现模拟一个抢购接口,假设需要满足一个 5W 的并发请求,且每次请求会产生 20KB
对象,我们可以通过千级并发创建一个 1MB 对象的接口来模拟万级并发请求产生大量对象
的场景,具体代码如下:
@RequestMapping(value = "/test1")
public String test1(HttpServletRequest request) {
List<Byte[]> temp = new ArrayList<Byte[]>();
Byte[] b = new Byte[1024*1024];
temp.add(b);
return "success";
}
AB 压测
 
分别对应用服务进行压力测试,以下是请求接口的吞吐量和响应时间在不同并发用户数下的
变化情况:
通过命令,我们可以获得在这台机器上启动的 JVM 默认最大堆内存为 1953MB,初始化大
小为 124MB。
在 JDK1.7 中,默认情况下年轻代和老年代的比例是 1:2,我们可以通过–XX:NewRatio 重
置该配置项。年轻代中的 Eden 和 To Survivor、From Survivor 的比例是 8:1:1,我们可
以通过 -XX:SurvivorRatio 重置该配置项。
在 JDK1.7 中如果开启了 -XX:+UseAdaptiveSizePolicy 配置项,JVM 将会动态调整 Java
堆中各个区域的大小以及进入老年代的年龄,–XX:NewRatio 和 -XX:SurvivorRatio 将会失
效,而 JDK1.8 是默认开启 -XX:+UseAdaptiveSizePolicy 配置项的。
还有,在 JDK1.8 中,不要随便关闭 UseAdaptiveSizePolicy 配置项,除非你已经对初始
化堆内存 / 最大堆内存、年轻代 / 老年代以及 Eden 区 /Survivor 区有非常明确的规划了。
否则 JVM 将会分配最小堆内存,年轻代和老年代按照默认比例 1:2 进行分配,年轻代中的
Eden 和 Survivor 则按照默认比例 8:2 进行分配。这个内存分配未必是应用服务的最佳配
置,因此可能会给应用服务带来严重的性能问题。
 
我们可以将某些指标的预期值作为参考指标,上面的 GC 频率就是其中之一,那么还有哪
些指标可以为我们提供一些具体的调优方向呢?
GC 频率: 高频的 FullGC 会给系统带来非常大的性能消耗,虽然 MinorGC 相对 FullGC 来
说好了许多,但过多的 MinorGC 仍会给系统带来压力。
内存: 这里的内存指的是堆内存大小,堆内存又分为年轻代内存和老年代内存。首先我们要
分析堆内存大小是否合适,其实是分析年轻代和老年代的比例是否合适。如果内存不足或分
配不均匀,会增加 FullGC,严重的将导致 CPU 持续爆满,影响系统性能。
吞吐量: 频繁的 FullGC 将会引起线程的上下文切换,增加系统的性能开销,从而影响每次
处理的线程请求,最终导致系统的吞吐量下降。
延时: JVM 的 GC 持续时间也会影响到每次请求的响应时间。
具体调优方法
调整堆内存空间减少 FullGC: 通过日志分析,堆内存基本被用完了,而且存在大量
FullGC,这意味着我们的堆内存严重不足,这个时候我们需要调大堆内存空间。
 
以下是各个配置项的说明:
-Xms:堆初始大小;
-Xmx:堆最大值。
调大堆内存之后,我们再来测试下性能情况,发现吞吐量提高了 40% 左右,响应时间也降
低了将近 50%。

再查看 GC 日志,发现 FullGC 频率降低了,老年代的使用率只有 16% 了。
 
调整年轻代减少 MinorGC: 通过调整堆内存大小,我们已经提升了整体的吞吐量,降低了
响应时间。那还有优化空间吗?我们还可以将年轻代设置得大一些,从而减少一些
MinorGC( 有通过降低 Minor GC 频率来提高系统性能的详解)。
 
设置 Eden、Survivor 区比例: 在 JVM 中,如果开启 AdaptiveSizePolicy,则每次 GC
后都会重新计算 Eden、From Survivor 和 To Survivor 区的大小,计算依据是 GC 过程中 统计的 GC 时间、吞吐量、内存占用量。这个时候 SurvivorRatio 默认设置的比例会失效。
在 JDK1.8 中,默认是开启 AdaptiveSizePolicy 的,我们可以通过 -XX:-
UseAdaptiveSizePolicy 关闭该项配置,或显示运行 -XX:SurvivorRatio=8 将 Eden、
Survivor 的比例设置为 8:2。大部分新对象都是在 Eden 区创建的,我们可以固定 Eden 区
的占用比例,来调优 JVM 的内存分配性能。
再进行 AB 性能测试,我们可以看到吞吐量提升了,响应时间降低了。

 

总结
JVM 内存调优通常和 GC 调优是互补的, 基于以上调优,我们可以继续对年轻代和堆内存
的垃圾回收算法进行调优。这里可以结合上一讲的内容,一起完成 JVM 调优。
虽然分享了一些 JVM 内存分配调优的常用方法,但我还是建议你在进行性能压测后如果没
有发现突出的性能瓶颈,就继续使用 JVM 默认参数,起码在大部分的场景下,默认配置已
经可以满足我们的需求了。但满足不了也不要慌张,结合今天所学的内容去实践一下,相信
你会有新的收获。
  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值