JVM面试总结

目录

• Java虚拟机 JVM
  • • 常见面试题如下：
  • JVM内存模型
  • GC如何确定垃圾/确定死亡对象
  • 那些对象可以作为GC Roots
  • GC如何回收垃圾/垃圾收集算法
  • 垃圾收集器
    • CMS收集器（Concurrent Mark Sweep）
      • 缺点
    • G1垃圾收集器
  • GC触发条件
    • Minor GC
    • Full GC
  • JVM常见参数
  • 4种引用类型
  • 类加载过程
  • 类加载器
    • 双亲委派模型
  • JVM调优
    • 什么时候需要调优
    • 如何调优
  • 线上CPU过高如何排查
  • 如何确定JVM各区基本参数
  • Major GC和Minor GC频繁 「老年代GC/新生代GC」
    • 计算公式
    • 调整过程
    • 请求高峰期发生GC，导致服务可用性下降
  • 发生Stop-The-World的GC

Java虚拟机 JVM

常见面试题如下：

1. JVM内存模型
2. 垃圾回收机制
3. 那些对象可以作为GC Root
4. Minor GC和Full GC
5. 对象什么时候进入老年代
6. 类加载过程
7. 双亲委派模型和破坏双亲委派模型
8. JVM何时开始类加载
9. JVM常见的参数
10. 线上CPU过高如何排查
11. 什么时候需要JVM调优
12. 如何JVM调优
13. 常见的垃圾收集器

JVM内存模型

程序计数器：一块较小的内存空间, 是当前线程所执行的字节码的行号指示器，每条线程都要有一个独立的程序计数器，正在执行 java 方法的话，计数器记录的是虚拟机字节码指令的地址（当前指令的地址）。如果是 Native 方法，则为空。唯一一个在虚拟机中没有规定任何 OutOfMemoryError 情况的区域。

虚拟机栈(线程私有)：是描述java方法执行的内存模型，每个方法在执行的同时都会创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成
的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。栈帧随着方法调用而创建，随着方法结束而销毁——无论方法是正常完成还是异常完成（抛出了在方法内未被捕获的异
常）都算作方法结束。

本地方法栈(线程私有)：和虚拟机栈所发挥的作用是非常相似的，它们之间的区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。

堆：Java堆是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存，也是垃圾收集器进行垃圾收集的最重要的内存区域。Java 堆从 GC 的角度还可以细分为: 新生代(Eden 区、From Survivor 区和 To Survivor 区)和老年代。

方法区：方法区用于存储已被JVM加载的类信息、常量、静态变量，运行时常量池是方法区的一部分，class文件除了有类的字段、接口、方法等描述信息之外，还有常量池用于存放编译期间生成的各种字面量和符号引用。方法区也被称为永久代.

在 Java8中为了避免永久代的内存溢出以及OutOfMemoryError使用元空间替代永久代,区别在于：元空间并不在虚拟机中，而是使用
本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。类的元数据放入 native
memory, 字符串池和类的静态变量放入 java 堆中，这样可以加载多少类的元数据就不再由
MaxPermSize 控制, 而由系统的实际可用空间来控制。

GC如何确定垃圾/确定死亡对象

• 引用计数法[循环引用问题]
• 可达性分析算法 [那些可以作为GC Root]

那些对象可以作为GC Roots

• 虚拟机栈（栈帧中的本地变量表）中引用的对象。
• 方法区中类静态属性引用的对象。
• 方法区中常量引用的对象。
• 本地方法栈中JNI（即一般说的Native方法）引用的对象。

GC如何回收垃圾/垃圾收集算法

分代收集算法
：GC主要作用于堆 堆可分为新生代和老年代 不同区域使用不同的收集算法，新生代对象每次垃圾收集都会有大批量的对象死去,少数生还，选用复制算法，只需要付出少量存活对象的复制成本即可完成收集，老年代中对象存活率高且没有额外空间对它进行分配担保，所以使用“标记-清除”或“标记-整理”算法进行回收。

复制算法
：按内存容量将内存划分为等大小
的两块。每次只使用其中一块，当这一块内存满后将尚存活的对象复制到另一块上去，把已使用
的内存清掉。新生代分为1个Eden区和2个Survivor区（分别叫from和to）每次只使用其中的2块,且Eden和Survivor的大小为8/1

