由于Java11中
ZGC的出现，尽量不要对GC调优的研究下太多功夫，对未来来说，这是贬值的。
新生代的垃圾回收器
| 收集器 | 算法 | 收集器类型 | 说明 | 适用场景 |
|---|---|---|---|---|
| Serial | 复制算法 | 单线程 | 进行垃圾回收时，须暂停所有工作线程，知道回收完成 | 简单高效，适合内存不大的情况 |
| ParNew | 复制算法 | 多线程并行 | 它是Serial收集器的多线程版本 | 搭配CMS的首选 |
| Parallel Scavenge（吞吐量优先收集器） | 复制算法 | 多线程并行 | 类似ParNew，更加关注吞吐量 | 主要适合后台运算不需要太多交互的任务 |
老年代的垃圾回收器
| 收集器 | 算法 | 收集器类型 | 说明 | 适用场景 |
|---|---|---|---|---|
| Serial Old | 标记整理 | 单线程 | JDK7/8默认的 | Client模式下虚拟机适用 |
| Parallel Old | 标记整理 | 多线程并行 | Parallel Scavenge的老年代版本 | 在注重吞吐量场景下使用 |
| CMS | 标记清除 | 并行、并发 | 尽可能缩短GC时用户线程停止的时间，缺点：1、容易有内存碎片 2、需要更多的cpu资源 3、产生浮动垃圾，需要更大的堆空间 | 重视服务的相应速度 |
| G1 | 跨代、标记整理 | 并行、并发 | JDK7正式引入，采用分区回收的思维，基本不牺牲吞吐量的前提下，低停顿内存回收，可预测的停顿是其最大的优势 | 面向服务端应用的垃圾回收器，目标是取代CMS |
垃圾回收器搭配
image-20200803224511274
CMS和Serial Old两个老年代连在一起，这里的意思是CMS作为主收集器，当用户线程内存不足时，采用备用方案Serial Old收集，因为CMS收集器需要更多的内存。
JVM的调优
首先说明，调优不是为了提升性能，而是让程序运行的更稳定，调优是通过几天或者几周观察系统日志不断调试才能做出来的，不是加几个参数就能调优的。
调优的步骤及思路：
- 监视分析GC日志
- 分析结果，判断是否需要优化
- 调整垃圾回收器类型，内存的分配
- 全面应用参数
