JVM 调优手册

梦里梦外; 2022-05-25 12:05 157阅读 0赞

### **JVM 调优手册** ###

#### [JVM调优总结（7）：调优方法][JVM_7] ####

（1）栈是运行时的单位，而堆是存储的单位

（2）栈代表了处理逻辑，堆代表了数据

（3）堆中存的是对象，栈中存的是基本数据类型和堆中对象的引用

（4） 程序运行永远都是在栈中进行的，因而参数传递时，只存在传递基本类型和对象引用的问题

（5）栈的大小通过-Xss来设置，当栈中存储数据比较多时，需要适当调大这个值，否则会出现java.lang.StackOverflowError异常。常见的出现这个异常的是无法返回的递归，因为此时栈中保存的信息都是方法返回的记录点（堆就是一块共享的内存）

（6）Java栈中保存引用的所需要的空间：4byte；一个空Object对象的大小是8byte；java在对对象内存分配时都是以8的整数倍来分；

一个基本类型包装类的大小至少是16byte（因为这种包装类型已经成为对象了，因此需要把他们作为对象来看待。包装类型的大小至少是12byte，java对象大小是8的整数倍）

（7）基本垃圾回收算法：标记-整理（Mark-Compact）

此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题

（8）垃圾回收的起点是一些根对象（java栈, 静态变量, 寄存器…）。而最简单的Java栈就是Java程序执行的main函数。这种回收方式，也是上面提到的“标记-清除”的回收方式

（9）如何解决同时存在的对象创建和对象回收问题

（目前最有效）：进行垃圾回收前，一般都需要暂停整个应用（即：暂停内存的分配），然后进行垃圾回收，回收完成后再继续应用。

弊端：当堆空间持续增大时，垃圾回收的时间也将会相应的持续增大，对应应用暂停的时间也会相应的增大。

并发垃圾回收算法：使用这种算法，垃圾回收线程与程序运行线程同时运行。在这种方式下，解决了暂停的问题，但是因为需要在新生成对象的同时又要回收对象，算法复杂性会大大增加，系统的处理能力也会相应降低，同时，“碎片”问题将会比较难解决。

（10）不同的对象的生命周期是不一样的，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率

（11）年轻代 --> 年老代 --> 持久代

![2018051511211479][]

对新生成的对象一直有引用，即该对象一直存活，就逐步过渡各个代。

年轻代：Eden区 + 两个Survivor区 （Survivor区是可以配置为多个的（多于两个）：这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能）

持久代：用于存放静态文件，如今Java类、方法等。持久代大小通过-XX:MaxPermSize=<N>进行设置

（12）什么情况去触发垃圾回收

Scavenge GC： 一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Scavenge GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。

Full GC：对整个堆进行整理，包括Young、Tenured和Perm

有如下原因可能导致Full GC

· 年老代（Tenured）被写满

· 持久代（Perm）被写满

· System.gc()被显示调用

·上一次GC之后Heap的各域分配策略动态变化

（13） 并行收集器

此收集器可以进行如下配置：

> 最大垃圾回收暂停:指定垃圾回收时的最长暂停时间，通过-XX:MaxGCPauseMillis=<N>指定。<N>为毫秒.如果指定了此值的话，堆大小和垃圾回收相关参数会进行调整以达到指定值。设定此值可能会减少应用的吞吐量。
> 
> 吞吐量:吞吐量为垃圾回收时间与非垃圾回收时间的比值，通过-XX:GCTimeRatio=<N>来设定，公式为1/（1+N）。例如，-XX:GCTimeRatio=19时，表示5%的时间用于垃圾回收。默认情况为99，即1%的时间用于垃圾回收
> 
> 串行处理器：
> 
> –适用情况：数据量比较小（100M左右）；单处理器下并且对响应时间无要求的应用。  
> –缺点：只能用于小型应用
> 
> 并行处理器：
> 
> –适用情况：“对吞吐量有高要求”，多CPU、对应用响应时间无要求的中、大型应用。举例：后台处理、科学计算。  
> –缺点：垃圾收集过程中应用响应时间可能加长
> 
> 并发处理器：
> 
> –适用情况：“对响应时间有高要求”，多CPU、对应用响应时间有较高要求的中、大型应用。举例：Web服务器/应用服务器、电信交换、集成开发环境。
> 
> \-XX:PrintHeapAtGC:  打印GC前后的详细堆栈信息  
>

（14）年轻代和年老代的大小选择 调优总结

年轻代大小选择：

响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。

吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。

年老代大小选择：

响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：

1. 并发垃圾收集信息

2. 持久代并发收集次数

3. 传统GC信息

4. 花在年轻代和年老代回收上的时间比例

减少年轻代和年老代花费的时间，一般会提高应用的效率

吞吐量优先的应用

一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。

较小堆引起的碎片问题：

因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：

1. \-XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。

2. \-XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩

（15）内存泄漏检查

1.年老代堆空间被占满

异常： java.lang.OutOfMemoryError: Java heap space

![20180517090127894][]

解决：这种方式解决起来也比较容易，一般就是根据垃圾回收前后情况对比，同时根据对象引用情况（常见的集合对象引用）分析，基本都可以找到泄漏点。

2. 持久代被占满

异常：java.lang.OutOfMemoryError: PermGen space

解决：

1. -XX:MaxPermSize=16m

2. 换用JDK。比如JRocket。[JRocket][]

3.堆栈溢出

异常：java.lang.StackOverflowError

说明：这个就不多说了，一般就是递归没返回，或者循环调用造成

4. 线程堆栈满

异常：Fatal: Stack size too small

说明：java中一个线程的空间大小是有限制的。JDK5.0以后这个值是1M。与这个线程相关的数据将会保存在其中。但是当线程空间满了以后，将会出现上面异常。

解决：增加线程栈大小。-Xss2m。但这个配置无法解决根本问题，还要看代码部分是否有造成泄漏的部分。

5.系统内存被占满

异常：java.lang.OutOfMemoryError: unable to create new native thread

说明：

这个异常是由于操作系统没有足够的资源来产生这个线程造成的。系统创建线程时，除了要在Java堆中分配内存外，操作系统本身也需要分配资源来创建线程。因此，当线程数量大到一定程度以后，堆中或许还有空间，但是操作系统分配不出资源来了，就出现这个异常了。

分配给Java虚拟机的内存愈多，系统剩余的资源就越少，因此，当系统内存固定时，分配给Java虚拟机的内存越多，那么，系统总共能够产生的线程也就越少，两者成反比的关系。同时，可以通过修改-Xss来减少分配给单个线程的空间，也可以增加系统总共内生产的线程数。

解决：

1. 重新设计系统减少线程数量。

2. 线程数量不能减少的情况下，通过-Xss减小单个线程大小。以便能生产更多的线程。

[JVM_7]: http://www.importnew.com/19275.html
[2018051511211479]: /images/20220525/5f82cb8dc1fe43c8873e3ac9b55aadfb.png
[20180517090127894]: /images/20220525/d6c92d18bf6b4bf8a29ef0294aafafac.png
[JRocket]: https://blog.csdn.net/liu78778/article/details/4805189