标记-清除算法： 分为标记和清除2个阶段，先标记需要回收的对象，标记完成后统一回收所有需要的对象。会产生较多不连续的内存碎片，可能会在下次分匹配大对象时候无法找到连续够大的内存空间而提前出发一次垃圾收集动作。

标记-整理：比标记-清除多了一步整理，可以避免产生较多的内存碎片.

垃圾收集器

CMS收集器（Concurrent Mark Sweep）

它是一种以获取最短回收停顿时间为目标的收集器。优点：并发收集，低停顿。基于“标记-清除”算法。目前很大一部分Java应用都集中在互联网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验，CMS收集器就非常符合这类应用的需求。

执行步骤：

1. 初始标记（CMS initial mark）:需要“Stop The World”，标记GC Roots能直接关联到的对象，速度快。
2. 并发标记（CMS concurrent mark）：进行GC Roots Tracing 过程
3. 重新标记（CMS remark）：需要“Stop The World”,修正并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。停顿时间：初始标记<重新标记<<并发标记
4. 并发清除（CMS concurrent sweep）：时间较长。

缺点

1. 对CPU资源非常敏感，面向并发设计的程序都会对CPU资源较敏感。在并发阶段会因为占用了一部分线程[CPU资源]会使应用程序变慢，总吞吐量降低，CMS默认的回收线程数: （CPU数量+3）/4

2. 无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。并发清理阶段用户程序运行产生的垃圾过了标记阶段所以无法在本次收集中清理掉，称为浮动垃圾。CMS收集器默认在老年代使用了68%的空间后被激活。若老年代增长的不是很快，可以适当调高参数-XX:CMSInitiatingOccupancyFraction 提高触发百分比，但调得太高会容易导致“Concurrent Mode Failure”失败。

3. 基于“标记-清除”算法会产生大量空间碎片。提供开关参数-XX:+UseCMSCompactAtFullCollection 用于在“ 享受”完Full GC服务之后进行碎片整理过程，内存整理的过程是无法并发的。但是停顿时间会变长。-XX:CMSFullGCsBeforeCompation 设置在执行多少次不压缩的Full GC后，进行一次带压缩的。

G1垃圾收集器

G1收集器可以在几乎不牺牲吞吐量的前提下完成低停顿的内存回收，这是由于它能够极力避免全区域的垃圾收集，之前的收集器进行收集的范围都是整个新生代或老年代，而G1将整个Java堆（包括新生代、老年代）划分为多个大小固定的独立区域（Region），并且跟踪这些区域里面的垃圾堆积程度，在后台维护一个优先列表，每次根据允许的收集时间，优先回收垃圾最多的区域（这就是Garbage First名称的由来）。区域划分、有优先级的区域回收，保证了G1收集器在有限的时间内可以获得最高的收集效率。与CMS相比有两个显著改进：

1. 基于标记-整理算法实现收集器
2. 非常精确地控制停顿

执行步骤：

1. 初始标记：GC Roots可以直接关联到的对象，并且修改TAMS(Next Top at Mark Start)的值，让下一阶段用户程序并发执行的时候,能在真确可用的Region中创建对象。这阶段需要停顿线程但是很短。
2. 并发标记：从GC Root开始对堆中的对象进行可达性分析，找出存活的对象，可并发执行，耗时长。
3. 最终标记：为了修正上一个标记阶段因为用户线程的运行导致标记变化的部分。需要停顿线程可以并发执行。
4. 筛选回收：对每个Region的回收价值和成本进行排序，按用户期望的GC停顿时间来制定回收计划。

GC触发条件

可以分为2方面新生代Eden区的Minor GC和老年代的Full GC

Minor GC

1. 当Eden区满时，触发Minor GC

Full GC

1. 调用System.gc时，系统建议执行Full GC，但是不必然执行
2. 老年代空间不足
3. 方法区空间不足

JVM常见参数

4种引用类型

类加载过程

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载7个阶段。其中JVM 类加载机制分为五个部分：加载，验证，准备，解析，初始化

加载：这个阶段会在内存中生成一个代表这个类的 java.lang.Class 对 象，作为方法区这个类的各种数据的入口。

验证：确保 Class 文件的字节流中包含的信息是否符合当前虚拟机的要求，并
且不会危害虚拟机自身的安全。

准备：为类变量分配内存并设置类变量的初始值阶段，即在方法区中分配这些变量所使
用的内存空间。

