< div style = "color:#16b0ff;font-size:50px;font-weight: 900;text-shadow: 5px 5px 10px var(--theme-color);font-family: 'Comic Sans MS';" > JVM< / div >
< span style = "color:#16b0ff;font-size:20px;font-weight: 900;font-family: 'Comic Sans MS';" > Introduction< / span > ： ！
[TOC]
https://mp.weixin.qq.com/s?__biz=MzI4NjI1OTI4Nw==& mid=2247489183& idx=1& sn=02ab3551c473bd2c8429862e3689a94b& chksm=ebdef7a7dca97eb17194c3d935c86ade240d3d96bbeaf036233a712832fb94af07adeafa098b& mpshare=1& scene=23& srcid=0812OQ78gD47QJEguFGixUVa& sharer_sharetime=1628761112690& sharer_shareid=0f9991a2eb945ab493c13ed9bfb8bf4b#rd
# Classloader
## 类加载机制
JVM把描述类的数据加载到内存里面， ， ： （ ） （ ） （ ）
类加载过程如下：
- 加载。加载分为三步：
- 通过类的全限定性类名获取该类的二进制流
- 将该二进制流的静态存储结构转为方法区的运行时数据结构
- 在堆中为该类生成一个class对象
- 验证： ，
- 准备： ，
- 解析：该阶段主要完成符号引用转化成直接引用
- 初始化： ， ；
## 类加载器
虚拟机设计团队把加载动作放到 JVM 外部实现， ，
- **启动类加载器(Bootstrap ClassLoader)**
** 用来加载java核心类库， ）
- **扩展类加载器(Extension ClassLoader)**
** 用来加载java的扩展库， ，
- **应用程序类加载器(Application ClassLoader)**
** 它根据java的类路径来加载类， ， （ ） ，
- **自定义类加载器(User ClassLoader)**
由JAVA语言实现，
此外我们比较需要知道的几点：
- 一个类是由 jvm 加载是通过类加载器+全限定类名确定唯一性的
- 双亲委派，众所周知，子加载器会尽量委托给父加载器进行加载，父加载器找不到再自己加载
- 线程上下文类加载，为了满足 spi 等需求突破双亲委派机制，当高层类加载器想加载底层类时通过 Thread.contextClassLoader 来获取当前线程的类加载器(往往是底层类加载器)去加载类
## 双亲委派
当一个类加载器收到一个类加载的请求，他首先不会尝试自己去加载，而是将这个请求委派给父类加载器去加载，只有父类加载器在自己的搜索范围类查找不到给类时，子加载器才会尝试自己去加载该类。
所有的加载请求都会传送到根加载器去加载，只有当父加载器无法加载时，子类加载器才会去加载：
**为什么需要双亲委派模型？**
为了防止内存中出现多个相同的字节码。因为如果没有双亲委派的话， ，
**那怎么打破双亲委派模型？**
自定义类加载器， ，
**双亲委派模型的作用**
- 避免类的重复加载
- 保证Java核心类库的安全
# JVM
## JAVA内存模型
Java虚拟机规范中试图定义一种Java内存模型（ ， ） ，
JMM描述了Java程序中各种变量（ ） ， ， ， （ ） ：
- **线程对共享变量的所有操作都必须在自己的工作内存中进行，不能直接从主内存中读写**
- **不同的线程之间无法直接访问其他线程工作内存中的变量，线程变量值的传递需要通过主内存来完成**
**Java 内存模型**（下文简称 **JMM** ）就是在底层处理器内存模型的基础上，定义自己的多线程语义。它明确指定了一组排序规则，来保证线程间的可见性。这一组规则被称为 **Happens-Before** , JMM 规定，要想保证 B 操作能够看到 A 操作的结果（无论它们是否在同一个线程），那么 A 和 B 之间必须满足 **Happens-Before 关系** ：
- **单线程规则**：一个线程中的每个动作都 happens-before 该线程中后续的每个动作
- **监视器锁定规则**：监听器的**解锁**动作 happens-before 后续对这个监听器的**锁定**动作
- **volatile 变量规则**：对 volatile 字段的写入动作 happens-before 后续对这个字段的每个读取动作
- **线程 start 规则**：线程 **start()** 方法的执行 happens-before 一个启动线程内的任意动作
- **线程 join 规则**：一个线程内的所有动作 happens-before 任意其他线程在该线程 **join()** 成功返回之前
- **传递性**：如果 A happens-before B, 且 B happens-before C, 那么 A happens-before C
## JVM内存结构
JVM包含**堆**、**元空间**、**Java虚拟机栈**、**本地方法栈**、**程序计数器**等内存区域，其中**堆**是占用内存最大的，如下图所示：
**JVM常量池**
JVM常量池主要分为**Class文件常量池、运行时常量池、全局字符串常量池、以及基本类型包装类对象常量池**。
- **Class文件常量池**： ， ， ，
- **运行时常量池**： ， ， ， ，
- **全局字符串常量池**： ， ， ， ，
- **基本类型包装类对象常量池**： ， ，
## JVM内存模型
JVM试图定义一种统一的内存模型， ，
**线程隔离数据区：**
- **程序计数器：** 一块较小的内存空间，存储当前线程所执行的字节码行号指示器
- **虚拟机栈：** 里面的元素叫栈帧，存储 ** 局部变量表、操作栈、动态链接、方法返回地址** 等
- **本地方法栈：** 为虚拟机使用到的本地Native方法服务时的栈帧，
**线程共享数据区：**
- **方法区：** 存储已被虚拟机加载的**类信息、常量、静态变量、即时编译器编译后的代码**等数据
- **堆：** 唯一目的就是存放**对象的实例**，是垃圾回收管理器的主要区域
- **元数据区**：常量池、方法元信息、
### 程序计数器
程序计数器（ ） ， ， ， ； ，
- 当前线程私有
- 当前线程所执行的字节码的行号指示器
- 不会出现OutOfMemoryError情况
- 以一种数据结构的形式放置于内存中
**注意**：程序计数器是唯一一个不会出现 `OutOfMemoryError` 的内存区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡。
### JAVA虚拟机栈
JAVA虚拟机栈（ ） ， ， ， ， ， ， （ ） ， ，
- 线程私有，生命周期与线程相同
- java方法执行的内存模型， ，
- `StackOverflowError` ：当线程请求的栈深度大于虚拟机所允许的深度
- `OutOfMemoryError` ：如果栈的扩展时无法申请到足够的内存
> **相关参数：**
>
> -Xss：
### 本地方法栈
本地方法栈（ ） ， （ ） ， ，
### 方法区
方法区（ ）
- **又称之为： （ ）
- **线程共享**
- **主要存储： （ ）
- **Java虚拟机规范规定： ，
> **相关参数：**
>
> -XX:PermSize：
>
> -XX:MaxPermSize：
### 堆内存
堆内存（ ） ， ** 新生代**(Eden区、From Survivor 区和 To Survivor 区)和老年代。
- **线程共享**
- **主要用于存储JAVA实例或对象**
- **GC发生的主要区域**
- **是Java虚拟机所管理的内存中最大的一块**
- **当堆中没有内存能完成实例分配， ，
> **相关参数：**
>
> -Xms：
>
> -Xmx：
>
> -XX:MaxTenuringThreshold：
>
> -XX:PretenureSizeThreshold：
>
> **新生代相关参数**（注意：当新生代设置得太小时，也可能引发大对象直接分配到旧生代）：
>
> -Xmn：
>
> -XX:SurvivorRatio：
## JVM运行时内存
JVM运行时内存又称堆内存(Heap)。Java 堆从 GC 的角度还可以细分为: 新生代(Eden 区、From Survivor 区和 To Survivor 区)和老年代。
当代主流虚拟机（ ） ： ， ， ，
**一个对象从出生到消亡**
一个对象产生之后首先进行栈上分配， ， ， ， ， ，
### 新生代（ ）
**主要是用来存放新生的对象**。一般占据堆的1/3空间。由于频繁创建对象，
- **Eden区**： （ ， ） ，
- **ServivorTo**：
- **ServivorFrom**： ，
**MinorGC流程**
- **MinorGC采用复制算法**
- 首先把Eden和ServivorFrom区域中存活的对象复制到ServicorTo区域（ ， ） ， （ ）
- 然后清空Eden和ServicorFrom中的对象
- 最后ServicorTo和ServicorFrom互换，
**为什么 Survivor 分区不能是 0 个？**
如果 Survivor 是 0 的话，也就是说新生代只有一个 Eden 分区，每次垃圾回收之后，存活的对象都会进入老生代，这样老生代的内存空间很快就被占满了，从而触发最耗时的 Full GC ，显然这样的收集器的效率是我们完全不能接受的。
**为什么 Survivor 分区不能是 1 个？**
如果 Survivor 分区是 1 个的话，假设我们把两个区域分为 1:1， ，
但如果设置内存空间的比例是 8:2 ，只是看起来似乎“很好”，假设新生代的内存为 100 MB（ ， ， ，
**为什么 Survivor 分区是 2 个？**
如果Survivor分区有2个分区， ， ， ， ， ， ， （
**总结**
根据上面的分析可以得知，当新生代的 Survivor 分区为 2 个的时候，不论是空间利用率还是程序运行的效率都是最优的，所以这也是为什么 Survivor 分区是 2 个的原因了。
### 老年代（ ）
**主要存放应用程序中生命周期长的内存对象**。老年代的对象比较稳定， ， ，
**MajorGC流程**
MajorGC采用标记—清除算法。首先扫描一次所有老年代， ， ， ， ， ， （ ）
### 永久区（ ）
指内存的永久保存区域，**主要存放元数据**， ， ， ， ，
**JAVA8与元数据**
在Java8中， ， （ ） ， ： ， ， ， ， ，
### 内存分配策略
堆内存常见的分配测试如下：
- 对象优先在Eden区分配
- 大对象直接进入老年代
- 长期存活的对象将进入老年代
| ** 参数** | ** 说明信息** |
| :------------------------------ | ------------------------------------------------------------ |
| -Xms | 初始堆大小。如：-Xms256m |
| -Xmx | 最大堆大小。如：-Xmx512m |
| -Xmn | 新生代大小。通常为Xmx的1/3或1/4。新生代=Eden+2个Survivor空间。实际可用空间为=Eden+1个Survivor，
| -Xss | JDK1.5+每个线程堆栈大小为 1M， ，
| -XX:NewRatio | 新生代与老年代的比例。如– ， ，
| -XX:SurvivorRatio | 新生代中Eden与Survivor的比值。默认值为 8， ，
| -XX:PermSize | 永久代（方法区）的初始大小 |
| -XX:MaxPermSize | 永久代（方法区）的最大值 |
| -XX:+PrintGCDetails | 打印GC信息 |
| -XX:+HeapDumpOnOutOfMemoryError | 让虚拟机在发生内存溢出时Dump出当前的内存堆转储快照，
**参数基本策略**
各分区的大小对GC的性能影响很大。如何将各分区调整到合适的大小，
**活跃数据的大小**： ，
可以通过GC日志中Full GC之后老年代数据大小得出， ， ， ：
| 空间 | 倍数 |
| ------ | --------------------------------------- |
| 总大小 | **3-4** 倍活跃数据的大小 |
| 新生代 | **1-1.5** 活跃数据的大小 |
| 老年代 | **2-3** 倍活跃数据的大小 |
| 永久代 | **1.2-1.5** 倍Full GC后的永久代空间占用 |
例如， ， ：
> 总堆： ×
>
> 新生代： ×
>
> 老年代： 750MB = 1200MB - 450MB
这部分设置仅仅是堆大小的初始值，后面的优化中，可能会调整这些值，具体情况取决于应用程序的特性和需求。
## 引用级别
Java中4种引用的级别和强度由高到低依次为：
当**垃圾回收器**回收时，某些对象会被回收，某些不会被回收。垃圾回收器会从**根对象**`Object`来**标记**存活的对象，然后将某些不可达的对象和一些引用的对象进行回收。如下所示：
| 引用类型 | 被垃圾回收时间 | 用途 | 生存时间 |
| -------- | -------------- | ------------------ | ----------------- |
| 强引用 | 从来不会 | 对象的一般状态 | JVM停止运行时终止 |
| 软引用 | 当内存不足时 | 对象缓存 | 内存不足时终止 |
| 弱引用 | 正常垃圾回收时 | 对象缓存 | 垃圾回收后终止 |
| 虚引用 | 正常垃圾回收时 | 跟踪对象的垃圾回收 | 垃圾回收后终止 |
### 强引用（ ）
强引用是我们最常见的对象， ， （ ） ， ，
```java
Object strongReference = new Object();
```
当**内存空间不足**时，`Java`虚拟机宁愿抛出`OutOfMemoryError`错误，使程序**异常终止**，也不会靠随意**回收**具有**强引用**的**对象**来解决内存不足的问题。 如果强引用对象**不使用时**，需要弱化从而使`GC`能够回收，如下：
```java
strongReference = null;
```
显式地设置`strongReference`对象为`null`，或让其**超出**对象的**生命周期**范围，则`gc`认为该对象**不存在引用**，这时就可以回收这个对象。具体什么时候收集这要取决于`GC`算法。
```java
public void test() {
Object strongReference = new Object();
// 省略其他操作
}
```
在一个**方法的内部**有一个**强引用**，这个引用保存在`Java`**栈**中，而真正的引用内容(`Object`)保存在`Java`**堆**中。 当这个**方法运行完成**后，就会退出**方法栈**，则引用对象的**引用数**为`0`，这个对象会被回收。但是如果这个`strongReference`是**全局变量**时，就需要在不用这个对象时赋值为`null`，因为**强引用**不会被垃圾回收。
### 软引用（ ）
如果一个对象只具有**软引用**，则**内存空间充足**时，**垃圾回收器**就**不会**回收它；如果**内存空间不足**了，就会**回收**这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。
```java
// 强引用
String strongReference = new String("abc");
// 软引用
String str = new String("abc");
SoftReference< String > softReference = new SoftReference< String > (str);
```
**软引用**可以和一个**引用队列**(`ReferenceQueue`)联合使用。如果**软引用**所引用对象被**垃圾回收**，
```java
ReferenceQueue< String > referenceQueue = new ReferenceQueue< >();
String str = new String("abc");
SoftReference< String > softReference = new SoftReference< >(str, referenceQueue);
```
**注意**： ， ， ，
**垃圾收集线程**会在虚拟机抛出`OutOfMemoryError`之前回**收软引用对象**，而**虚拟机**会尽可能优先回收**长时间闲置不用**的**软引用对象**。对那些**刚构建**的或刚使用过的**"较新的"**软对象会被虚拟机尽可能**保留**，这就是引入**引用队列**`ReferenceQueue`的原因。
### 弱引用（ ）
弱引用对象相对软引用对象具有更短暂的生命周期，只要 GC 发现它仅有弱引用，不管内存空间是否充足，都会回收它，不过 GC 是一个优先级很低的线程，因此不一定会很快发现那些仅有弱引用的对象。
**弱引用**与**软引用**的区别在于：只具有**弱引用**的对象拥有**更短暂**的**生命周期**。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有**弱引用**的对象，不管当前**内存空间足够与否**，都会**回收**它的内存。不过，由于垃圾回收器是一个**优先级很低的线程**，因此**不一定**会**很快**发现那些只具有**弱引用**的对象。
```java
String str = new String("abc");
WeakReference< String > weakReference = new WeakReference< >(str);
str = null;
```
`JVM` 首先将**软引用**中的**对象**引用置为`null`，然后通知**垃圾回收器**进行回收：
```java
str = null;
System.gc();
```
**注意**：如果一个对象是偶尔(很少)的使用， ， ，
下面的代码会让一个**弱引用**再次变为一个**强引用**：
```java
String str = new String("abc");
WeakReference< String > weakReference = new WeakReference< >(str);
// 弱引用转强引用
String strongReference = weakReference.get();
```
同样，**弱引用**可以和一个**引用队列**(`ReferenceQueue`)联合使用，如果**弱引用**所引用的**对象**被**垃圾回收**，
### 虚引用（ ）
**虚引用**顾名思义，就是**形同虚设**。与其他几种引用都不同，**虚引用**并**不会**决定对象的**生命周期**。如果一个对象**仅持有虚引用**，那么它就和**没有任何引用**一样，在任何时候都可能被垃圾回收器回收。
**应用场景：**
**虚引用**主要用来**跟踪对象**被垃圾回收器**回收**的活动。 ** 虚引用**与**软引用**和**弱引用**的一个区别在于：
> 虚引用必须和引用队列(ReferenceQueue)联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。
```java
String str = new String("abc");
ReferenceQueue queue = new ReferenceQueue();
// 创建虚引用，要求必须与一个引用队列关联
PhantomReference pr = new PhantomReference(str, queue);
```
程序可以通过判断引用**队列**中是否已经加入了**虚引用**，来了解被引用的对象是否将要进行**垃圾回收**。如果程序发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的**内存被回收之前**采取必要的行动。
## OOM
JVM发生OOM的九种场景如下：
**场景一：
> 当堆内存（ ） ，
>
> **原因分析**
>
> `Javaheap space` 错误产生的常见原因可以分为以下几类：
>
> - 请求创建一个超大对象，通常是一个大数组
> - 超出预期的访问量/数据量，通常是上游系统请求流量飙升，常见于各类促销/秒杀活动，可以结合业务流量指标排查是否有尖状峰值
> - 过度使用终结器（ ） ，
> - 内存泄漏（ ） ， ，
>
> **解决方案**
>
> 针对大部分情况，通常只需通过 `-Xmx` 参数调高 JVM 堆内存空间即可。如果仍然没有解决，可参考以下情况做进一步处理：
>
> - 如果是超大对象，可以检查其合理性，比如是否一次性查询了数据库全部结果，而没有做结果数限制
> - 如果是业务峰值压力，可以考虑添加机器资源，或者做限流降级
> - 如果是内存泄漏，需要找到持有的对象，修改代码设计，比如关闭没有释放的连接
**场景二：
> 当 Java 进程花费 98% 以上的时间执行 GC，
>
> 此类问题的原因与解决方案跟 `Javaheap space` 非常类似，可以参考上文。
**场景三：
> 该错误表示永久代（ ） ，
>
> **原因分析**
>
> 永久代存储对象主要包括以下几类：
>
> - 加载/缓存到内存中的 class 定义，包括类的名称，字段，方法和字节码
> - 常量池
> - 对象数组/类型数组所关联的 class
> - JIT 编译器优化后的 class 信息
>
> PermGen 的使用量与加载到内存的 class 的数量/大小正相关。
>
> **解决方案**
>
> 根据 Permgen space 报错的时机，可以采用不同的解决方案，如下所示：
>
> - 程序启动报错，修改 `-XX:MaxPermSize` 启动参数，调大永久代空间
> - 应用重新部署时报错，很可能是没有应用没有重启，导致加载了多份 class 信息，只需重启 JVM 即可解决
> - 运行时报错，应用程序可能会动态创建大量 class， ，
>
> 如果上述方法无法解决，可以通过 jmap 命令 dump 内存对象 `jmap-dump:format=b,file=dump.hprof<process-id>` ，然后利用 Eclipse MAT https://www.eclipse.org/mat 功能逐一分析开销最大的 classloader 和重复 class。
**场景四：
> JDK 1.8 使用 Metaspace 替换了永久代（ ） ，
>
> 此类问题的原因与解决方法跟 `Permgenspace` 非常类似，可以参考上文。需要特别注意的是调整 Metaspace 空间大小的启动参数为 `-XX:MaxMetaspaceSize`。
**场景五：
> 每个 Java 线程都需要占用一定的内存空间，当 JVM 向底层操作系统请求创建一个新的 native 线程时，如果没有足够的资源分配就会报此类错误。
>
> **原因分析**
>
> JVM 向 OS 请求创建 native 线程失败，就会抛出 `Unableto createnewnativethread`，常见的原因包括以下几类：
>
> - 线程数超过操作系统最大线程数 ulimit 限制
> - 线程数超过 kernel.pid_max（ ）
> - native 内存不足
>
> 该问题发生的常见过程主要包括以下几步：
>
> - JVM 内部的应用程序请求创建一个新的 Java 线程
> - JVM native 方法代理了该次请求，并向操作系统请求创建一个 native 线程
> - 操作系统尝试创建一个新的 native 线程，并为其分配内存
> - 如果操作系统的虚拟内存已耗尽，或是受到 32 位进程的地址空间限制，操作系统就会拒绝本次 native 内存分配
> - JVM 将抛出 `java.lang.OutOfMemoryError:Unableto createnewnativethread`错误
>
> **解决方案**
>
> - 升级配置，为机器提供更多的内存
> - 降低 Java Heap Space 大小
> - 修复应用程序的线程泄漏问题
> - 限制线程池大小
> - 使用 -Xss 参数减少线程栈的大小
> - 调高 OS 层面的线程最大数：执行 `ulimia-a` 查看最大线程数限制，使用 `ulimit-u xxx` 调整最大线程数限制
**场景六： ？
> 该错误表示所有可用的虚拟内存已被耗尽。虚拟内存（ ） （ ） （ ）
>
> **原因分析**
>
> 该错误出现的常见原因包括以下几类：
>
> - 地址空间不足
> - 物理内存已耗光
> - 应用程序的本地内存泄漏（ ） ， ，
> - 执行 `jmap-histo:live<pid>` 命令，强制执行 Full GC； ，
>
> **解决方案**
>
> 根据错误原因可以采取如下解决方案：
>
> - 升级地址空间为 64 bit
> - 使用 Arthas 检查是否为 Inflater/Deflater 解压缩问题，如果是，则显式调用 end 方法
> - Direct ByteBuffer 问题可以通过启动参数 `-XX:MaxDirectMemorySize` 调低阈值
> - 升级服务器配置/隔离部署，避免争用
**场景七：
> 有一种内核作业（ ） ， （ ） ，
>
> **原因分析**
>
> 默认情况下， ， ， ，
>
> **解决方案**
>
> - 升级服务器配置/隔离部署，避免争用
> - OOM Killer 调优
**场景八：
> JVM 限制了数组的最大长度，
>
> 此类问题比较罕见，通常需要检查代码，确认业务是否需要创建如此大的数组，是否可以拆分为多个块，分批执行。
**场景九：
> Java 允许应用程序通过 Direct ByteBuffer 直接访问堆外内存，许多高性能程序通过 Direct ByteBuffer 结合内存映射文件（ ）
>
> **原因分析**
>
> Direct ByteBuffer 的默认大小为 64 MB， ，
>
> **解决方案**
>
> - Java 只能通过 ByteBuffer.allocateDirect 方法使用 Direct ByteBuffer， ，
> - 检查是否直接或间接使用了 NIO， ，
> - 通过启动参数 `-XX:MaxDirectMemorySize` 调整 Direct ByteBuffer 的上限值
> - 检查 JVM 参数是否有 `-XX:+DisableExplicitGC` 选项，如果有就去掉，因为该参数会使 `System.gc()` 失效
> - 检查堆外内存使用代码，确认是否存在内存泄漏；或者通过反射调用 `sun.misc.Cleaner` 的 `clean()` 方法来主动释放被 Direct ByteBuffer 持有的内存空间
> - 内存容量确实不足，升级配置
**最佳实践**
> ① OOM发生时输出堆dump：
>
> `-XX:+HeapDumpOnOutOfMemoryError` `-XX:HeapDumpPath=$CATALINA_HOME/logs`
>
> ② OOM发生后的执行动作：
>
> `-XX:OnOutOfMemoryError=$CATALINA_HOME/bin/stop.sh`
>
> `-XX:OnOutOfMemoryError=$CATALINA_HOME/bin/restart.sh`
>
> OOM之后除了保留堆dump外，
# GC
## 寻找垃圾算法
### 引用计数法
引用计数法（ ） ， ，
当图中的数值变成0时， ， ， ， ， ， ：
这个时候就需要使用到我们的根可达算法。
### 可达性分析
根可达算法（ ） ， ， ， ， ：
- **线程栈变量：** 线程里面会有线程栈和main栈帧，
- **静态变量：** 一个class 它有一个静态的变量， ，
- **常量池：** 如果你这个class会用到其他的class的那些个类的对象，
- **JNI：
图中的 object5 和object6 虽然他们之间互相引用了， ， ， ， ， ，
**GC Root**
GC Roots 是一组必须活跃的引用。用通俗的话来说， ，
- **Java 线程中，当前所有正在被调用的方法的引用类型参数、局部变量、临时值等。也就是与我们栈帧相关的各种引用**
- **所有当前被加载的 Java 类**
- **Java 类的引用类型静态变量**
- **运行时常量池里的引用类型常量（
- **JVM 内部数据结构的一些引用，比如 sun.jvm.hotspot.memory.Universe 类**
- **用于同步的监控对象，比如调用了对象的 wait() 方法**
- **JNI handles，
GC Roots 大体可以分为三大类：
- **活动线程相关的各种引用**
- **类的静态变量的引用**
- **JNI 引用**
## 清理垃圾算法
清理垃圾算法又叫内存回收算法。
### 标记（ ）
垃圾回收的第一步，就是找出活跃的对象。根据 GC Roots 遍历所有的可达对象，这个过程，就叫作标记。
如图所示，圆圈代表的是对象。绿色的代表 GC Roots， ， ，
### 清除（ ）
清除阶段就是把未被标记的对象回收掉。
但是这种简单的清除方式，有一个明显的弊端，那就是碎片问题。比如我申请了 1k、2k、3k、4k、5k 的内存。
由于某种原因 ，
这个时候，我应该有足足 6k 的空闲空间。接下来，我打算申请另外一个 5k 的空间，结果系统告诉我内存不足了。系统运行时间越长，这种碎片就越多。在很久之前使用 Windows 系统时，有一个非常有用的功能，就是内存整理和磁盘整理，运行之后有可能会显著提高系统性能。这个出发点是一样的。
### 复制（ ）
算法.png)
**优点**
- 因为是对整个半区进行内存回收，内存分配时不用考虑内存碎片等情况。实现简单，效率较高
**不足之处**
- 既然要复制，需要提前预留内存空间，有一定的浪费
- 在对象存活率较高时，需要复制的对象较多，效率将会变低
### 整理（ ）
其实，不用分配一个对等的额外空间，也是可以完成内存的整理工作。可以把内存想象成一个非常大的数组，根据随机的 index 删除了一些数据。那么对整个数组的清理，其实是不需要另外一个数组来进行支持的，使用程序就可以实现。它的主要思路，就是移动所有存活的对象，且按照内存地址顺序依次排列，然后将末端内存地址以后的内存全部回收。
但是需要注意，这只是一个理想状态。对象的引用关系一般都是非常复杂的，我们这里不对具体的算法进行描述。你只需要了解，从效率上来说，一般整理算法是要低于复制算法的。
### 扩展回收算法
https://juejin.cn/post/6896035896916148237
目前JVM的垃圾回收器都是对几种朴素算法的发扬光大（ ， ） ：
- **复制算法（ ）
- **标记-清除（ ）
- **标记-整理（ ）
#### 标记清除（ ）
算法.png)
首先从 GC Root 开始遍历对象图， （ ） ， ，
**不足之处**
- 标记、清除的效率都不高
- 清除后产生大量的内存碎片，空间碎片太多会导致在分配大对象时无法找到足够大的连续内存，从而不得不触发另一次垃圾回收动作
#### 标记整理（ ）
算法.png)
与标记清除算法类似，但不是在标记完成后对可回收对象进行清理，而是将所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。
**优点**
- 消除了标记清除导致的内存分散问题，也消除了复制算法中内存减半的高额代价
**不足之处**
- 效率低下，需要标记所有存活对象，还要标记所有存活对象的引用地址。效率上低于复制算法
#### 标记复制（ ）
标记-复制算法将内存分为两块相同大小的区域（ ） ， ， ，
- 缺点：浪费一半的内存空间
- 优点：简单高效
**JVM在Eden区保存新对象， ，
#### 分代收集（ ）
分代收集就是根据对象的存活周期将内存分为新生代和老年代。
- **新生代**对象“朝生夕死”， （
- **老年代**对象生存几率比较高， ， ， ，
研究表明大部分对象可以分为两类：
- 大部分对象的生命周期都很短
- 其他对象则很可能会存活很长时间
根据对象存活周期的不同将内存划分为几块。对不同周期的对象采取不同的收集算法：
- **新生代**：每次垃圾收集会有大批对象回收，所以采取复制算法
- **老年代**：对象存活率高，采取标记清理或者标记整理算法
**① 年轻代（ ）
年轻代使用的垃圾回收算法是复制算法。因为年轻代发生 GC 后，只会有非常少的对象存活，复制这部分对象是非常高效的。但复制算法会造成一定的空间浪费，所以年轻代中间也会分很多区域。
如图所示，年轻代分为：**1个伊甸园空间（ ） ， （ ） （ ） ：
- 在 Eden 区执行了第一次 GC 之后，存活的对象会被移动到其中一个 Survivor 分区（ ）
- Eden 区再次 GC， ，
在这个过程中， ， ** -XX:SurvivorRatio** 进行配置的（默认为 8）
**② 老年代（ ）
老年代一般使用“**标记-清除**”、“**标记-整理**”算法，因为老年代的对象存活率一般是比较高的，空间又比较大，拷贝起来并不划算，还不如采取就地收集的方式。对象进入老年代的途径如下：
- **提升（ ）
如果对象够老，会通过“提升”进入老年代
- **分配担保**
年轻代回收后存活的对象大于10%时， ，
- **大对象直接在老年代分配**
超出某个大小的对象将直接在老年代分配
- **动态对象年龄判定**
有的垃圾回收算法，并不要求 age 必须达到 15 才能晋升到老年代，它会使用一些动态的计算方法。
比如，如果幸存区中相同年龄对象大小的和，大于幸存区的一半，大于或等于 age 的对象将会直接进入老年代。
#### 分区收集
## GC垃圾收集器
GC垃圾收集器的JVM配置参数：
- **-XX:+UseSerialGC**：年轻代和老年代都用串行收集器
- **-XX:+UseParNewGC**：年轻代使用 ParNew，
- **-XX:+UseParallelGC**：年轻代使用 ParallerGC，
- **-XX:+UseParallelOldGC**：新生代和老年代都使用并行收集器
- **-XX:+UseConcMarkSweepGC**：表示年轻代使用 ParNew，
- **-XX:+UseG1GC**：使用 G1垃圾回收器
- **-XX:+UseZGC**：使用 ZGC 垃圾回收器
### 年轻代收集器
#### Serial收集器
处理GC的只有一条线程， ， ， ， ， ， ，
#### ParNew收集器
ParNew是Serial的多线程版本。由多条GC线程并行地进行垃圾清理。清理过程依然要停止用户线程。ParNew 追求“低停顿时间”，与 Serial 唯一区别就是使用了多线程进行垃圾收集，在多 CPU 环境下性能比 Serial 会有一定程度的提升；但线程切换需要额外的开销，因此在单 CPU 环境中表现不如 Serial。
#### Parallel Scavenge收集器
另一个多线程版本的垃圾回收器。它与ParNew的主要区别是：
- **Parallel Scavenge**： ， ，
- **ParNew**：追求降低用户停顿时间，适合交互式应用。强交互弱计算
### 老年代收集器
#### Serial Old收集器
与年轻代的 Serial 垃圾收集器对应，都是单线程版本，同样适合客户端使用。年轻代的 Serial， ，
#### Parallel Old收集器
Parallel Old 收集器是 Parallel Scavenge 的老年代版本，追求 CPU 吞吐量。
#### CMS收集器
**并发标记清除(Concurrent Mark Sweep,CMS)垃圾回收器**，是一款致力于获取最短停顿时间的收集器，使用多个线程来扫描堆内存并标记可被清除的对象，然后清除标记的对象。在下面两种情形下会暂停工作线程：
- 在老年代中标记引用对象的时候
- 在做垃圾回收的过程中堆内存中有变化发生
对比与并行垃圾回收器， ， `-XX:+UseParNewGCJVM` 参数来开启使用CMS垃圾回收器。
**主要流程如下**：
- **初始标记(CMS initial mark)**：
- **并发标记(CMS concurrenr mark)**： ，
- **重新标记(CMS remark)**：
- **并发清除(CMS concurrent sweep)**：清出垃圾
**CMS触发机制**： ，
- `-XX:CMSInitiatingOccupancyFraction=80`
- `-XX:+UseCMSInitiatingOccupancyOnly`
**优点**
- 并发收集
- 停顿时间最短
**缺点**
- **并发回收导致CPU资源紧张**
在并发阶段， ， ， ： （ ） ， ，
- **无法清理浮动垃圾**
在CMS的并发标记和并发清理阶段， ， ， ， ，
- **并发失败（ ）
由于在垃圾回收阶段用户线程还在并发运行， ， ， ，
这里会有一个风险： ， （ ） ， ： ，
- **内存碎片问题**
CMS是一款基于“标记-清除”算法实现的回收器，这意味着回收结束时会有内存碎片产生。内存碎片过多时，将会给大对象分配带来麻烦，往往会出现老年代还有很多剩余空间，但就是无法找到足够大的连续空间来分配当前对象，而不得不提前触发一次 Full GC 的情况。
为了解决这个问题， ， （ ，
**作用内存区域**：老年代
**适用场景**：对停顿时间敏感的场合
**算法类型**：标记-清除
### 新生代和老年代收集
#### G1收集器
G1（ ） ， ， ， （ ） ，
- **初始标记（ ） ， ， ， ， ， ，
- **并发标记**：从 GC Roots 开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以后，还要重新处理在并发时有引用变动的对象。
- **最终标记（ ）
- **清理阶段（ ） ： ， ， ， ， ， ， ，
G1收集器中的堆内存被划分为多个大小相等的内存块（ ） ， ， ：
每个Region被标记了E、S、O和H， ， ， （ ） ， （ ， ） ， ， ，
**Region**
堆内存中一个Region的大小可以通过 `-XX:G1HeapRegionSize` 参数指定， ， ， ， ，
**GC模式**
- **young gc**
发生在年轻代的GC算法， （ ） ， ， ， ， ， ， ，
- `-XX:MaxGCPauseMillis` ： ，
- `-XX:G1NewSizePercent` ：新生代最小值，默认值`5%`
- `-XX:G1MaxNewSizePercent` ：新生代最大值，默认值`60%`
- **mixed gc**
当越来越多的对象晋升到老年代old region时， ， ， ， ， ， ， ： ， ，
- **full gc**
- 如果对象内存分配速度过快， ， ， ， ， ， ，
**G1垃圾回收器** 应用于大的堆内存空间。它将堆内存空间划分为不同的区域， `-XX:UseG1GCJVM` 参数来开启使用G1垃圾回收器。
**主要流程如下**：
- 初始标记(Initial Marking)：
- 并发标记(Concurrenr Marking)： ，
- **最终标记(Final Marking)**： ，
- 筛选回收(Live Data Counting And Evacution)： ， ，
`-XX:InitiatingHeapOccupancyPercent` ： ，
**优点**：
- 并行与并发，充分发挥多核优势
- 分代收集，所以不需要与其它收集器配合即可工作
- 空间整合，整体来看基于”标记-整理算法“，局部采用”复制算法“都不会产生内存碎片
- 可以指定GC最大停顿时长
**缺点**：
- 需要记忆集来记录新生代和老年代之间的引用关系
- 需要占用大量的内存，
**作用内存区域**：跨代
**适用场景**：作为关注停顿时间的场景的收集器备选方案
**算法类型**：整体来看基于”标记-整理算法“，局部采用"复制算法"
#### ZGC收集器
Z Garbage Collector， ， ，
与CMS中的ParNew和G1类似， ， ： ， ：
ZGC只有三个STW阶段： ， ， ， ， ， ； ， ， ， ， ， ，
**ZGC 的内存布局**
与 Shenandoah 和 G1 一样，
- 小型 Region (Small Region)：容量固定为 2MB，
- 中型 Region (M edium Region)：容量固定为 32MB，
- 大型 Region (Large Region)：容量不固定，可以动态变化，但必须为 2MB 的整数倍，用于放置 4MB 或以上的大对象。每个大型 Region 中只会存放一个大对象，这也预示着虽然名字叫作“大型 Region”， ，
在 JDK 11 及以上版本，可以通过以下参数开启 ZGC：
#### Shenandoah收集器
Shenandoah 与 G1 有很多相似之处，比如都是基于 Region 的内存布局，都有用于存放大对象的 Humongous Region， ：
- Shenandoah支持并发的整理算法， ，
- 默认不使用分代收集理论
- 使用连接矩阵 (Connection Matrix)记录跨Region的引用关系，
Shenandoah 收集器的工作原理相比 G1 要复杂不少，其运行流程示意图如下：
可见Shenandoah的并发程度明显比G1更高， ， ， ：
- **并发标记( Concurrent Marking)**
- **并发回收( Concurrent Evacuation)**
- **并发引用更新( Concurrent Update Reference)**
Shenandoah 的高并发度让它实现了超低的停顿时间，但是更高的复杂度也伴随着更高的系统开销，这在一定程度上会影响吞吐量，下图是 Shenandoah 与之前各种收集器在停顿时间维度和系统开销维度上的对比：
OracleJDK 并不支持 Shenandoah， ：
## GC日志
### 日志格式
**ParallelGC YoungGC日志**
**ParallelGC FullGC日志**
### 最佳实践
在不同的 JVM 的不垃圾回收器上，看参数默认是什么，不要轻信别人的建议，命令行示例如下：
```shell
java -XX:+PrintFlagsFinal -XX:+UseG1GC & 1 | grep UseAdaptiveSizePolicy
```
PrintCommandLineFlags： ，
```shell
# java -XX:+PrintCommandLineFlags -version
-XX:InitialHeapSize=127905216 -XX:MaxHeapSize=2046483456 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
openjdk version "1.8.0_41"
OpenJDK Runtime Environment (build 1.8.0_41-b04)
OpenJDK 64-Bit Server VM (build 25.40-b25, mixed mode)
```
G1垃圾收集器JVM参数最佳实践：
```shell
# 1.基本参数
-server # 服务器模式
-Xmx12g # 初始堆大小
-Xms12g # 最大堆大小
-Xss256k # 每个线程的栈内存大小
-XX:+UseG1GC # 使用 G1 (Garbage First) 垃圾收集器
-XX:MetaspaceSize=256m # 元空间初始大小
-XX:MaxMetaspaceSize=1g # 元空间最大大小
-XX:MaxGCPauseMillis=200 # 每次YGC / MixedGC 的最多停顿时间 (期望最长停顿时间)
# 2.必备参数
-XX:+PrintGCDetails # 输出详细GC日志
-XX:+PrintGCDateStamps # 输出GC的时间戳（ ， ）
-XX:+PrintTenuringDistribution # 打印对象分布： ，
-XX:+PrintHeapAtGC # 在进行GC的前后打印出堆的信息
-XX:+PrintReferenceGC # 打印Reference处理信息:强引用/弱引用/软引用/虚引用/finalize方法万一有问题
-XX:+PrintGCApplicationStoppedTime # 打印STW时间
-XX:+PrintGCApplicationConCurrentTime # 打印GC间隔的服务运行时长
# 3.日志分割参数
-XX:+UseGCLogFileRotation # 开启日志文件分割
-XX:NumberOfGCLogFiles=14 # 最多分割几个文件，超过之后从头文件开始写
-XX:GCLogFileSize=32M # 每个文件上限大小，超过就触发分割
-Xloggc:/path/to/gc-%t.log # GC日志输出的文件路径,使用%t作为日志文件名,即gc-2021-03-29_20-41-47.log
```
CMS垃圾收集器JVM参数最佳实践：
```shell
# 1.基本参数
-server # 服务器模式
-Xmx4g # JVM最大允许分配的堆内存，
-Xms4g # JVM初始分配的堆内存，
-Xmn256m # 年轻代内存大小，
-Xss512k # 设置每个线程的堆栈大小
-XX:+DisableExplicitGC # 忽略手动调用GC, System.gc()的调用就会变成一个空调用，
-XX:+UseConcMarkSweepGC # 使用 CMS 垃圾收集器
-XX:+CMSParallelRemarkEnabled # 降低标记停顿
-XX:+UseCMSCompactAtFullCollection # 在FULL GC的时候对年老代的压缩
-XX:+UseFastAccessorMethods # 原始类型的快速优化
-XX:+UseCMSInitiatingOccupancyOnly # 使用手动定义初始化定义开始CMS收集
-XX:LargePageSizeInBytes=128m # 内存页的大小
-XX:CMSInitiatingOccupancyFraction=70 # 使用cms作为垃圾回收使用70％
# 2.必备参数
-XX:+PrintGCDetails # 输出详细GC日志
-XX:+PrintGCDateStamps # 输出GC的时间戳（ ， ）
-XX:+PrintTenuringDistribution # 打印对象分布： ，
-XX:+PrintHeapAtGC # 在进行GC的前后打印出堆的信息
-XX:+PrintReferenceGC # 打印Reference处理信息:强引用/弱引用/软引用/虚引用/finalize方法万一有问题
-XX:+PrintGCApplicationStoppedTime # 打印STW时间
-XX:+PrintGCApplicationConCurrentTime # 打印GC间隔的服务运行时长
# 3.日志分割参数
-XX:+UseGCLogFileRotation # 开启日志文件分割
-XX:NumberOfGCLogFiles=14 # 最多分割几个文件，超过之后从头文件开始写
-XX:GCLogFileSize=32M # 每个文件上限大小，超过就触发分割
-Xloggc:/path/to/gc-%t.log # GC日志输出的文件路径,使用%t作为日志文件名,即gc-2021-03-29_20-41-47.log
```
**test、stage 环境jvm使用CMS 参数配置（ ）
```shell
-server -Xms256M -Xmx256M -Xss512k -Xmn96M -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=128M -XX:InitialHeapSize=256M -XX:MaxHeapSize=256M -XX:+PrintCommandLineFlags -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:+CMSClassUnloadingEnabled -XX:+CMSParallelRemarkEnabled -XX:+CMSScavengeBeforeRemark -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=2 -XX:+CMSParallelInitialMarkEnabled -XX:+CMSParallelRemarkEnabled -XX:+UnlockDiagnosticVMOptions -XX:+ParallelRefProcEnabled -XX:+AlwaysPreTouch -XX:MaxTenuringThreshold=8 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+PrintGC -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:SurvivorRatio=8 -Xloggc:../logs/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=../dump
```
**online 环境jvm使用CMS参数配置（ ）
```shell
-server -Xms4G -Xmx4G -Xss512k -Xmn1536M -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=128M -XX:InitialHeapSize=4G -XX:MaxHeapSize=4G -XX:+PrintCommandLineFlags -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:+CMSClassUnloadingEnabled -XX:+CMSParallelRemarkEnabled -XX:+CMSScavengeBeforeRemark -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=2 -XX:+CMSParallelInitialMarkEnabled -XX:+CMSParallelRemarkEnabled -XX:+UnlockDiagnosticVMOptions -XX:+ParallelRefProcEnabled -XX:+AlwaysPreTouch -XX:MaxTenuringThreshold=10 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+PrintGC -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:SurvivorRatio=8 -Xloggc:../logs/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=../dump
```
## GC场景
### Full GC场景
**场景一：
此方法的调用是建议JVM进行Full GC,虽然只是建议而非一定,但很多情况下它会触发 Full GC,从而增加Full GC的频率,也即增加了间歇性停顿的次数。强烈影响系建议能不使用此方法就别使用，让虚拟机自己去管理它的内存，可通过通过 `-XX:+ DisableExplicitGC` 来禁止RMI调用System.gc()。
**场景二：老年代代空间不足**
- 原因分析： ，
- 抛出错误：`Java.lang.OutOfMemoryError: Java heap space`
- 解决办法：
- 尽量让对象在YoungGC时被回收
- 让对象在新生代多存活一段时间
- 不要创建过大的对象或数组
**场景三：永生区空间不足**
- 原因分析：
- 抛出错误：`java.lang.OutOfMemoryError: PermGen space`
- 解决办法：
- 增大老年代空间大小
- 使用CMS GC
**场景四：
- 原因分析：
- `promotion failed` ： ， ，
- `concurrent mode failure` ： ，
- 抛出错误：
- 解决办法：增大幸存区或老年代
**场景五：堆中分配很大的对象**
- 原因分析：创建大对象或长数据时，此对象直接进入老年代，而老年代虽有很大剩余空间，但没有足够的连续空间来存储
- 抛出错误：
- 解决办法：配置-XX:+UseCMSCompactAtFullCollection开关参数， ，
### CMS GC场景
**场景一：动态扩容引起的空间震荡**
- **现象**
服务**刚刚启动时 GC 次数较多**，最大空间剩余很多但是依然发生 GC， ，
- **原因**
在 JVM 的参数中 `-Xms` 和 `-Xmx` 设置的不一致，在初始化时只会初始 `-Xms` 大小的空间存储信息，每当空间不够用时再向操作系统申请，这样的话必然要进行一次 GC。另外， ， `-XX:MinHeapFreeRatio` 和 `-XX:MaxHeapFreeRatio` 来控制扩容和缩容的比例，调节这两个值也可以控制伸缩的时机。整个伸缩的模型理解可以看这个图，当 committed 的空间大小超过了低水位/高水位的大小，
- **策略**
观察 CMS GC 触发时间点 Old/MetaSpace 区的 committed 占比是不是一个固定的值，或者像上文提到的观察总的内存使用率也可以。尽量 ** 将成对出现的空间大小配置参数设置成固定的** ，如 `-Xms` 和 `-Xmx` ， `-XX:NewSize` ， `-XX:MaxMetaSpaceSize` 等。
**场景二：
- **现象**
除了扩容缩容会触发 CMS GC 之外，还有 Old 区达到回收阈值、MetaSpace 空间不足、Young 区晋升失败、大对象担保失败等几种触发条件，如果这些情况都没有发生却触发了 GC ？这种情况有可能是代码中手动调用了 System.gc 方法，此时可以找到 GC 日志中的 GC Cause 确认下。
- **原因**
** 保留 System.gc**： ， `-XX:+DisableExplicitGC` 参数则可以禁用。**去掉 System.gc**：禁用掉后会带来另一个内存泄漏的问题，为 DirectByteBuffer 分配空间过程中会显式调用 System.gc ，希望通过 Full GC 来强迫已经无用的 DirectByteBuffer 对象释放掉它们关联的 Native Memory，
- **策略**
无论是保留还是去掉都会有一定的风险点，不过目前互联网中的 RPC 通信会大量使用 NIO， `-XX:+ExplicitGCInvokesConcurrent` 和 `-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses` 参数来将 System.gc 的触发类型从 Foreground 改为 Background， ，
**场景三：
- **现象**
JVM 在启动后或者某个时间点开始， **MetaSpace 的已使用大小在持续增长，同时每次 GC 也无法释放，调大 MetaSpace 空间也无法彻底解决** 。
- **原因**
在讨论为什么会 OOM 之前， ， `-XX:MaxPermSize` 的值也不太好设置，经常会出现 `java.lang.OutOfMemoryError: PermGen space` 异常，所以在 Java 7 之后常量池等字面量（ ） （ ） （ ） ， `-XX:MetaSpaceSize` 和 `-XX:MaxMetaSpaceSize` 两个值设置为固定的，但这样也会导致在空间不够的时候无法扩容，然后频繁地触发 GC， **ClassLoader不停地在内存中load了新的Class ，一般这种问题都发生在动态类加载等情况上。**
- **策略**
可以 dump 快照之后通过 JProfiler 或 MAT 观察 Classes 的 Histogram（ ） `-XX:+TraceClassLoading` 和 `-XX:+TraceClassUnLoading` 参数观察详细的类加载和卸载信息。
**场景四：过早晋升**
- **现象**
这种场景主要发生在分代的收集器上面， ， `-XX:MaxTenuringThreshold` 来控制。过早晋升一般不会直接影响 GC， ， ， ：
- **分配速率接近于晋升速率** ，对象晋升年龄较小。
GC 日志中出现“Desired survivor size 107347968 bytes, **new threshold 1(max 6)** ”等信息，说明此时经历过一次 GC 就会放到 Old 区。
- **Full GC 比较频繁** ，且经历过一次 GC 之后 Old 区的 ** 变化比例非常大** 。
如Old区触发回收阈值是80%， ，
过早晋升的危害：
- Young GC 频繁，总的吞吐量下降
- Full GC 频繁，可能会有较大停顿
- **原因**
主要的原因有以下两点：
- **Young/Eden 区过小**： ， ， （ ， ，
- **分配速率过大**：
- **策略**
- 如果是 **Young/Eden 区过小** ，可以在总的 Heap 内存不变的情况下适当增大Young区。一般情况下Old的大小应当为活跃对象的2~3倍左右， ，
- 过早晋升优化来看， ， ， ， （ ， ， ， ：
如果是分配速率过大：
- **偶发较大** ：通过内存分析工具找到问题代码，从业务逻辑上做一些优化
- **一直较大** ：当前的 Collector 已经不满足 Mutator 的期望了，这种情况要么扩容 Mutator 的 VM，
- **小结**
过早晋升问题一般不会特别明显，但日积月累之后可能会爆发一波收集器退化之类的问题，所以我们还是要提前避免掉的，可以看看自己系统里面是否有这些现象，如果比较匹配的话，可以尝试优化一下。一行代码优化的 ROI 还是很高的。如果在观察 Old 区前后比例变化的过程中，发现可以回收的比例非常小，如从 80% 只回收到了 60%， ，
**场景五：
- **现象**
Old 区频繁的做 CMS GC， ，
- **原因**
这种情况比较常见，基本都是一次 Young GC 完成后，负责处理 CMS GC 的一个后台线程 concurrentMarkSweepThread 会不断地轮询，使用 `shouldConcurrentCollect()` 方法做一次检测，判断是否达到了回收条件。如果达到条件，使用 `collect_in_background()` 启动一次 Background 模式 GC。轮询的判断是使用 `sleepBeforeNextCycle()` 方法，间隔周期为 `-XX:CMSWaitDuration` 决定，默认为 2s。
- **策略**
处理这种常规内存泄漏问题基本是一个思路，主要步骤如下：
Dump Diff 和 Leak Suspects 比较直观，这里说下其它几个关键点：
- **内存 Dump**： ** 分别在 CMS GC 的发生前后分别 dump 一次**
- **分析 Top Component**： ， ，
- **分析 Unreachable**：
**场景六：
- **现象**
CMS GC 单次 STW 最大超过 1000ms， ， ， ，
- **原因**
CMS在回收的过程中， ， ， ，
- **策略**
知道了两个 STW 过程执行流程，我们分析解决就比较简单了，由于大部分问题都出在 Final Remark 过程，这里我们也拿这个场景来举例，主要步骤：
- **【方向】** 观察详细 GC 日志，找到出问题时 Final Remark 日志，分析下 Reference 处理和元数据处理 real 耗时是否正常，详细信息需要通过 `-XX:+PrintReferenceGC` 参数开启。 ** 基本在日志里面就能定位到大概是哪个方向出了问题，耗时超过 10% 的就需要关注** 。
```shell
2019-02-27T19:55:37.920+0800: 516952.915: [GC (CMS Final Remark) 516952.915: [ParNew516952.939: [SoftReference, 0 refs, 0.0003857 secs]516952.939: [WeakReference, 1362 refs, 0.0002415 secs]516952.940: [FinalReference, 146 refs, 0.0001233 secs]516952.940: [PhantomReference, 0 refs, 57 refs, 0.0002369 secs]516952.940: [JNI Weak Reference, 0.0000662 secs]
[class unloading, 0.1770490 secs]516953.329: [scrub symbol table, 0.0442567 secs]516953.373: [scrub string table, 0.0036072 secs][1 CMS-remark: 1638504K(2048000K)] 1667558K(4352000K), 0.5269311 secs] [Times: user=1.20 sys=0.03, real=0.53 secs]
```
- **【根因】** 有了具体的方向我们就可以进行深入的分析，一般来说最容易出问题的地方就是 Reference 中的 FinalReference 和元数据信息处理中的 scrub symbol table 两个阶段，想要找到具体问题代码就需要内存分析工具 MAT 或 JProfiler 了，注意要 dump 即将开始 CMS GC 的堆。在用 MAT 等工具前也可以先用命令行看下对象 Histogram，
- 对 FinalReference 的分析主要观察 `java.lang.ref.Finalizer` 对象的 dominator tree， `SocksSocketImpl` 、Jersey 的 `ClientRuntime` 、MySQL 的 `ConnectionImpl` 等等
- scrub symbol table 表示清理元数据符号引用耗时，符号引用是 Java 代码被编译成字节码时，方法在 JVM 中的表现形式，生命周期一般与 Class 一致，当 `_should_unload_classes` 被设置为 true 时在 `CMSCollector::refProcessingWork()` 中与 Class Unload、String Table 一起被处理
- **【策略】** 知道 GC 耗时的根因就比较好处理了，这种问题不会大面积同时爆发，不过有很多时候单台 STW 的时间会比较长，如果业务影响比较大，及时摘掉流量，具体后续优化策略如下：
- FinalReference： ， `-XX:+ParallelRefProcEnabled` 对 Reference 进行并行处理
- symbol table： ， `-XX:-CMSClassUnloadingEnabled` 来避免 MetaSpace 的处理， ，
- **小结**
正常情况进行的 Background CMS GC， ， ， ， ，
**场景七：内存碎片& 收集器退化**
- **现象**
并发的 CMS GC 算法，退化为 Foreground 单线程串行 GC 模式，
- 带压缩动作的算法，称为 MSC， ， ，
- 不带压缩动作的算法，收集 Old 区，和普通的 CMS 算法比较相似，暂停时间相对 MSC 算法短一些
- **原因**
CMS 发生收集器退化主要有以下几种情况：
- **晋升失败（ ）
- **增量收集担保失败**
- **显式 GC**
- **并发模式失败（ ）
- **策略**
分析到具体原因后，我们就可以针对性解决了，具体思路还是从根因出发，具体解决策略：
- **内存碎片**： `-XX:UseCMSCompactAtFullCollection=true` 来控制 Full GC 的过程中是否进行空间的整理（默认开启，注意是 Full GC， ） ， `-XX: CMSFullGCsBeforeCompaction=n` 来控制多少次 Full GC 后进行一次压缩
- **增量收集**： `-XX:CMSInitiatingOccupancyFraction` 的值，让 CMS GC 尽早执行，以保证有足够的连续空间，也减少 Old 区空间的使用大小，另外需要使用 `-XX:+UseCMSInitiatingOccupancyOnly` 来配合使用，不然 JVM 仅在第一次使用设定值，后续则自动调整
- **浮动垃圾**： `-XX:+CMSScavengeBeforeRemark` 在过程中提前触发一次Young GC，
- **小结**
正常情况下触发并发模式的 CMS GC， ， ， `-XX:CMSFullGCsBeforeCompaction` 的值不好选取的话，可以使用 `-XX:PrintFLSStatistics` 来观察内存碎片率情况，然后再设置具体的值。最后就是在编码的时候也要避免需要连续地址空间的大对象的产生，如过长的字符串，用于存放附件、序列化或反序列化的 byte 数组等，还有就是过早晋升问题尽量在爆发问题前就避免掉。
**场景八：
- **现象**
内存使用率不断上升，甚至开始使用 SWAP 内存，同时可能出现 GC 时间飙升，线程被 Block 等现象， ** 通过 top 命令发现 Java 进程的 RES 甚至超过了** `**-Xmx**` ** 的大小** 。出现这些现象时，基本可确定是出现堆外内存泄漏。
- **原因**
JVM 的堆外内存泄漏，主要有两种的原因：
- 通过 `UnSafe#allocateMemory` ，
- 代码中有通过 JNI 调用 Native Code 申请的内存没有释放
- **策略**
** 原因一：主动申请未释放**
** 原因二：通过 JNI 调用的 Native Code 申请的内存未释放**
**场景九：
- **现象**
在 GC 日志中，出现 GC Cause 为 GCLocker Initiated GC。
```shell
2020-09-23T16:49:09.727+0800: 504426.742: [GC (GCLocker Initiated GC) 504426.742: [ParNew (promotion failed): 209716K->6042K(1887488K), 0.0843330 secs] 1449487K->1347626K(3984640K), 0.0848963 secs] [Times: user=0.19 sys=0.00, real=0.09 secs]2020-09-23T16:49:09.812+0800: 504426.827: [Full GC (GCLocker Initiated GC) 504426.827: [CMS: 1341583K->419699K(2097152K), 1.8482275 secs] 1347626K->419699K(3984640K), [Metaspace: 297780K->297780K(1329152K)], 1.8490564 secs] [Times: user=1.62 sys=0.20, real=1.85 secs]
```
- **原因**
JNI（ ）
- 拷贝传递
- 共享引用（指针），性能更高
由于 Native 代码直接使用了 JVM 堆区的指针，如果这时发生 GC， ，
- **策略**
- 添加 `-XX+PrintJNIGCStalls` 参数，可以打印出发生 JNI 调用时的线程，进一步分析，找到引发问题的 JNI 调用
- JNI 调用需要谨慎，不一定可以提升性能，反而可能造成 GC 问题
- 升级 JDK 版本到 14， JDK-8048556 ](https://bugs.openjdk.java.net/browse/JDK-8048556 ) 导致的重复 GC
# JVM性能调优
## 磁盘不足排查
其实， ， ， ， ， ， ， ， ， ，
从上面的显示中其中第一行使用的2.8G最大，然后是挂载在 ** /** 目录下，我们直接**cd /**。然后通过执行：
```shell
du -sh *
```
查看各个文件的大小，找到其中最大的，或者说存储量级差不多的并且都非常大的文件，把那些没用的大文件删除就好。
然后， ：
## CPU过高排查
**排查过程**
- 使用`top`查找进程id
- 使用`top -Hp < pid > `查找进程中耗cpu比较高的线程id
- 使用`printf %x < pid > `将线程id十进制转十六进制
- 使用` jstack -pid | grep -A 20 < pid > `过滤出线程id锁关联的栈信息
- 根据栈信息中的调用链定位业务代码
案例代码如下：
```java
public class CPUSoaring {
public static void main(String[] args) {
Thread thread1 = new Thread(new Runnable(){
@Override
public void run() {
for (;;){
System.out.println("I am children-thread1");
}
}
},"children-thread1");
Thread thread2 = new Thread(new Runnable(){
@Override
public void run() {
for (;;){
System.out.println("I am children-thread2");
}
}
},"children-thread2");
thread1.start();
thread2.start();
System.err.println("I am is main thread!!!!!!!!");
}
}
```
- 第一步：首先通过**top**命令可以查看到id为**3806**的进程所占的CPU最高：
- 第二步：然后通过**top -Hp pid**命令， ：
- 第三步：接着通过：**printf '%x\n' tid**命令将线程的tid转换为十六进制： ：
- 第四步：最后通过：**jstack pid|grep xid -A 30**命令就是输出线程的堆栈信息，线程所在的位置：
- 第五步：还可以通过**jstack -l pid > 文件名称.txt** 命令将线程堆栈信息输出到文件，线下查看。
这就是一个CPU飙高的排查过程， ， ， ， ，
## 内存打满排查
**排查过程**
- 查找进程id：
- 查看JVM堆内存分配情况：
- 查看占用内存比较多的对象：`jmap -histo pid | head -n 100`
- 查看占用内存比较多的存活对象：`jmap -histo:live pid | head -n 100`
**示例**
- 第一步：
- 第二步：
- 第三步：定位占用内存比价多的对象
这里就能看到对象个数以及对象大小……
这里看到一个自定义的类，这样我们就定位到具体对象，看看这个对象在那些地方有使用、为何会有大量的对象存在。
## OOM异常排查
OOM的异常排查也比较简单， ， ：
```shell
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${目录}
```
指定项目出现OOM异常的时候自动导出堆转储文件， （
首先我们来聊一聊， ， ：
- **Java堆**
- **方法区**
- **虚拟机栈**
- **本地方法栈**
- **程序计数器**
- **直接内存**
只有**程序计数器**区域不会出现OOM， （ ）
而站在程序代码的角度来看， ：
- **内存泄露**
- **对象过大、过多**
- **方法过长**
- **过度使用代理框架，生成大量的类信息**
接下来我们屋来看看OOM的排查， ， ， ， ：
```java
import java.util.ArrayList;
import java.util.List;
class OOM {
static class User{
private String name;
private int age;
public User(String name, int age){
this.name = name;
this.age = age;
}
}
public static void main(String[] args) throws InterruptedException {
List< User > list = new ArrayList< >();
for (int i = 0; i < Integer.MAX_VALUE ; i + + ) {
Thread.sleep(1000);
User user = new User("zhangsan"+i,i);
list.add(user);
}
}
}
```
代码很简单， ， ， ：
这样就找到导致OOM异常的类， ，
上面的方法是排查已经出现了OOM异常的方法， ， ？
一般大厂都会有自己的监控平台，能够实施的**监控测试环境、预览环境、线上实施的服务健康状况（ ） ， ， ，
因为一般方法的长度合理，
每次自己写完代码，自己检查后，都可以提交给比自己高级别的工程师**review**自己的代码，就能及时的发现代码的问题，基本上代码没问题，百分之九十以上的问题都能避免，这也是大厂注重代码质量，并且时刻**review**代码的习惯。
## Jvisualvm
项目频繁YGC 、FGC问题排查
### 内存问题
对象内存占用、实例个数监控
对象内存占用、年龄值监控
通过上面两张图发现这些对象占用内存比较大而且存活时间也是比较常， ， ， ， ， ，
**优化办法**：优化两个缓存对象，将缓存对象大小减小。优化一下两个对象，缓存关键信息！
### CPU耗时问题排查
Cpu使用耗时监控：
耗时、调用次数监控：
从上面监控图可以看到主要耗时还是在网络请求，
## 调优堆内存分配
**初始堆空间大小设置**
- 使用系统默认配置在系统稳定运行一段时间后查看记录内存使用情况：
- 按照通用法则通过gc信息分配调整大小，
- 老年代大小为Full GC后老年代空间占用大小的2-3倍
- 新生代大小为Full GC后老年代空间占用大小的1-1.5倍
- 元数据空间大小为Full GC后元数据空间占用大小的1.2-1.5倍
活跃数大小是应用程序运行在稳定态时， （ ，
**堆大小调整的着手点、分析点**
- 统计Minor GC 持续时间
- 统计Minor GC 的次数
- 统计Full GC的最长持续时间
- 统计最差情况下Full GC频率
- 统计GC持续时间和频率对优化堆的大小是主要着手点， ，
## 年轻代调优
**年轻代调优规则**
- 老年代空间大小不应该小于活跃数大小1.5倍。老年代空间大小应为老年代活跃数2-3倍
- 新生代空间至少为java堆内存大小的10% 。新生代空间大小应为1-1.5倍的老年代活跃数
- 在调小年轻代空间时应保持老年代空间不变
MinorGC是收集eden+from survivor 区域的， ， ， ，
- **MinorGC频繁原因**
MinorGC 比较频繁说明eden内存分配过小，
- **年轻代大小调整**
Eden调整到多大那， ， ， ，
- **MinorGC停顿时间过长**
MinorGC 收集过程是要产生STW的。如果年轻代空间太大， ， ， ， ， ，
堆内存：
堆内存： ：
**按照上面计算调优**
堆内存： 480M 年轻带： 160M 收集14次 耗时154毫秒 11毫秒/次 相比之前的 12.82毫秒/次 停顿时间减少1.82毫秒
**但是还没达到10毫秒的要求， ；
年轻代减少：
堆大小： 480-14.55 = 465.45=465M
但是在这样调整后使用jmap -heap 查看的时候年轻代大小和实际配置数据有出入（ ） ， ： ， ：
MinorGC耗时 159/16=9.93毫秒
MinorGC耗时 185/18=10.277=10.28毫秒
MinorGC耗时 205/20=10.25毫秒
Ok 这样MinorGC停顿时间过长问题解决， ， ，
## 老年代调优
按照同样的思路对老年代进行调优，
**老年代调优流程**
- 分析每次MinorGC 之后老年代空间占用变化，
- 按照MinorGC频率和晋升老年代对象大小计算提升率即每秒钟能有多少对象晋升到老年代
- FullGC之后统计老年代空间被占用大小计算老年带空闲空间， ， ， ， ，
- 如果在FullGC 频率满足优化目标而停顿时间比较长的情况下可以考虑使用CMS、G1收集器。并发收集减少停顿时间
## 栈溢出
栈溢出异常的排查（包括**虚拟机栈、本地方法栈**） ， ， ，
当线程请求的栈深度大于虚拟机栈所允许的大小时，就会出现**StackOverflowError**异常，二从代码的角度来看，导致线程请求的深度过大的原因可能有：**方法栈中对象过大，或者过多，方法过长从而导致局部变量表过大，超过了-Xss参数的设置**。
## 死锁排查
死锁的案例演示的代码如下：
```java
public class DeadLock {
public static Object lock1 = new Object();
public static Object lock2 = new Object();
public static void main(String[] args){
Thread a = new Thread(new Lock1(),"DeadLock1");
Thread b = new Thread(new Lock2(),"DeadLock2");
a.start();
b.start();
}
}
class Lock1 implements Runnable{
@Override
public void run(){
try{
while(true){
synchronized(DeadLock.lock1){
System.out.println("Waiting for lock2");
Thread.sleep(3000);
synchronized(DeadLock.lock2){
System.out.println("Lock1 acquired lock1 and lock2 ");
}
}
}
}catch(Exception e){
e.printStackTrace();
}
}
}
class Lock2 implements Runnable{
@Override
public void run(){
try{
while(true){
synchronized(DeadLock.lock2){
System.out.println("Waiting for lock1");
Thread.sleep(3000);
synchronized(DeadLock.lock1){
System.out.println("Lock2 acquired lock1 and lock2");
}
}
}
}catch(Exception e){
e.printStackTrace();
}
}
}
```
上面的代码非常的简单，就是两个类的实例作为锁资源，然后分别开启两个线程，不同顺序的对锁资源资源进行加锁，并且获取一个锁资源后，等待三秒，是为了让另一个线程有足够的时间获取另一个锁对象。
运行上面的代码后，就会陷入死锁的僵局：
对于死锁的排查， ， ，
并且查看线程的堆栈信息。就能看到具体的死锁的线程：
线上的话可以上用Arthas也可以使用原始的命令进行排查， ，
Arthas工具可以使用**thread**命令排查死锁，要关注的是**BLOCKED**状态的线程，如下图所示：
具体thread的详细参数可以参考如下图所示：
**如何避免死锁**
上面我们聊了如何排查死锁，下面我们来聊一聊如何避免死锁的发生，从上面的案例中可以发现，死锁的发生两个线程同时都持有对方不释放的资源进入僵局。所以，在代码层面，要避免死锁的发生，主要可以从下面的四个方面进行入手：
- **首先避免线程的对于资源的加锁顺序要保持一致**
- **并且要避免同一个线程对多个资源进行资源的争抢**
- **另外的话， ， ， ， ，
- **最后，就是使用第三方的工具检测死锁，预防线上死锁的发生**
死锁的排查已经说完了， ， ， ，
## 调优实战
上面说完了调优的目的和调优的指标，那么我们就来实战调优，首先准备我的案例代码，如下：
```java
import java.util.ArrayList;
import java.util.List;
class OOM {
static class User{
private String name;
private int age;
public User(String name, int age){
this.name = name;
this.age = age;
}
}
public static void main(String[] args) throws InterruptedException {
List< User > list = new ArrayList< >();
for (int i = 0; i < Integer.MAX_VALUE ; i + + ) {
Tread.sleep(1000);
System.err.println(Thread.currentThread().getName());
User user = new User("zhangsan"+i,i);
list.add(user);
}
}
}
```
案例代码很简单，就是不断的往一个集合里里面添加对象，首先初次我们启动的命令为：
```shell
java -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:+PrintHeapAtGC -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=50M -Xloggc:./logs/emps-gc-%t.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./logs/emps-heap.dump OOM
```
就是纯粹的设置了一些GC的打印日志， ：
可以看到一段时间后出现4次Minor GC， ，
Minor GC非常频繁， ， ， ， ， ，
因此， ， ：
```shell
java -Xmx2048m -Xms2048m -Xmn1024m -Xss256k -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:+PrintHeapAtGC -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=50M -Xloggc:./logs/emps-gc-%t.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./logs/emps-heap.dump OOM
```
观察一段时间后，结果如下图所示：
可以发现Minor GC次数明显下降， ， ， ， ， ， ：
因此第三次对于元空间的区域设置大一些， ， ：
```shell
java -Xmx2048m -Xms2048m -Xmn1024m -Xss256k -XX:MetaspaceSize=100m -XX:MaxMetaspaceSize=100m -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:+PrintHeapAtGC -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=50M -Xloggc:./logs/emps-gc-%t.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./logs/emps-heap.dump OOM
```
观察相同的时间后， ：
同样的时间， ，
但是调优并不是一味的调大内存， ， ， ， ，
然后再来看Visual VM的图， ：
可以看到Minor GC也是非常频繁的， ， ， ， ，
当我们将上面的情况， ， ：
```shell
java -Xmx4048m -Xms4048m -Xmn2024m -XX:SurvivorRatio=7 -Xss256k -XX:MetaspaceSize=300m -XX:MaxMetaspaceSize=100m -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:+PrintHeapAtGC -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=50M -Xloggc:./logs/emps-gc-%t.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./logs/emps-heap.dump OOM
```
可以看到相同时间内， ， ， ， ， ：
所以， ， ， ， ， ， ， ， ， ，
## 调优参数
### 堆
- -Xms1024m 设置堆的初始大小
- -Xmx1024m 设置堆的最大大小
- -XX:NewSize=1024m 设置年轻代的初始大小
- -XX:MaxNewSize=1024m 设置年轻代的最大值
- -XX:SurvivorRatio=8 Eden和S区的比例
- -XX:NewRatio=4 设置老年代和新生代的比例
- -XX:MaxTenuringThreshold=10 设置晋升老年代的年龄条件
### 栈
- -Xss128k
### 元空间
- -XX:MetasapceSize=200m 设置初始元空间大小
- -XX:MaxMatespaceSize=200m 设置最大元空间大小 默认无限制
### 直接内存
- -XX:MaxDirectMemorySize 设置直接内存的容量，默认与堆最大值一样
### 日志
- -Xloggc:/opt/app/ard-user/ard-user-gc-%t.log 设置日志目录和日志名称
- -XX:+UseGCLogFileRotation 开启滚动生成日志
- -XX:NumberOfGCLogFiles=5 滚动GC日志文件数， ，
- -XX:GCLogFileSize=20M GC文件滚动大小，
- -XX:+PrintGCDetails 开启记录GC日志详细信息（ ）
- -XX:+ PrintGCDateStamps 记录系统的GC时间
- -XX:+PrintGCCause 产生GC的原因(默认开启)
### GC
#### Serial垃圾收集器（ ）
开启
- -XX:+UseSerialGC
关闭：
- -XX:-UseSerialGC //新生代使用Serial 老年代则使用SerialOld
#### Parallel Scavenge收集器（ ）
- -XX:+UseParallelOldGC 关闭
- -XX:-UseParallelOldGC 新生代使用功能Parallel Scavenge 老年代将会使用Parallel Old收集器
#### ParallelOl垃圾收集器（ ）
- -XX:+UseParallelGC 关闭
- -XX:-UseParallelGC 新生代使用功能Parallel Scavenge 老年代将会使用Parallel Old收集器
#### ParNew垃圾收集器（ ）
- -XX:+UseParNewGC 关闭
- -XX:-UseParNewGC //新生代使用功能ParNew 老年代则使用功能CMS
#### CMS垃圾收集器（ ）
- -XX:+UseConcMarkSweepGC 关闭
- -XX:-UseConcMarkSweepGC
- -XX:MaxGCPauseMillis GC停顿时间， ，
- -XX:+UseCMSCompactAtFullCollection 用于在CMS收集器不得不进行FullGC时开启内存碎片的合并整理过程， ， （ ）
- -XX： ， ， ）
- -XX:CMSInitiatingOccupancyFraction 当老年代使用达到该比例时会触发FullGC，
- -XX:+UseCMSInitiatingOccupancyOnly 这个参数搭配上面那个用， ， ，
- -XX:+CMSScavengeBeforeRemark 在FullGC前启动一次MinorGC， ， ，
- -XX:+CMSParallellnitialMarkEnabled 默认情况下初始标记是单线程的， ，
- -XX:+CMSParallelRemarkEnabled 使用多线程进行重新标记，
#### G1垃圾收集器开启
- -XX:+UseG1GC 关闭
- -XX:-UseG1GC
- -XX： ， ～
- -XX： ， ，
# JDK Tools
## jps
用于显示当前用户下的所有java进程信息：
```shell
# jps [options] [hostid]
# q:仅输出VM标识符, m: 输出main method的参数,l:输出完全的包名, v:输出jvm参数
[root@localhost ~]# jps -l
28729 sun.tools.jps.Jps
23789 cn.ms.test.DemoMain
23651 cn.ms.test.TestMain
```
## jstat
用于监视虚拟机运行时状态信息（ ） ：
**-gc**：垃圾回收统计（大小）
```shell
# 每隔2000ms输出<pid>进程的gc情况，
[root@localhost ~]# jstat -gc < pid > 2000 2
# 每隔2s输出<pid>进程的gc情况，
[root@localhost ~]# jstat -gc -t -h3 < pid > 2s
Timestamp S0C S1C S0U S1U ... YGC YGCT FGC FGCT GCT
1021.6 1024.0 1024.0 0.0 1024.0 ... 1 0.012 0 0.000 0.012
1023.7 1024.0 1024.0 0.0 1024.0 ... 1 0.012 0 0.000 0.012
1025.7 1024.0 1024.0 0.0 1024.0 ... 1 0.012 0 0.000 0.012
Timestamp S0C S1C S0U S1U ... YGC YGCT FGC FGCT GCT
1027.7 1024.0 1024.0 0.0 1024.0 ... 1 0.012 0 0.000 0.012
1029.7 1024.0 1024.0 0.0 1024.0 ... 1 0.012 0 0.000 0.012
# 结果说明: C即Capacity 总容量，
##########################
# S0C： （ ）
# S1C： （ ）
# S0U： （ ）
# S1U： （ ）
# EC： （ ）
# EU： （ ）
# OC：
# OU：
# PC：
# PU：
# YGC：
# YGCT：
# FGC：
# FGCT：
# GCT：
```
**-gcutil**：垃圾回收统计（百分比）
```shell
[root@localhost bin]# jstat -gcutil < pid >
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
0.00 99.80 16.21 26.18 93.34 90.74 9 0.056 2 0.045 0.102
# 结果说明
##########################
# S0： （ ）
# S1： （ ）
# E： （ ）
# O：
# P：
# YGC：
# YGCT：
# FGC：
# FGCT：
# GCT：
```
**-gccapacity**：堆内存统计
```shell
[root@localhost ~]# jstat -gccapacity < pid >
NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC PGCMN PGCMX PGC PC YGC FGC
84480.0 1349632.0 913408.0 54272.0 51200.0 502784.0 168448.0 2699264.0 168448.0 168448.0 21504.0 83968.0 51712.0 51712.0 9 0
# 结果说明
##########################
# NGCMN：
# NGCMX：
# NGC：
# S0C： （ ）
# S1C： （ ）
# EC： （ ）
# OGCMN：
# OGCMX：
# OGC：
# OC：
# PGCMN：
# PGCMX：
# PGC：
# PC：
# YGC：
# GCT：
```
**-gccause**：垃圾收集统计概述（同-gcutil） ，
```shell
[root@localhost ~]# jstat -gccause < pid >
S0 S1 E O P YGC YGCT FGC FGCT GCT LGCC GCC
0.00 79.23 39.37 39.92 99.74 9 0.198 0 0.000 0.198 Allocation Failure No GC
# 结果说明
##########################
# LGCC：
# GCC：
```
## jstack
jstack(Java Stack Trace)主要用于打印线程的堆栈信息， ，
```shell
# dump出进程<pid>的线程堆栈快照至/data/1.log文件中
jstack -l < pid > >/data/1.log
# 参数说明：
# -F： （ ） ，
# -m： ，
# -l： ，
```
jstack dump文件中值得关注的线程状态有：
- **死锁（ ）
- 执行中（ ）
- **等待资源（ ）
- 等待某个资源或条件发生来唤醒自己。具体需结合jstacktrace来分析， ，
- 如果大量线程在“waiting on condition”， ，
- **等待获取监视器（ ）
- 如果大量线程在“waiting for monitor entry”，
- 暂停（ ）
- 对象等待中（ ）
- **阻塞（ ）
- 停止（ ）
**注意**： ，
**场景一：
```shell
"RMI TCP Connection(267865)-172.16.5.25" daemon prio=10 tid=0x00007fd508371000 nid=0x55ae waiting for monitor entry [0x00007fd4f8684000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.log4j.Category.callAppenders(Category.java:201)
- waiting to lock < 0x00000000acf4d0c0 > (a org.apache.log4j.Logger)
at org.apache.log4j.Category.forcedLog(Category.java:388)
at org.apache.log4j.Category.log(Category.java:853)
at org.apache.commons.logging.impl.Log4JLogger.warn(Log4JLogger.java:234)
at com.tuan.core.common.lang.cache.remote.SpyMemcachedClient.get(SpyMemcachedClient.java:110)
```
- 线程状态是 Blocked，
- “ waiting to lock < 0x00000000acf4d0c0 > ”指，线程在等待给这个 0x00000000acf4d0c0 地址上锁（ ： ）
- 在 dump 日志里查找字符串 0x00000000acf4d0c0， （ < 0x00000000acf4d0c0 > ），就可以顺藤摸瓜了
- “waiting for monitor entry”说明此线程通过 synchronized(obj) {……} 申请进入了临界区， ，
- 第一行里，"RMI TCP Connection(267865)-172.16.5.25"是 Thread Name 。tid指Java Thread id。nid指native线程的id。prio是线程优先级。[0x00007fd4f8684000]是线程栈起始地址。
**场景二：
1.top命令找出最高占用的进程（ ）
2.查看高负载进程下的高负载线程（ < PID > 或ps -mp < PID > -o THREAD,tid,time）
3.找出最高占用的线程并记录thread_id， （ ）
4.（ ） （ ）
5.导出进程的堆栈日志， （ ）
6.根据找到的堆栈信息关联到代码进行定位分析即可
## jmap
jmap(Java Memory Map)主要用于打印内存映射。常用命令：
`jmap -dump:live,format=b,file=xxx.hprof <pid> `
**查看JVM堆栈的使用情况**
```powershell
[root@localhost ~]# jmap -heap 7243
Attaching to process ID 27900, please wait...
Debugger attached successfully.
Client compiler detected.
JVM version is 20.45-b01
using thread-local object allocation.
Mark Sweep Compact GC
Heap Configuration: #堆内存初始化配置
MinHeapFreeRatio = 40 #-XX:MinHeapFreeRatio设置JVM堆最小空闲比率
MaxHeapFreeRatio = 70 #-XX:MaxHeapFreeRatio设置JVM堆最大空闲比率
MaxHeapSize = 100663296 (96.0MB) #-XX:MaxHeapSize=设置JVM堆的最大大小
NewSize = 1048576 (1.0MB) #-XX:NewSize=设置JVM堆的‘ ’
MaxNewSize = 4294901760 (4095.9375MB) #-XX:MaxNewSize=设置JVM堆的‘ ’
OldSize = 4194304 (4.0MB) #-XX:OldSize=设置JVM堆的‘ ’
NewRatio = 2 #-XX:NewRatio=:‘新生代’和‘老生代’的大小比率
SurvivorRatio = 8 #-XX:SurvivorRatio=设置年轻代中Eden区与Survivor区的大小比值
PermSize = 12582912 (12.0MB) #-XX:PermSize=< value > :设置JVM堆的‘ ’
MaxPermSize = 67108864 (64.0MB) #-XX:MaxPermSize=< value > :设置JVM堆的‘ ’
Heap Usage:
New Generation (Eden + 1 Survivor Space): #新生代区内存分布，包含伊甸园区+1个Survivor区
capacity = 30212096 (28.8125MB)
used = 27103784 (25.848182678222656MB)
free = 3108312 (2.9643173217773438MB)
89.71169693092462% used
Eden Space: #Eden 区内存分布
capacity = 26869760 (25.625MB)
used = 26869760 (25.625MB)
free = 0 (0.0MB)
100.0% used
From Space: #其中一个Survivor区的内存分布
capacity = 3342336 (3.1875MB)
used = 234024 (0.22318267822265625MB)
free = 3108312 (2.9643173217773438MB)
7.001809512867647% used
To Space: #另一个Survivor区的内存分布
capacity = 3342336 (3.1875MB)
used = 0 (0.0MB)
free = 3342336 (3.1875MB)
0.0% used
PS Old Generation: #当前的Old区内存分布
capacity = 67108864 (64.0MB)
used = 67108816 (63.99995422363281MB)
free = 48 (4.57763671875E-5MB)
99.99992847442627% used
PS Perm Generation: #当前的 “持久代” 内存分布
capacity = 14417920 (13.75MB)
used = 14339216 (13.674942016601562MB)
free = 78704 (0.0750579833984375MB)
99.45412375710227% used
```
新生代内存回收就是采用空间换时间方式； ， ，
**统计一【jmap -histo】**：统计所有类的实例数量和所占用的内存容量
```powershell
[root@localhost ~]# jmap -histo 7243
num #instances #bytes class name
----------------------------------------------
1: 8969 19781168 [B
2: 1835 2296720 [I
3: 19735 2050688 [C
4: 3448 385608 java.lang.Class
5: 3829 371456 [Ljava.lang.Object;
6: 14634 351216 java.lang.String
7: 6695 214240 java.util.concurrent.ConcurrentHashMap$Node
8: 6257 100112 java.lang.Object
9: 2155 68960 java.util.HashMap$Node
10: 723 63624 java.lang.reflect.Method
11: 49 56368 [Ljava.util.concurrent.ConcurrentHashMap$Node;
12: 830 46480 java.util.zip.ZipFile$ZipFileInputStream
13: 1146 45840 java.lang.ref.Finalizer
......
```
**统计二【jmap -histo】**： ， ，
```shell
[root@localhost ~]# jmap -histo 7243 |grep Map|sort -k 2 -g -r|less
Total 96237 26875560
7: 6695 214240 java.util.concurrent.ConcurrentHashMap$Node
9: 2155 68960 java.util.HashMap$Node
18: 563 27024 java.util.HashMap
21: 505 20200 java.util.LinkedHashMap$Entry
16: 337 34880 [Ljava.util.HashMap$Node;
27: 336 16128 gnu.trove.THashMap
56: 163 6520 java.util.WeakHashMap$Entry
60: 127 6096 java.util.WeakHashMap
38: 127 10144 [Ljava.util.WeakHashMap$Entry;
53: 126 7056 java.util.LinkedHashMap
......
```
**统计三【jmap -histo】**：
```shell
[root@localhost ~]# jmap -histo 7243 | sort -n -r -k 2 | head -10
num #instances #bytes class name
----------------------------------------------
Total 96237 26875560
3: 19735 2050688 [C
6: 14634 351216 java.lang.String
1: 8969 19781168 [B
7: 6695 214240 java.util.concurrent.ConcurrentHashMap$Node
8: 6257 100112 java.lang.Object
5: 3829 371456 [Ljava.lang.Object;
4: 3448 385608 java.lang.Class
9: 2155 68960 java.util.HashMap$Node
2: 1835 2296720 [I
```
**统计四【jmap -histo】**：
```shell
[root@localhost ~]# jmap -histo 7243 | sort -n -r -k 3 | head -10
num #instances #bytes class name
----------------------------------------------
Total 96237 26875560
1: 8969 19781168 [B
2: 1835 2296720 [I
3: 19735 2050688 [C
4: 3448 385608 java.lang.Class
5: 3829 371456 [Ljava.lang.Object;
6: 14634 351216 java.lang.String
7: 6695 214240 java.util.concurrent.ConcurrentHashMap$Node
8: 6257 100112 java.lang.Object
9: 2155 68960 java.util.HashMap$Node
```
**dump注意事项**
- 在应用快要发生FGC的时候把堆数据导出来
， ，
- 查看快要发生FGC使用命令： < pid >
- 数据导出： < pid >
- 通过命令查看大对象： < pid > |less
**使用总结**
- 如果程序内存不足或者频繁GC， ，
- 要制作堆Dump可以直接使用jvm自带的jmap命令
- 可以先使用`jmap -heap`命令查看堆的使用情况，看一下各个堆空间的占用情况
- 使用`jmap -histo:[live]`查看堆内存中的对象的情况。如果有大量对象在持续被引用，并没有被释放掉，那就产生了内存泄露，就要结合代码，把不用的对象释放掉
- 也可以使用 `jmap -dump:format=b,file=<fileName>` 命令将堆信息保存到一个文件中，
- 在内存出现泄露、溢出或者其它前提条件下， ， ，
- 在用cms gc的情况下， ， ， ，
## jhat
jhat（ ） ， ， ， ， ， ， ，
```powershell
# 解析Java堆转储文件,并启动一个 web server
jhat heapDump.dump
```
## jconsole
jconsole(Java Monitoring and Management Console)是一个Java GUI监视工具， ， ， ， ， ， ，
**第一步**： ：
```powershell
JAVA_OPTS="$JAVA_OPTS -Djava.rmi.server.hostname=192.168.202.121 -Dcom.sun.management.jmxremote"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=12345"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=true"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.pwd.file=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/management/jmxremote.password"
```
**第二步**：配置权限文件
```powershell
[root@localhost bin]# cd /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/management/
[root@localhost management]# cp jmxremote.password.template jmxremote.password
[root@localhost management]# vi jmxremote.password
```
monitorRole QED
controlRole chenqimiao
**第三步**：
```powershell
[root@localhost management]# chmod 600 jmxremote.password jmxremote.access
```
这样基本配置就结束了， ， ， ， ， ：
请将127.0.0.1修改为本地真实的IP,我的服务器IP是192.168.202.121：
** 第四步**：
## jvisualvm
jvisualvm(JVM Monitoring/Troubleshooting/Profiling Tool)同jconsole都是一个基于图形化界面的、可以查看本地及远程的JAVA GUI监控工具， ， ， ， ， ，
**Visual GC(监控垃圾回收器)**
Java VisualVM默认没有安装Visual GC插件， ， ， ， ： ** 工具->插件** 安装Visual GC， ：
**大dump文件**
从服务器dump堆内存后文件比较大（ ） ， ， ， ， ：
```shell
default_options="-J-Xms24m -J-Xmx192m"
```
再重启VisualVM就行了。
## jmc
jmc（ ） ， ，
JMC的最主要的特征就是JFR（ ） ， ， ， ，
### 启动JFR
在商业版本上面， ， `-XX:+UnlockCommercialFeatures -XX:+FlightRecorder` 来启动应用。启动之后， ，
- **通过Java Mission Control启动JFR**
打开Java Mission Control点击对应的JVM启动即可， （ ， ） ：
- 记录固定一段时间的事件（ ： ）
- 持续进行记录
- **通过命令行启动JFR**
通过在启动的时候，增加参数：`-XX:+FlightRecorderOptions=string` 来启动真正地事件记录，这里的 `string` 可以是以下值（ ， ， ） ：
- `name=name` ： （ ， ）
- `defaultrecording=<ture|false>` ： ， ， ，
- `setting=paths` ：
- `delay=time` ： ， （ ： ， ）
- `duration=time` ：
- `filename=path` ：
- `compress=<ture|false>` ： （ ）
- `maxage=time` ：在循环使用的缓存中，事件数据保存的最大时长
- `maxsize=size` ： （ ： ， ）
### 常用JFR命令
- 启动recording
命令格式：`jcmd process_id JFR.start [options_list]`，
- dump出循环缓存中的数据
命令格式：`jcmd process_id JFR.dump [options_list]`， ：
- `name=name` ：
- `recording=n` ： （ ）
- `filename=path` ：
- 查看进程中所有recording
命令格式：` jcmd process_id JFR.check [verbose]`， ，
- 停止recording
命令格式：` jcmd process_id JFR.stop [options_list]`， ：
- `name=name` ：
- `recording=n` ：
- `discard=boolean` ： ， ，
- `filename=path` ：写入数据的文件名称
### 命令启动JFR案例
- **第一步**： （ ） ， ，
- **第二步**： ，
```powershell
[root@localhost bin]# jcmd 12234 VM.unlock_commercial_features
12234: Commercial Features already unlocked.
```
- **第三步**： ， ：
```powershell
jcmd < PID > JFR.start name=test duration=60s [settings=template.jfc] filename=output.jfr
```
`template.jfc` （在 `$JAVA_HOME/jre/lib/jfr` 下有 `default.jfc` 和 `profile.jfc` 模板）的配置收集 `60s` 的JVM信息， `output.jfr` 中。一旦记录完成之后，就可以复制.jfr文件到你的工作环境使用jmc GUI来分析。它几乎包含了排查jvm问题需要的所有信息， ：
```powershell
[root@localhost bin]# jcmd 12234 JFR.start name=test duration=60s filename=output.jfr
12234: Started recording 6. The result will be written to: /root/zookeeper-3.4.12/bin/output.jfr
[root@localhost bin]# ls -l
-rw-r--r-- 1 root root 298585 6月 29 11:09 output.jfr
```
**JFR（ ）
- Java Mission Control的最主要的特征就是Java Flight Recorder。正如它的名字所示， ，
- JFR的基本操作就是开启哪些事件（ ： ） ， ， ， （ ） ，
- 事件的类型、缓存的大小、事件数据的存储方式等等都是通过JVM参数、Java Mission Control的GUI界面、jcmd命令来控制的。JFR默认是编译进程序的， ， ， ，
### JFR概况
， ， ：
我们可以看到， ： ， ， ， ，
### JFR内存视图
Java Mission Control 可以看到非常多的信息， ， （ ， ） ， ： ， ， ： ， ， ： ， ； ； ，
### JFR 代码视图
这张图也有很多tab， ：
### JFR事件视图
下图显示了事件的概述视图：
## EclipseMAT
虽然Java虚拟机可以帮我们对内存进行回收， ， （ ） ， ， ， ， ，
**GC Roots**
JAVA虚拟机通过可达性（ ， ， （ ） ， ，
- 一个在current thread（ ） （ ） （ ）
- 线程自身或者system class loader（ ）
- native code（ ）
**内存泄漏**
当对象无用了，但仍然可达（未释放），垃圾回收器无法回收。
**Java四种引用类型**
- Strong References（ ）
普通的java引用， ：
- Soft Reference（ ）
当对象是Soft Reference可达时， ， ， ，
- Weak Reference（ ）
WeakReference不会强制对象保存在内存中。它拥有比较短暂的生命周期， ， ， `Reference Queue` 中，
系统为我们提供了WeakHashMap， ， ， ， ， ， ， ， ， ，
ReferenceQueue可以让你很容易地跟踪dead references。WeakReference类的构造函数有一个ReferenceQueue参数， ， ，
- Phantom Reference（ ）
其余Soft/Weak Reference区别较大是它的get()方法总是返回null。这意味着你只能用Phantom Reference本身， ） ， ， （ ， ） ，
**MAT视图与概念**
- **Shallow Heap**
Shallow Size就是对象本身占用内存的大小， ， （ ） （ ） ：
```java
public class String {
public final class String {8 Bytes header
private char value[]; 4 Bytes
private int offset; 4 Bytes
private int count; 4 Bytes
private int hash = 0; 4 Bytes
// ......
}
// "Shallow size“ of a String ==24 Bytes12345678
```
Java的对象成员都是些引用。真正的内存都在堆上， ， ，
- **Retained Heap**
Retained Heap值的计算方式是将Retained Set中的所有对象大小叠加。或者说， ， （ ）
一个ArrayList持有100000个对象， ， × ， ， （ ， ）
- **Histogram**
可列出每一个类的实例数。支持正则表达式查找，
- **Dominator Tree**
对象之间dominator关系树。如果从GC Root到达Y的的所有path都经过X， ，
- **Path to GC Roots**
，
意思是查看排除虚引用/弱引用/软引用等的引用链，因为被虚引用/弱引用/软引用的对象可以直接被GC给回收， （ ） ， ， ，
查看当前Object所有引用,被引用的对象：
- List objects with （ ）
- incoming references 引用到该对象的对象
- outcoming references 被该对象引用的对象
- Show objects by class （ ）
- incoming references 引用到该对象的对象
- outcoming references 被该对象引用的对象
- **OQL(Object Query Language)**
类似SQL查询语言： ： ： ：
```mysql
select * from com.example.mat.Listener
# 查找size＝
select * from java.util.ArrayList where size=0 and modCount=01
# 查找所有的Activity
select * from instanceof android.app.Activity
```
- **内存快照对比**
方式一： （ ）
方式二： （ ， ）
**MAT内存分析实战**
- **实战一：内存泄漏分析**
查找导致内存泄漏的类。既然环境已经搭好， ，
- 查找目标类
如果在开发过程中， ， ， ， ， ，
`select * from instanceof android.app.Activity`
- Paths to GC Roots：
查看一个对象到RC Roots是否存在引用链。要将虚引用/弱引用/软引用等排除，因为被虚引用/弱引用/软引用的对象可以直接被GC给回收
- 分析具体的引用为何没有被释放，并进行修复
**小技巧：**
- 当目的不明确时， ， ， ，
- 如果大对象筛选看不出区别， ，
- 直接按照包名直接查看GC引用链， ， ， ， ， ，
所以有时候进行MAT分析还是需要一些经验，
- **实战二：集合使用率分析**
集合在开发中会经常使用到， ， （ ， ） ， ， ，
- **筛选目标对象**
- **Show Retained Set（ ）
- **筛选指定的Object（ ， ）
- **查看指定类的Immediate dominators**
**Collections fill ratio**
这种方式只能查看那些具有预分配内存能力的集合， ， ：
- **实战三：
当Hash集合中过多的对象返回相同Hash值的时候， （ ） ，
- **Map Collision Ratio**
检测每一个HashMap或者HashTable实例并按照碰撞率排序：
- **查看Immediate dominators**
- **通过HashEntries查看key value**
- **Array等其它集合分析方法类似**
- **实战四：
- **通过OQL查询empty并且未修改过的集合：
```mysql
select * from java.util.ArrayList where size=0 and modCount=01
select * from java.util.HashMap where size=0 and modCount=0
select * from java.util.Hashtable where count=0 and modCount=012
```
- **Immediate dominators(查看引用者)**
- **计算空集合的Retained Size值，
## 🔥火焰图
火焰图是用来分析程序运行瓶颈的工具。火焰图也可以用来分析 Java 应用。
### 环境安装
确认你的机器已经安装了**git、jdk、perl、c++编译器**。
#### 安装Perl
```shell
wget http://www.cpan.org/src/5.0/perl-5.26.1.tar.gz
tar zxvf perl-5.26.1.tar.gz
cd perl-5.26.1
./Configure -de
make
make test
make install
```
wget后面的路径可以按需更改。安装过程比较耗时间，
#### C++编译器
```shell
apt-get install g++
```
一般用于编译c++程序， ，
#### clone相关项目
下载下来所需要的两个项目（ ） ：
```shell
git clone https://github.com/jvm-profiling-tools/async-profiler
git clone https://github.com/brendangregg/FlameGraph
```
#### 编译项目
下载好以后， ， ：
```shell
cd async-profiler
make
```
### 生成文件
#### 生成火焰图数据
可以从 github 上下载 [async-profiler ](https://github.com/jvm-profiling-tools/async-profiler ) 的压缩包进行相关操作。进入async-profiler项目的目录下， ：
```shell
./profiler.sh -d 60 -o collapsed -f /tmp/test_01.txt ${pid}
```
上面的-d表示的是持续时长， ， ， ， ， （ ） ， ， ， ，
#### 生成svg文件
上一步产生的文件里的内容，肉眼是很难看懂的，所以现在[FlameGraph](https://github.com/brendangregg/FlameGraph)的作用就体现出来了，它可以读取该文件并生成直观的火焰图，现在进入该项目目录下面，执行如下语句：
```shell
perl flamegraph.pl --colors=java /tmp/test_01.txt > test_01.svg
```
因为是perl文件， ， ， ， ， ， ， ，
#### 展示火焰图
现在下载下来该文件，使用浏览器打开，效果如下：
### 火焰图案例
生成的[火焰图案例](images/DevOps/火焰图案例.svg)如下：
#### 瓶颈点1
CoohuaAnalytics$KafkaConsumer:::send方法中Gzip压缩占比较高。已经定位到方法级别， ， ， ：
#### 瓶颈点2
展开2这个波峰， ， ：
直接看代码：
果然如推断， ：
#### 瓶颈点3
展开波峰3， ：
定位到具体的代码， ：
