JAVA进程启动的时候,虽然我们可以为JVM指定合适的内存大小,但是这些内存操作系统并没有真正的分配给JVM,而是等JVM访问这些内存的时候,才真正分配,这样会造成以下问题:
- 第1次YGC之前Eden区分配对象的速度较慢;
- YGC的时候,Young区的对象要晋升到Old区的时候,这个时候需要操作系统真正分配内存,这样就会加大YGC的停顿时间;
启动时间
配置-XX:+AlwaysPreTouch参数可以优化这个问题,不过这个参数也有副作用,它会影响启动时间,那影响到底有多大呢?请接着往下看。
对比结果如下,差距还是蛮大的:
~ | -XX:+AlwaysPreTouch | XX:-AlwaysPreTouch(default) |
---|---|---|
16G | 36s | <1s |
8G | 20s | <1s |
并行PreTouch
配置这个参数后这么耗时其中一个原因是,这个特性在JDK8版本以前都不是并行处理的,到了JDK9才是并行。可以戳链接Parallelize Memory Pretouch: https://bugs.openjdk.java.net/browse/JDK-8157952
根本原因
配置-XX:+AlwaysPreTouch参数后,JVM进程启动时间慢了几个数量级的根本原因呢?
在没有配置-XX:+AlwaysPreTouch参数即默认情况下,JVM参数-Xms申明的堆只是在虚拟内存中分配,而不是在物理内存中分配:它被以一种内部数据结构的形式记录,从而避免被其他进程使用这些内存。这些内存页直到被访问时,才会在物理内存中分配。当JVM需要内存的时候,操作系统将根据需要分配内存页。
配置-XX:+AlwaysPreTouch参数后,JVM将-Xms指定的堆内存中每个字节都写入'0',这样的话,除了在虚拟内存中以内部数据结构保留之外,还会在物理内存中分配。并且由于touch这个行为是单线程的,因此它将会让JVM进程启动变慢。所以,要么选择减少接下来对每个缓存页的第一次访问时间,要么选择减少JVM进程启动时间,这是一种trade-off。
对G1无效
G1前提下,即使配置了-XX:+AlwaysPreTouch参数,JVM也会忽略掉这个参数,即跟没有配置效果一样。8u60版本修复了这个问题,详情请戳链接:G1 ignores AlwaysPreTouch: https://bugs.openjdk.java.net/browse/JDK-8067469,如下图所示:
转自 阿飞的博客