| :one: | :two: | :three: | :four: | :five: | :six: |

- [ ] Java 简介

- [x] [Java 开发环境配置](docs/basic/Java开发环境配置.md)

- [ ] Java 基础语法

- [x] [Java 数据类型](docs/basic/Java数据类型.md)

- [x] [Java 操作符](docs/basic/Java操作符.md)

- [x] [Java 控制语句](docs/basic/Java控制语句.md)

- [x] Java 方法

- [x] [Java 数组](docs/basic/Java数组.md)

- [x] [Java 枚举](docs/basic/Java枚举.md)

- [x] [Java 异常](docs/basic/Java异常.md)

- [x] [Java 输入输出](docs/basic/Java输入输出.md)

- [x] [Java 容器概述](docs/container/Java容器概述.md)

- [x] [List](docs/container/List.md)

- [x] [Map](docs/container/Map.md)

- [x] [Set](docs/container/Set.md)

- [x] [Queue](docs/container/Queue.md)

- [x] [第一章 并发简介](docs/concurrent/1-并发简介.md)

- [x] [第二章 线程基础](docs/concurrent/2-线程基础.md)

- [x] [第三章 并发机制的底层实现](docs/concurrent/3-并发机制的底层实现.md)

- [x] [第四章 内存模型](docs/concurrent/4-内存模型.md)

- [x] [第五章 同步容器和并发容器](docs/concurrent/5-同步容器和并发容器.md)

- [x] [第六章 锁](docs/concurrent/6-锁.md)

- [x] [第七章 原子变量类](docs/concurrent/7-原子变量类.md)

- [x] [第八章 并发工具类](docs/concurrent/8-并发工具类.md)

- [x] [第九章 线程池](docs/concurrent/9-线程池.md)

- [x] [Java 并发面试题集](docs/concurrent/Java并发面试题集.md)

- [第一章 运行时数据区域](docs/jvm/1-运行时数据区域.md)

- [第二章 垃圾收集](docs/jvm/2-垃圾收集.md)

- [第三章 类加载机制](docs/jvm/3-类加载机制.md)

- [第四章 JVM 调优](docs/jvm/4-JVM调优.md)