解析：指虚拟机将常量池中的符号引用替换为直接引用的过程。

类加载器

从顶到底分为->启动类加载器->扩展类加载器->应用程序类加载器->自定义类加载器 //前三种是JVM提供的。

1. 启动类加载器负责加载 JAVA_HOME\lib 目录中的，或通过-Xbootclasspath 参数指定路径中的，且被
   虚拟机认可（按文件名识别，如 rt.jar）的类。
2. 扩展类加载器负责加载 JAVA_HOME\lib\ext 目录中的，或通过 java.ext.dirs 系统变量指定路径中的类
   库。
3. 应用程序类加载器 负责加载用户路径（classpath）上的类库。

双亲委派模型

双亲委派的意思是如果一个类加载器需要加载类，那么首先它会把这个类请求委派给父类加载器去完成，每一层都是如此。一直递归到顶层，当父加载器无法完成这个请求时，子类才会尝试去加载。

好处：采用双亲委派的一个好处是比如加载位于 rt.jar 包中的类 java.lang.Object，不管是哪个加载
器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载
器最终得到的都是同样一个 Object 对象。

JVM调优

收集GC信息，结合系统需求，确定优化方案，例如选用合适的GC回收器、重新设置内存比例、调整JVM参数等。

进行调整后，将不同的优化方案分别应用到多台机器上，然后比较这些机器上GC的性能差异，有针对性的做出选择，再通过不断的试验和观察，找到最合适的参数。

什么时候需要调优

1. GC频繁[考虑新生代Eden MinorGC 老年代 Full GC]
2. 单次GC时间过长[STW 一般超过1s]
3. 应用占用CUP过高[需要排查是否有内存泄漏]
4. 堆外内存占用过高导致应用响应慢。

如何调优

GC频繁：

一般新生代的空间不大，Eden区域被填满的时间较快，可以通过增加Eden区域的大小来降低Minor GC的频率。
增加Eden区域的大小是否会导致单次Minor GC时间增加：

Eden区域增加会导致增加了T1(扫描时间),但是T2(复制对象)的时间和存活的对象数有关系，而不是和Eden区域大小有关系，且T2时间远大于T1,所以增加Eden不会显著增加单次GC时间。

Full GC一般指全局GC,而Major GC一般指的是老年代的GC.这在《深入理解JVM虚拟机第二版中》说法是有误的，这里将这2个GC都称为是老年代的GC,在第三版中做了更正。这2中需要根据不同的垃圾收集器CMS OR G1做具体判断，比如设置Region等。

GC时间过长： 处理方式同上需要根据不同垃圾收集器来处理

应用占用CUP过高: 直接排查内存溢出 正对性处理即可.

外部环境导致的响应慢： 适当减少外部应用对服务器内存的占用。

线上CPU过高如何排查

如何确定JVM各区基本参数

分区的大小对GC的性能影响很大。如何将各分区调整到合适的大小，分析活跃数据的大小是很好的切入点。

活跃数据的大小是指，应用程序稳定运行时长期存活对象在堆中占用的空间大小，也就是Full GC后堆中老年代占用空间的大小。可以通过GC日志中Full GC之后老年代数据大小得出，比较准确的方法是在程序稳定后，多次获取GC数据，通过取平均值的方式计算活跃数据的大小。活跃数据和各分区之间的比例关系为：

空间	倍数
总大小	3-4 倍活跃数据的大小
新生代	1-1.5 活跃数据的大小
老年代	2-3 倍活跃数据的大小
永久代	1.2-1.5 倍Full GC后的永久代空间占用

这里只是对初始值进行计算，最终结果根据实际情况进行调优得到。

Major GC和Minor GC频繁 「老年代GC/新生代GC」

服务情况：Minor GC每分钟100次 ，Major GC每4分钟一次，单次Minor GC耗时25ms，单次Major GC耗时200ms，接口响应时间50ms。

由于这个服务要求低延时高可用，结合上文中提到的GC对服务响应时间的影响，计算可知由于Minor GC的发生，12.5%的请求响应时间会增加，其中8.3%的请求响应时间会增加25ms，可见当前GC情况对响应时间影响较大。

（50ms+25ms）× 100次/60000ms = 12.5%，50ms × 100次/60000ms = 8.3% 。

优化目标：降低TP99、TP90时间。

计算公式

单位时间T内发生一次持续25ms的GC，接口平均响应时间为50ms，且请求均匀到达 根据下图所示：

