读Java性能权威指南（第2版）笔记19_垃圾回收F
1. G1垃圾回收器
1.1. 垃圾优先（garbage first）
1.2. 在堆内离散的区域上进行操作
1.2.1. 默认大约有2048个
1.2.2. 代的区域不需要是连续的
1.2.3. 可能属于老年代
- 1.2.3.1. 并发后台线程寻找没有被引用的对象时，一些区域会比其他区域有更多的垃圾
1.2.4. 可能属于新生代
1.3. 并发回收器（concurrent collector）
1.3.1. 标记老年代中不使用的对象和应用程序线程同时发生（它们同时运行）
1.3.2. 并不是完全并发的
-
1.3.2.1. 新生代的标记和压缩仍需要暂停所有应用程序线程
-
1.3.2.2. 老年代的压缩也是在应用程序线程暂停期间发生的
1.4. 停顿
1.4.1. 较长的Full GC停顿
- 1.4.1.1. 理想情况下，你已经优化得足够好，就不会发生这种情况
1.4.2. 较短的Young GC停顿
- 1.4.2.1. 包括回收和压缩部分老年代的混合回收
1.4.3. 非常短的标记线程停顿
1.5. 4个逻辑操作
1.5.1. 新生代回收
- 1.5.1.1. Young GC
1.5.2. 后台并发标记周期
-
1.5.2.1. 第一个阶段
-
1.5.2.1.1. JDK 8中被称为初始标记（initial mark）
-
1.5.2.1.2. JDK 11中被称为并发开始（concurrent start）
-
1.5.2.1.2.1. 大小以区域为单位，而不是MB
-
1.5.2.1.2.2. 一个新的区域：巨型对象区域，是老年代的一部分
-
-
1.5.2.1.3. 暂停所有的应用程序线程
-
-
1.5.2.2. 重新标记（remark）阶段
- 1.5.2.2.1. 会暂停应用程序线程，不过时间通常比较短
-
1.5.2.3. 正常的清理（cleanup）阶段
- 1.5.2.3.1. 会暂停应用程序线程，不过时间通常比较短
1.5.3. Mixed GC
-
1.5.3.1. 混合垃圾回收
-
1.5.3.2. 执行正常的新生代回收时，也会回收后台扫描时标记的一些区域
-
1.5.3.3. 在JDK 11中，首次Mixed GC被标记为Prepared Mixed，紧接着是并发清理
-
1.5.3.4. 将执行多次，持续到（几乎）所有标记的区域都完成回收,恢复常规的Young GC周期
1.5.4. 必要的Full GC
-
1.5.4.1. 并发模式失败（concurrent mode failure）
-
1.5.4.1.1. 老年代在这个标记周期完成之前被填满了
-
1.5.4.1.2. 应该增加堆的大小
-
1.5.4.1.3. G1 GC的后台处理必须更快
-
1.5.4.1.4. 必须优化标记周期以更快地运行
-
-
1.5.4.2. 晋升失败（promotion failure）
-
1.5.4.2.1. 已经开始执行Mixed GC以清理老年代的区域。在它还没有清理出足够的空间之前，有太多的对象从新生代晋升，以至于老年代的空间还是用完了
-
1.5.4.2.2. 混合回收需要执行得更快
-
1.5.4.2.3. 每次新生代回收都需要处理更多的老年代区域
-
-
1.5.4.3. 疏散失败（evacuation failure）
-
1.5.4.3.1. 堆已经非常满了或者碎片化很严重
-
1.5.4.3.2. 增加堆的大小
-
-
1.5.4.4. 巨型对象分配失败（humongous allocation failure）
-
1.5.4.5. 元数据GC阈值（metadata GC threshold）
-
1.5.4.5.1. 元空间本质上是一个独立的堆，并且独立于主堆进行回收
-
1.5.4.5.2. 在JDK 8中，当它需要进行回收时，G1 GC会在主堆上执行Full GC（紧跟着新生代回收）
-
1.5.4.5.3. 在JDK 11中，元空间可以被回收，也可以调整大小，而不必进行Full GC
-
1.6. 运行G1的JVM经过良好优化后应该只经历Young GC、Mixed GC和并发GC周期
2. 优化G1 GC
2.1. 目标是确保没有因并发模式失败或疏散失败而产生Full GC
2.1.1. 从设置合理的停顿时间目标开始
2.2. 在JDK 8中执行Full GC时，使用的是单线程，这就会造成停顿时间比平常更长
2.3. 在JDK 11中，Full GC由多个线程执行，从而使停顿时间更短
2.4. 增加老年代的大小，增加堆空间的总大小，或者调整分代比例
2.5. 增加后台线程的数量（假设有足够的CPU）
2.6. 更频繁地执行G1 GC后台活动
2.7. 增加Mixed GC周期的工作量
2.8. -XX:MaxGCPauseMillis=N标志
2.8.1. 该标志有默认值，即200毫秒
2.9. 优化G1后台线程
2.9.1. -XX:ParallelGCThreads=N标志
- 2.9.1.1. 影响应用程序线程暂停阶段的线程数量
2.9.2. -XX:ConcGCThreads=N标志
-
2.9.2.1. 影响用于并发标记的线程数量
-
2.9.2.2. 如果有额外的CPU可用
-
2.9.2.3. 计算方式
-
2.9.2.3.1. ConcGCThreads = (ParallelGCThreads + 2) / 4
-
2.9.2.3.2. 基于整数的
-
2.10. 优化G1 GC的运行频率
2.10.1. G1 GC提前开始后台标记周期，也可以尽量减少Full GC
2.10.2. 当堆达到-XX:InitiatingHeapOccupancyPercent=N设定的占用率时，这个周期才会开始
2.10.3. -XX:InitiatingHeapOccupancyPercent=N
-
2.10.3.1. 默认值是45，表示老年代占整个堆的比例
-
2.10.3.2. 为了让后台线程运行得更频繁
2.11. 优化G1 GC的Mixed GC周期
2.11.1. 在Mixed GC周期中处理更多的区域
2.11.2. -XX:G1MixedGCCountTarget=N标志
-
2.11.2.1. 处理区域时Mixed GC周期的最大总次数
-
2.11.2.2. 混合周期的数量上限
-
2.11.2.3. 默认值是8
-
2.11.2.4. 减小该值有助于解决晋升失败的问题（代价是Mixed GC周期的停顿时间更长）
2.11.3. MaxGCPauseMillis设定
-
2.11.3.1. GC可接受的最大停顿毫秒数
-
2.11.3.2. 增加MaxGCPauseMillis标志的值，可以在每次Mixed GC期间回收更多的老年代区域
3. JDK 12引入的回收器
3.1. 现存的并发回收器并不是完全并发的
3.1.1. G1 GC和CMS回收器都没有新生代的并发回收，回收新生代需要暂停所有应用程序线程
3.1.2. 没有进行并发压缩
3.2. Z垃圾回收器（Z garbage collector，ZGC）
3.2.1. 在JDK 11中首次出现
3.2.2. AdoptOpenJDK构建的JVM（或者你自己从源码编译的JDK）包含
3.2.3. Oracle构建的JVM包含
3.3. Shenandoah垃圾回收器
3.3.1. 在JDK 12中首次出现
3.3.2. 已经被向后移植到了JDK 8和JDK 11中
3.3.3. AdoptOpenJDK构建的JVM（或者你自己从源码编译的JDK）包含
3.4. -XX:+UnlockExperimentalVMOptions
3.4.1. 默认情况下是false
3.5. -XX:+UseZGC
3.6. -XX:+UseShenandoahGC
3.7. 都可以并发压缩堆
3.7.1. 可以在不暂停所有应用程序线程的情况下移动堆中的对象
3.7.2. 堆不再需要分代（不再有新生代和老年代了，只有一个堆）
3.7.3. 应用程序线程的操作延迟预期会减少（至少在很多情况下会）
3.8. ZGC和Shenandoah会有在很短的时间内，所有的应用程序线程都会暂停
3.8.1. 目标是将这些时间保持在非常短的水平，即在10毫秒左右
3.9. 并发压缩对延迟的影响
3.9.1. 垃圾回收的停顿一般是造成延迟异常的最大原因
3.10. 并发压缩回收器对吞吐量的影响
3.10.1. 并发压缩回收器通常会比G1 GC后台线程执行更多的后台处理
3.10.2. 没有足够的CPU周期，回收器也会出现之前看到的并发失败，最终发生Full GC
3.10.3. 有足够的CPU，那么使用这两种回收器时的吞吐量将高于G1 GC或Throughput回收器的吞吐量
4. Epsilon回收器
4.1. JDK 11的一个什么都不做的回收器
4.1.1. 为JDK内部测试设计的
4.1.2. 对象永远不会从堆中回收，当堆被填满时，你会得到一个内存溢出错误的提示
4.2. 你确定程序需要的内存永不会比你提供的大
4.3. 一旦遇到了适用Epsilon回收器的情况，它会带来很好的性能提升
4.4. 两种情况下是有用的
4.4.1. 存活时间非常短的应用程序
4.4.2. 特意编写的、重复使用内存并且永远不执行新分配的应用程序
- 4.4.2.1. 在某些内存受限的嵌入式环境中很有用
