JVM之决定堆大小以及内存占用

JVM之决定堆大小以及内存占用

 

      首先需要判断出应用存活的数据的大小，存活数据的大小是决定配置应用需要的Java堆大小的重要条件，也能够决定是否需要重新审视一下应用的内存需求或者修改应用程序以满足内存需求。

 

注意：存活数据是指，应用处于稳定运行状态下，在Java堆里面长期存活的对象。换一句话说，就是应用在稳定运行的状态下，Full GC之后，Java堆的所占的空间。

 

 

 

约束

   

有多少物理内存可以供JVM使用？是部署多个JVM或者单个JVM？对做出的决定有重要影响。下面列出了一些要点可以帮助决定有多少物理内存可以供使用。

 

• 一个机器上面只是部署一个JVM，且就一个应用使用？如果是这种情况，那么机器的所有物理内存可以供JVM使用。
• 一个机器上部署了多个JVM？或者一个机器上部署了多个应用？如果是这两个中的任何一种情况，你就必须要决定每一个JVM或者应用需要分配多少内存了。

注意：无论是前面的哪种情况，都需要给操作系统留出一些内存。

 

 

 

HotSpot VM的堆结构

   

在做内存占用测量之前，我们必须要先理解HotSpot VM Java堆的结构，理解这个对决定应用需要的Java堆大小以及优化垃圾收器性能有很好的帮助。

 

 

HotSpot VM有3个主要的空间：young代、old代以及permanent代,如上图所示。

 

当Java应用分配Java对象时，这些对象被分配到young代。在经历过几次minor GC之后，如果对象还是存活的，就会被转移到old代空间。permanent代空间存储了VM和Java类的元数据比如内置的字符串和类的静态变量。

 

 

配置堆大小

 

• -Xms：堆初始值大小
• -Xmx：堆最大值大小

注意：

当-Xms的值小于-Xmx的值的时候，Java堆的大小可以在最大值和最小值之前浮动。当Java应用强调吞吐量和延迟的时候，倾向于把-Xms和-Xmx设置成相同的值，由于调整young代或者old代的大小都需要进行Full GC，Full GC降低吞吐量以及加强延迟。

 

 

年轻代大小

 

• -XX:NewSize=<n>[g|m|k]：年轻代初始值和最小值的大小，如果设置这个值，就一定要设置-XX:MaxNewSize=<n>[g|m|k]
• -XX:MaxNewSize=<n>[g|m|k]：年轻代最大值
• -Xmn<n>[g|m|k]：如果年轻代大小固定，就用这个配置

注意：

如果-Xms和-Xmx没有被设定成相同的值，而且-Xmn被使用了，当调整Java堆的大小的时候，不会调整young代的空间大小，young代的空间大小会保持恒定。因此，-Xmn应该在-Xms和-Xmx设定成相同的时候才指定。  

 

 

老年代大小

 

      old代的空间大小可以基于young代的大小进行计算，old代的初始值的大小是-Xms的值减去-XX:NewSize，最大值是-Xmx减去-XX:MaxNewSize，如果-Xmx和-Xms设置成了相同的值，而且使用-Xmn选项或者-XX:NewSize和-XX:MaxNewSize设置成了相同的值，那么old代的大小就是-Xmx减去-Xmn。

 

 

方法区大小

 

• -XX:PermSize=<n>[g|m|k]：方法区初始值大小
• -XX:MaxPermSize=<n>[g|m|k]：方法区最大值大小

注意：

Java应用应该指定这两个值成为同一个值，由于这个值的调整会导致Full GC。

 

 

 

垃圾回收相关信息

 

如果上面提到的Java堆大小、young代、permanent代的大小都没有指定，那么JVM会根据应用的情况自行计算。

 

在young代、old代以及permanent代中任何一个空间里面无法分配对象的时候就会触发垃圾回收，理解这点，对后面的优化非常重要。当young代没有足够空间分配Java对象的时候，触发minor GC。minor GC相对于Full GC来说会更短暂。

 

一个对象在经历过一定次数的Minor GC之后，如果还存活，那么会被转移到old代（对象有一个“任期阀值”的概念，优化延迟的时候再介绍）。当old代没有足够空间放置对象的时候，HotSpot VM触发full GC。实际上在进行Minor GC的时候发现没有old代足够的空间来进行对象的转移，就会触发Full GC，相对于在Minor GC的过程中发现对象的移动失败了然后触发Full GC，这样的策略会有更小的花费。当permanent代的空间不够用的时候的，也会触发Full GC。

 