• (50ms+25ms)/T比例的请求会受GC影响，「其中GC前的50ms内到达的请求都会增加25ms，GC期间的25ms内到达的请求，会增加0-25ms不等」
• 如果时间T内发生N次GC，受GC影响请求占比=(接口响应时间+GC时间)×N/T 。
• 可见无论降低单次GC时间还是降低GC次数N都可以有效减少GC对响应时间的影响。

调整过程

首先优化Minor GC频繁问题。通常情况下，由于新生代空间较小，Eden区很快被填满，就会导致频繁Minor GC，因此可以通过增大新生代空间来降低Minor GC的频率。例如在相同的内存分配率的前提下，新生代中的Eden区增加一倍，Minor GC的次数就会减少一半。

这时很多人有这样的疑问，扩容Eden区虽然可以减少Minor GC的次数，但会增加单次Minor GC时间么？根据上面公式，如果单次Minor GC时间也增加，很难保证最后的优化效果。我们结合下面情况来分析，单次Minor GC时间主要受哪些因素影响？是否和新生代大小存在线性关系？ 首先，单次Minor GC时间由以下两部分组成：T1（扫描新生代）和 T2（复制存活对象到Survivor区）如下图。（注：这里为了简化问题，我们认为T1只扫描新生代判断对象是否存活的时间，其实该阶段还需要扫描部分老年代，后面案例中有详细描述。）

扩容前：新生代容量为R ，假设对象A的存活时间为750ms，Minor GC间隔500ms，那么本次Minor GC时间= T1（扫描新生代R）+T2（复制对象A到S）。

扩容后：新生代容量为2R ，对象A的生命周期为750ms，那么Minor GC间隔增加为1000ms，此时Minor GC对象A已不再存活，不需要把它复制到Survivor区，那么本次GC时间 = 2 × T1（扫描新生代R），没有T2复制时间。

可见，扩容后，Minor GC时增加了T1（扫描时间），但省去T2（复制对象）的时间，更重要的是对于虚拟机来说，复制对象的成本要远高于扫描成本，所以，单次Minor GC时间更多取决于GC后存活对象的数量，而非Eden区的大小。因此如果堆中短期对象很多，那么扩容新生代，单次Minor GC时间不会显著增加。下面需要确认下服务中对象的生命周期分布情况：

通过上图GC日志中两处红色框标记内容可知： 1. new threshold = 2（动态年龄判断，对象的晋升年龄阈值为2），对象仅经历2次Minor GC后就晋升到老年代，这样老年代会迅速被填满，直接导致了频繁的Major GC。 2. Major GC后老年代使用空间为300M+，意味着此时绝大多数(86% = 2G/2.3G)的对象已经不再存活，也就是说生命周期长的对象占比很小。

由此可见，服务中存在大量短期临时对象，扩容新生代空间后，Minor GC频率降低，对象在新生代得到充分回收，只有生命周期长的对象才进入老年代。这样老年代增速变慢，Major GC频率自然也会降低。

优化结果
通过扩容新生代为为原来的三倍，单次Minor GC时间增加小于5ms，频率下降了60%，服务响应时间TP90，TP99都下降了10ms+，服务可用性得到提升。
小结
如何选择各分区大小应该依赖应用程序中对象生命周期的分布情况：如果应用存在大量的短期对象，应该选择较大的年轻代；如果存在相对较多的持久对象，老年代应该适当增大。
更多思考
关于上文中提到晋升年龄阈值为2，很多同学有疑问，为什么设置了MaxTenuringThreshold=15，对象仍然仅经历2次Minor GC，就晋升到老年代？这里涉及到“动态年龄计算”的概念。

动态年龄计算：Hotspot遍历所有对象时，按照年龄从小到大对其所占用的大小进行累积，当累积的某个年龄大小超过了survivor区的一半时，取这个年龄和MaxTenuringThreshold中更小的一个值，作为新的晋升年龄阈值。在本案例中，调优前：Survivor区 = 64M，desired survivor = 32M，此时Survivor区中age<=2的对象累计大小为41M，41M大于32M，所以晋升年龄阈值被设置为2，下次Minor GC时将年龄超过2的对象被晋升到老年代。

JVM引入动态年龄计算，主要基于如下两点考虑：

