内容简介：JAVA进程启动的时候，虽然我们可以为JVM指定合适的内存大小，但是这些内存操作系统并没有真正的分配给JVM,而是等JVM访问这些内存的时候,才真正分配,这样会造成以下问题:配置对比结果如下，差距还是蛮大的：
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 ，如下图所示：
转自 阿飞的博客
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Remote
Jason Fried、David Heinemeier Hansson / Crown Business / 2013-10-29 / CAD 26.95
The “work from home” phenomenon is thoroughly explored in this illuminating new book from bestselling 37signals founders Fried and Hansson, who point to the surging trend of employees working from hom......一起来看看 《Remote》 这本书的介绍吧!