如果Full GC是由于old代满了而触发的，old代和permanent代的空间都会被垃圾回收，即使permanent代的空间还没有满。同理，如果Full GC是由于permanent代满了而触发的，old代和permanent代的空间都会被垃圾回收，即使old代的空间还没有满。另外，young代同样会被垃圾回收，除非-XX:+ScavengeBeforeFullGC选项被指定了，-XX:+ScavengeBeforeFullGC关闭FullGC的时候young代的垃圾回收。

 

 

 

堆大小优化的起点

 

主要分以下步骤：

 

• 确定初始的垃圾回收器
• 自行配置堆大小或让JVM自行选择
• 监控GC日志
• 让系统进入稳定运行状态，并观察OutOfMemoryError的情况

 

确定初始的垃圾回收器

 

      就像在“选择JVM runtime”小节里面提到过的，由吞吐量垃圾回收器（throughput garbage collector）开始。记住，使用吞吐量垃圾回收器通过设置-XX:+UserParallelOldGC命令行选项，如果你使用的HotSpot VM不支持的这个选项，那么就使用-XX:+UserParallelGC。

 

 

自行配置堆大小或让JVM自行选择

 

      如果你能够准确的预估到应用需要消耗的Java堆空间，可以通过设定-Xmx和-Xms来作为这个步骤的起点。如果你不知道该设定什么值，就让JVM来选择吧，反正后面，都会根据实际情况进行优化调整。

 

 

监控GC日志

 

      关于如何监控GC日志前面的“GC优化基础”已经描述过了。GC日志会展示在使用中的java堆的大小。初始化和最大的堆大小可以通过-XX:+PrintCommandLineFlags来查看。-XX:+PrintCommandLineFlags打印出在HotSpot VM初始化的时候选择的初始值和最大值比如-XX:InitialHeapSize=<n> -XX:MaxHeapSize=<m>,这里n表示初始化的java堆大小值，m表示java堆的最大值。

 

 

让系统进入稳定运行状态，并观察OutOfMemoryError的情况

 

      不管你是指定java堆的大小还是使用默认的大小，必须让应用进入稳定运行的状态，你必须要有能力和手段让应用处于和线上稳定运行的状态相同的状态。

 

      如果在企图让应用进入稳定状态的时候，你在垃圾回收日志里面观察到OutOfMemoryError，注意是old代溢出还是permanent代溢出。下面一个old代溢出的例子：

2012-07-15T18:51:03.895-0600: [Full GC[PSYoungGen: 279700K->267300K(358400K)]  
[ParOldGen: 685165K->685165K(685170K)]  964865K->964865K(1043570K)  
[PSPermGen: 32390K->32390K(65536K)],0.2499342 secs]  
[Times: user=0.08 sys=0.00, real=0.05 secs]  
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space  

 

      上面重要的部分加粗标示了，由于使用的是吞吐量垃圾回收器，old代的统计信息标示为ParOldGen。这行表示了old代的在FullGC的时候占用的空间。从这个结果来看，可以得出的结论是old代的空间太小了，由于FullGC前后old代的被占用的空间和分配的空间基本相等了，因此，JVM报了OutOfMemoryError。相比较，通过PSPermGen这行可以看出permanent代的空间占用是32390K，和他的容量（65536K）比还是有一定的距离。

 

下面的例子展示了由于permanent太少了而导致的OutOfMemoryError发生的例子：

2012-07-15T18:26:37.755-0600: [Full GC  [PSYoungGen: 0K->0K(141632K)]  
  [ParOldGen: 132538K->132538K(350208K)]  32538K->32538K(491840K)  
  [PSPermGen: 65536K->65536K(65536K)],  0.2430136 secs]  
  [Times: user=0.37 sys=0.00, real=0.24 secs]  
  java.lang.OutOfMemoryError: PermGen space  

 

      同上面一样，把关键行标示出来了，通过PSPermGen这行可以看出在FullGC前后，他的空间占用量都和他的容量相同，可以得出的结论是permanent代的空间条小了，这样就导致了OutOfMemoryError。在这个例子里面，old的占用空间（132538K）远比他的容量（350208K）小。

 

 