如果固定按照MaxTenuringThreshold设定的阈值作为晋升条件： a）MaxTenuringThreshold设置的过大，原本应该晋升的对象一直停留在Survivor区，直到Survivor区溢出，一旦溢出发生，Eden+Svuvivor中对象将不再依据年龄全部提升到老年代，这样对象老化的机制就失效了。 b）MaxTenuringThreshold设置的过小，“过早晋升”即对象不能在新生代充分被回收，大量短期对象被晋升到老年代，老年代空间迅速增长，引起频繁的Major GC。分代回收失去了意义，严重影响GC性能。

相同应用在不同时间的表现不同：特殊任务的执行或者流量成分的变化，都会导致对象的生命周期分布发生波动，那么固定的阈值设定，因为无法动态适应变化，会造成和上面相同的问题。

总结来说，为了更好的适应不同程序的内存情况，虚拟机并不总是要求对象年龄必须达到Maxtenuringthreshhold再晋级老年代。

请求高峰期发生GC，导致服务可用性下降

确定目标
GC日志显示，高峰期CMS在重标记（Remark）阶段耗时1.39s。Remark阶段是Stop-The-World（以下简称为STW）的，即在执行垃圾回收时，Java应用程序中除了垃圾回收器线程之外其他所有线程都被挂起，意味着在此期间，用户正常工作的线程全部被暂停下来，这是低延时服务不能接受的。本次优化目标是降低Remark时间。

优化
解决问题前，先回顾一下CMS的四个主要阶段，以及各个阶段的工作内容。下图展示了CMS各个阶段可以标记的对象，用不同颜色区分。

1. Init-mark初始标记(STW) ，该阶段进行可达性分析，标记GC ROOT能直接关联到的对象，所以很快。
2. Concurrent-mark并发标记，由前阶段标记过的绿色对象出发，所有可到达的对象都在本阶段中标记。
3. Remark重标记(STW) ，暂停所有用户线程，重新扫描堆中的对象，进行可达性分析，标记活着的对象。因为并发标记阶段是和用户线程并发执行的过程，所以该过程中可能有用户线程修改某些活跃对象的字段，指向了一个未标记过的对象，如下图中红色对象在并发标记开始时不可达，但是并行期间引用发生变化，变为对象可达，这个阶段需要重新标记出此类对象，防止在下一阶段被清理掉，这个过程也是需要STW的。特别需要注意一点，这个阶段是以新生代中对象为根来判断对象是否存活的。
4. 并发清理，进行并发的垃圾清理。
   
   Remark阶段主要是通过扫描堆来判断对象是否存活。那么准确判断对象是否存活，需要扫描哪些对象？CMS对老年代做回收，Remark阶段仅扫描老年代是否可行？结论是不可行，原因如下：
   如果仅扫描老年代中对象，即以老年代中对象为根，判断对象是否存在引用，上图中，对象A因为引用存在新生代中，它在Remark阶段就不会被修正标记为可达，GC时会被错误回收。 新生代对象持有老年代中对象的引用，这种情况称为“跨代引用”。因它的存在，Remark阶段必须扫描整个堆来判断对象是否存活，包括图中灰色的不可达对象。

灰色对象已经不可达，但仍然需要扫描的原因：新生代GC和老年代的GC是各自分开独立进行的，只有Minor GC时才会使用根搜索算法，标记新生代对象是否可达，也就是说虽然一些对象已经不可达，但在Minor GC发生前不会被标记为不可达，CMS也无法辨认哪些对象存活，只能全堆扫描（新生代+老年代）。由此可见堆中对象的数目影响了Remark阶段耗时。 分析GC日志可以得出同样的规律，Remark耗时>500ms时，新生代使用率都在75%以上。这样降低Remark阶段耗时问题转换成如何减少新生代对象数量。

新生代中对象的特点是“朝生夕灭”，这样如果Remark前执行一次Minor GC，大部分对象就会被回收。CMS就采用了这样的方式，在Remark前增加了一个可中断的并发预清理（CMS-concurrent-abortable-preclean），该阶段主要工作仍然是并发标记对象是否存活，只是这个过程可被中断。此阶段在Eden区使用超过2M时启动，当然2M是默认的阈值，可以通过参数修改。如果此阶段执行时等到了Minor GC，那么上述灰色对象将被回收，Reamark阶段需要扫描的对象就少了。

