JVM 调优手册

最新推荐文章于 2022-04-30 19:36:59 发布

caox_nazi

最新推荐文章于 2022-04-30 19:36:59 发布

阅读量755

点赞数 3

分类专栏：架构文章标签： JVM JAVA

本文链接：https://blog.csdn.net/caox_nazi/article/details/80312872

版权

架构专栏收录该内容

21 篇文章 0 订阅

订阅专栏

JVM 调优手册

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）年轻代 --> 年老代 --> 持久代

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

年轻代：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