调节堆大小，让其不会OutOfMemoryError的方法

 

      如果在垃圾回收日志中观察到OutOfMemoryError,尝试把Java堆的大小扩大到物理内存的80%~90%。尤其需要注意的是堆空间导致的OutOfMemoryError以及一定要增加空间。比如说，增加-Xms和-Xmx的值来解决old代的OutOfMemoryError,增加-XX:PermSize和-XX:MaxPermSize来解决permanent代引起的OutOfMemoryError。记住一点Java堆能够使用的容量受限于硬件以及是否使用64位的JVM。在扩大了Java堆的大小之后，再检查垃圾回收日志，直到没有OutOfMemoryError为止。

 

 

注意

如果应用运行在稳定状态下没有OutOfMemoryError就可以进入下一步了，计算活动对象的大小。

 

 

 

计算活动对象的大小

 

   就像前面提到的，活动对象的大小是应用处于稳定运行状态时，长时间存活数据占用的Java堆的空间大小。换句话说，就是应用稳定运行是，在FullGC之后，old代和permanent代的空间大小。

 

活动对象的大小可以通过垃圾回收日志查看，它提供了一些优化信息，如下：

 

• old代的Java堆空间占用数量。
• permanent代的Java堆空间占用数量。

为了保证能够准确的评估应用的活动对象大小，最好的做法是多看几次FullGC之后Java堆空间的大小，保证FullGC是发生在应用处于稳定运行的状态。

 

如果应用没有发生FullGC或者发生FullGC的次数很少，在性能测试环境，可以通过Java监控工具来触发FullGC，比如使用VisualVM和JConsole，这些工具在最新的JDK的bin目录下可以找到，VisualVM集成了JConsole，VisualVM或者JConsole上面有一个触发GC的按钮。 

 

 

 

初始化堆大小配置

 

 

下面的图，给出了应用存活的对象的大小。比较明智的做法是多收集几次FullGC信息，有更多的信息，能够做出更加好的决定。

 

 

配置堆大小

 

比较常规是，Java堆大小的初始化值和最大值（通过-Xms和-Xmx选项来指定）应该是old代活动对象的大小的3到4倍。

 

在上图中显示的FullGC信息中，在FullGC之后old代的大小是295111K,差不多是295M，即活动的对象的大小是295M。因此，推荐的Java堆的初始化和最大值应该是885M到1180M，即可以设置为-Xms885m -Xmx1180m。在这个例子中,Java堆的大小是1048570K差不多1048M，在推荐值范围内。

 

 

配置方法区大小

 

permanent的初始值和最大值（-XX:PermSize和-XX:MaxPermSize）应该permanent代活动对象大小的1.2到1.5倍。在上图中看到在FullGC之后permanent代占用空间是32390K，差不多32M。因此，permanent代的推荐大小是38M到48M,即可以设置为-XX:PermSize=48m -XX:MaxPermSize=48m(1.5倍)。这个例子里面，permanent代的空间大小是65536K即64M，大出了17M，不过在1G内存的系统的中，这个数值完全可以忍受。

 

 

配置年轻代大小

 

另外一个常规是，young代空间应该是old代活动对象大小的1到1.5倍。那么在这里例子中，young代的大小可以设置为295M到442M。本例里面，young代的空间大小的358400K，差不多358M，在推荐值中间。

 

如果推荐的Java堆的初始值和最大值是活动对象大小3到4倍，而young代的推荐只是1到1.5倍，那么old代空间大小应该是2到3倍。

 

还有，将对的初始值和最大值设置成一样，会更好

java -Xms1180m -Xmx1180m -Xmn295m

 

 

 

另外一些考虑

 

      本节将提及到在进行应用内存占用评估的时候，另外一些需要记住的点。首先，必须要知道，前面只是评估的Java堆的大小，而不是Java应用占用的所有的内存，如果要查看Java应用占用的所有内存在linux下可以通过top命令查看或者在window下面通过任务管理器来查看，尽管Java堆的大小可能对Java应用占用内存做出了最大的贡献。 比如说，为了存储线程堆栈，应用需要额外的内存，越多的线程，越多内存被线程栈消耗，越深的方法间调用，线程栈越多。另外，本地库需要分配额外的内存，I/O缓存也需要额外的内存。应用的内存消耗需要评估到应用任何一个会消耗内存的地方。

 

      记住，这一步操作不一定能够满足应用内存消耗的需求，如果不能满足，就回过头来看需求是否合理或者修改应用程序。比较可行的一种办法是修改应用程序减小对象的分配，从而减少内存的消耗。