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，如下图所示：
转自 阿飞的博客