- [JVM 调优概述](#jvm-调优概述)

- [性能定义](#性能定义)

- [调优原则](#调优原则)

- [GC 优化的过程](#gc-优化的过程)

- [HotSpot VM 参数](#hotspot-vm-参数)

- [JVM 内存配置](#jvm-内存配置)

- [GC 类型配置](#gc-类型配置)

- [辅助配置](#辅助配置)

- [典型配置](#典型配置)

- [堆大小设置](#堆大小设置)

- [回收器选择](#回收器选择)

- [JVM 实战](#jvm-实战)

- [分析 GC 日志](#分析-gc-日志)

- [1. 获取 GC 日志](#1-获取-gc-日志)

- [2. 如何分析 GC 日志](#2-如何分析-gc-日志)

- 吞吐量 - 指不考虑 GC 引起的停顿时间或内存消耗，垃圾收集器能支撑应用达到的最高性能指标。

- 延迟 - 其度量标准是缩短由于垃圾啊收集引起的停顿时间或者完全消除因垃圾收集所引起的停顿，避免应用运行时发生抖动。

- 内存占用 - 垃圾收集器流畅运行所需要的内存数量。

GC 优化的两个目标：

1. 将进入老年代的对象数量降到最低

2. 减少 Full GC 的执行时间

GC 优化的基本原则是：将不同的 GC 参数应用到两个及以上的服务器上然后比较它们的性能，然后将那些被证明可以提高性能或减少 GC 执行时间的参数应用于最终的工作服务器上。

除了可以在 JDK7 及更高版本中使用的 G1 收集器以外，其他分代 GC 都是由 Oracle JVM 提供的。关于分代 GC，就是对象在 Eden 区被创建，随后被转移到 Survivor 区，在此之后剩余的对象会被转入老年代。也有一些对象由于占用内存过大，在 Eden 区被创建后会直接被传入老年代。老年代 GC 相对来说会比新生代 GC 更耗时，因此，减少进入老年代的对象数量可以显著降低 Full GC 的频率。你可能会以为减少进入老年代的对象数量意味着把它们留在新生代，事实正好相反，新生代内存的大小是可以调节的。

Full GC 的执行时间比 Minor GC 要长很多，因此，如果在 Full GC 上花费过多的时间（超过 1s），将可能出现超时错误。

- 如果**通过减小老年代内存来减少 Full GC 时间**，可能会引起 OutOfMemoryError 或者导致 Full GC 的频率升高。

- 另外，如果**通过增加老年代内存来降低 Full GC 的频率**，Full GC 的时间可能因此增加。

因此，你**需要把老年代的大小设置成一个“合适”的值**。

**GC 优化需要考虑的 JVM 参数**

| **类型** | **参数** | **描述** |

| -------------- | ------------------- | ----------------------------- |

| 堆内存大小 | `-Xms` | 启动 JVM 时堆内存的大小 |

| | `-Xmx` | 堆内存最大限制 |

| 新生代空间大小 | `-XX:NewRatio` | 新生代和老年代的内存比 |

| | `-XX:NewSize` | 新生代内存大小 |

| | `-XX:SurvivorRatio` | Eden 区和 Survivor 区的内存比 |

GC 优化时最常用的参数是`-Xms`,`-Xmx`和`-XX:NewRatio`。`-Xms`和`-Xmx`参数通常是必须的，所以`NewRatio`的值将对 GC 性能产生重要的影响。

有些人可能会问**如何设置永久代内存大小**，你可以用`-XX:PermSize`和`-XX:MaxPermSize`参数来进行设置，但是要记住，只有当出现`OutOfMemoryError`错误时你才需要去设置永久代内存。

GC 优化的过程和大多数常见的提升性能的过程相似，下面是笔者使用的流程：

你需要监控 GC 从而检查系统中运行的 GC 的各种状态。

在检查 GC 状态后，你需要分析监控结构并决定是否需要进行 GC 优化。如果分析结果显示运行 GC 的时间只有 0.1-0.3 秒，那么就不需要把时间浪费在 GC 优化上，但如果运行 GC 的时间达到 1-3 秒，甚至大于 10 秒，那么 GC 优化将是很有必要的。

但是，如果你已经分配了大约 10GB 内存给 Java，并且这些内存无法省下，那么就无法进行 GC 优化了。在进行 GC 优化之前，你需要考虑为什么你需要分配这么大的内存空间，如果你分配了 1GB 或 2GB 大小的内存并且出现了`OutOfMemoryError`，那你就应该执行**堆快照（heap dump）**来消除导致异常的原因。

如果你决定要进行 GC 优化，那么你需要选择一个 GC 类型并且为它设置内存大小。此时如果你有多个服务器，请如上文提到的那样，在每台机器上设置不同的 GC 参数并分析它们的区别。

在设置完 GC 参数后就可以开始收集数据，请在收集至少 24 小时后再进行结果分析。如果你足够幸运，你可能会找到系统的最佳 GC 参数。如若不然，你还需要分析输出日志并检查分配的内存，然后需要通过不断调整 GC 类型/内存大小来找到系统的最佳参数。

如果 GC 优化的结果令人满意，就可以将参数应用到所有服务器上，并停止 GC 优化。

在下面的章节中，你将会看到上述每一步所做的具体工作。

| 配置 | 描述 |

| ----------------- | -------------------- |

| `-Xms` | 堆空间初始值。 |

| `-Xmx` | 堆空间最大值。 |

| `-XX:NewSize` | 新生代空间初始值。 |

| `-XX:MaxNewSize` | 新生代空间最大值。 |

| `-Xmn` | 新生代空间大小。 |

| `-XX:PermSize` | 永久代空间的初始值。 |

| `-XX:MaxPermSize` | 永久代空间的最大值。 |

| -XX:+UseParNewGC | 使用 ParNew + Serial Old 垃圾回收器组合 |

| 配置 | 描述 |

| --------------------------------- | ------------------------ |

| `-XX:+PrintGCDetails` | 打印 GC 日志 |

| `-Xloggc:<filename>` | 指定 GC 日志文件名 |

| `-XX:+HeapDumpOnOutOfMemoryError` | 内存溢出时输出堆快照文件 |

**年轻代的设置很关键。**

JVM 中最大堆大小有三方面限制：

1. 相关操作系统的数据模型（32-bt 还是 64-bit）限制；

2. 系统的可用虚拟内存限制；

3. 系统的可用物理内存限制。

- 持久代一般固定大小为 64m。使用 `-XX:PermSize` 设置。

- 官方推荐年轻代占整个堆的 3/8。使用 `-Xmn` 设置。

JVM 给了三种选择：串行收集器、并行收集器、并发收集器。

获取 GC 日志有两种方式：

- 使用命令动态查看

- 在容器中设置相关参数打印 GC 日志

`jstat -gc` 统计垃圾回收堆的行为：

也可以设置间隔固定时间来打印：

这个命令意思就是每隔 2000ms 输出 1262 的 gc 情况，一共输出 20 次

Tomcat 设置示例：

- `-Xms2000m -Xmx2000m -Xmn800m -XX:PermSize=64m -XX:MaxPermSize=256m`

Xms，即为 jvm 启动时得 JVM 初始堆大小,Xmx 为 jvm 的最大堆大小，xmn 为新生代的大小，permsize 为永久代的初始大小，MaxPermSize 为永久代的最大空间。

- `-XX:SurvivorRatio=4`

SurvivorRatio 为新生代空间中的 Eden 区和救助空间 Survivor 区的大小比值，默认是 8，则两个 Survivor 区与一个 Eden 区的比值为 2:8,一个 Survivor 区占整个年轻代的 1/10。调小这个参数将增大 survivor 区，让对象尽量在 survitor 区呆长一点，减少进入年老代的对象。去掉救助空间的想法是让大部分不能马上回收的数据尽快进入年老代，加快年老代的回收频率，减少年老代暴涨的可能性，这个是通过将-XX:SurvivorRatio 设置成比较大的值（比如 65536)来做到。

- `-verbose:gc -Xloggc:$CATALINA_HOME/logs/gc.log`

将虚拟机每次垃圾回收的信息写到日志文件中，文件名由 file 指定，文件格式是平文件，内容和-verbose:gc 输出内容相同。

- `-Djava.awt.headless=true` Headless 模式是系统的一种配置模式。在该模式下，系统缺少了显示设备、键盘或鼠标。

- `-XX:+PrintGCTimeStamps -XX:+PrintGCDetails`

设置 gc 日志的格式

- `-Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.rmi.dgc.client.gcInterval=600000`

指定 rmi 调用时 gc 的时间间隔

- `-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15` 采用并发 gc 方式，经过 15 次 minor gc 后进入年老代

Young GC 回收日志:

Full GC 回收日志:

通过上面日志分析得出，PSYoungGen、ParOldGen、PSPermGen 属于 Parallel 收集器。其中 PSYoungGen 表示 gc 回收前后年轻代的内存变化；ParOldGen 表示 gc 回收前后老年代的内存变化；PSPermGen 表示 gc 回收前后永久区的内存变化。young gc 主要是针对年轻代进行内存回收比较频繁，耗时短；full gc 会对整个堆内存进行回城，耗时长，因此一般尽量减少 full gc 的次数

通过两张图非常明显看出 gc 日志构成：

Young GC 日志:

Full GC 日志:

- [JVM（4）：Jvm 调优-命令篇](http://www.importnew.com/23761.html)

- [Java 系列笔记(4) - JVM 监控与调优](https://www.cnblogs.com/zhguang/p/Java-JVM-GC.html)

- [Java 服务 GC 参数调优案例](https://segmentfault.com/a/1190000005174819)

- [JVM 调优总结（5）：典型配置](http://www.importnew.com/19264.html)

- [如何合理的规划一次 jvm 性能调优](https://juejin.im/post/59f02f406fb9a0451869f01c)

- [jvm 系列(九):如何优化 Java GC「译」](http://www.ityouknow.com/jvm/2017/09/21/How-to-optimize-Java-GC.html)