除此之外CMS为了避免这个阶段没有等到Minor GC而陷入无限等待，提供了参数CMSMaxAbortablePrecleanTime ，默认为5s，含义是如果可中断的预清理执行超过5s，不管发没发生Minor GC，都会中止此阶段，进入Remark。 根据GC日志红色标记2处显示，可中断的并发预清理执行了5.35s，超过了设置的5s被中断，期间没有等到Minor GC ，所以Remark时新生代中仍然有很多对象。

对于这种情况，CMS提供CMSScavengeBeforeRemark参数，用来保证Remark前强制进行一次Minor GC。

优化结果
经过增加CMSScavengeBeforeRemark参数，单次执行时间>200ms的GC停顿消失，从监控上观察，GCtime和业务波动保持一致，不再有明显的毛刺。
小结
通过案例分析了解到，由于跨代引用的存在，CMS在Remark阶段必须扫描整个堆，同时为了避免扫描时新生代有很多对象，增加了可中断的预清理阶段用来等待Minor GC的发生。只是该阶段有时间限制，如果超时等不到Minor GC，Remark时新生代仍然有很多对象，我们的调优策略是，通过参数强制Remark前进行一次Minor GC，从而降低Remark阶段的时间。

更多思考
案例中只涉及老年代GC，其实新生代GC存在同样的问题，即老年代可能持有新生代对象引用，所以Minor GC时也必须扫描老年代。

JVM是如何避免Minor GC时扫描全堆的？ 经过统计信息显示，老年代持有新生代对象引用的情况不足1%，根据这一特性JVM引入了卡表（card table）来实现这一目的。
卡表的具体策略是将老年代的空间分成大小为512B的若干张卡（card）。卡表本身是单字节数组，数组中的每个元素对应着一张卡，当发生老年代引用新生代时，虚拟机将该卡对应的卡表元素设置为适当的值。如上图所示，卡表3被标记为脏（卡表还有另外的作用，标识并发标记阶段哪些块被修改过），之后Minor GC时通过扫描卡表就可以很快的识别哪些卡中存在老年代指向新生代的引用。这样虚拟机通过空间换时间的方式，避免了全堆扫描。

总结来说，CMS的设计聚焦在获取最短的时延，为此它“不遗余力”地做了很多工作，包括尽量让应用程序和GC线程并发、增加可中断的并发预清理阶段、引入卡表等，虽然这些操作牺牲了一定吞吐量但获得了更短的回收停顿时间。

发生Stop-The-World的GC

GC日志如下图（在GC日志中，Full GC是用来说明这次垃圾回收的停顿类型，代表STW类型的GC，并不特指老年代GC），根据GC日志可知本次Full GC耗时1.23s。这个在线服务同样要求低时延高可用。本次优化目标是降低单次STW回收停顿时间，提高可用性。

优化
首先，什么时候可能会触发STW的Full GC呢？ 1. Perm空间不足； 2. CMS GC时出现promotion failed和concurrent mode failure（concurrent mode failure发生的原因一般是CMS正在进行，但是由于老年代空间不足，需要尽快回收老年代里面的不再被使用的对象，这时停止所有的线程，同时终止CMS，直接进行Serial Old GC）； 3. 统计得到的Young GC晋升到老年代的平均大小大于老年代的剩余空间； 4. 主动触发Full GC（执行jmap -histo:live [pid]）来避免碎片问题。

然后，我们来逐一分析一下： - 排除原因2：如果是原因2中两种情况，日志中会有特殊标识，目前没有。 - 排除原因3：根据GC日志，当时老年代使用量仅为20%，也不存在大于2G的大对象产生。 - 排除原因4：因为当时没有相关命令执行。 - 锁定原因1：根据日志发现Full GC后，Perm区变大了，推断是由于永久代空间不足容量扩展导致的。

找到原因后解决方法有两种： 1. 通过把-XX:PermSize参数和-XX:MaxPermSize设置成一样，强制虚拟机在启动的时候就把永久代的容量固定下来，避免运行时自动扩容。 2. CMS默认情况下不会回收Perm区，通过参数CMSPermGenSweepingEnabled、CMSClassUnloadingEnabled ，可以让CMS在Perm区容量不足时对其回收。

由于该服务没有生成大量动态类，回收Perm区收益不大，所以我们采用方案1，启动时将Perm区大小固定，避免进行动态扩容。

优化结果
调整参数后，服务不再有Perm区扩容导致的STW GC发生。