JVM_常见垃圾回收器
常见的垃圾回收器有哪些？
- Serial 收集器：单线程工作的收集器，在垃圾收集时，必须暂停其他所有工作线程，直到收集结束
- ParNew 收集器：Serial 收集器的多线程并行版本
- Parallel Scavenge 收集器：与 ParNew 相似，关注点是吞吐量（CPU 中运行用户代码时间/CPU 总消耗时间的比值）
- Serial Old 收集器：Serial 收集器的老年代版本；单线程收集器
- Parallel Old 收集器：Parallel Scavenge 收集器的老年代版本
- CMS 收集器：是一种以获得最短回收停顿时间为目标的收集器
- G1 收集器：具有局部收集的设计思路和基于 Region 的内存布局
CMS 收集器？
- CMS 收集器是以获取最短回收停顿时间为目标的收集器
- 基于标记 – 清除算法实现，垃圾回收过程：
- 初始标记：单线程运行，标记 GC Roots 能直达的对象
- 并发标记：无停顿，和用户线程同时运行，从 GC Roots 的直达对象开始遍历整个对象图
- 重新标记：多线程运行，需要暂停所有用户线程，修正并发标记期间产生对象
- 并发清除：无停顿，和用户线程同时执行，清理掉标记阶段判断的已经死亡的对象
- 缺点：
- 依赖 CPU 资源
- 无法处理浮动垃圾
- 收集结束会有大量空间碎片
G1 收集器
- G1 收集器：具有局部收集的设计思路和基于 Region 的内存布局
- 垃圾回收步骤：
- 初始标记：标记 GC Roots 能直达的对象
- 并发标记：和用户线程同时运行，从 GC Roots 开始遍历对象图
- 最终标记：标记在并发标记过程中产生的垃圾
- 筛选回收：指定回收计划，选择多个 Region 构成回收集，把回收集中 Region 的存活对象复制到空的 Region 中，再清理掉旧的 Region 空间
有了 CMS，为什么还要引入 G1？
CMS 有三个明显的缺点：
- 依赖对 CPU 资源
- 无法处理浮动垃圾
- 收集结束会有大量空间碎片
G1 主要解决了内存碎片多的问题
垃圾收集器应该如何选择？
- Serial：在没有停顿时间要求的单线程处理器上运行
- Parallel：优先考虑应用程序的性能，对停顿时间没有什么要求
- CMS/G1：对停顿要求和用户体验有要求的场景