深入理解Java虚拟机读书笔记--5垃圾收集器
对应《深入理解Java虚拟机》3.5 3.6 节的内容
传统垃圾收集器(3.5)
《Java虚拟机规范》中对垃圾收集器应该如何实现并没有做出任何规定，因此不同的厂商、不同版本的虚拟机所包含的垃圾收集器都可能会有很大差别，不同的虚拟机一般也都会提供各种参数供用户根据自己的应用特点和要求组合出各个内存分代所使用的收集器。
- 如果两个收集器之间存在连线，就说明它们可以搭配使用
- 图中收集器所处的区域，则表示它是属于新生代收集器抑或是老年代收集器
- 我们选择的只是对具体应用最合适的收集器
- 在 JDK8 时将
Serial + CMS、ParNew + Serial Old这两个组合声明为废弃（JEP 173），并在 JDK9 中完全取消了这些组合的支持（JEP214）
Serial收集器
- 最基础、历史最悠久的收集器
- 单线程工作的收集器
- Stop The World 带给用户恶劣的体验
- 迄今为止，它依然是HotSpot虚拟机运行在客户端模式下的默认新生代收集器
- 简单而高效
- 所有收集器里额外内存消耗最小的
ParNew收集器
- ParNew 收集器实质上是Serial收集器的多线程并行版本
- 除了同时使用多条线程进行垃圾收集之外，其余的行为都与Serial收集器完全一致
- 在 JDK 7 之前的遗留系统中首选的新生代收集器就是 ParNew收集器，其中有一个与功能、性能无关但其实很重要的原因是：
除了Serial收集器外，目前只有它能与 CMS 收集器配合工作。 - ParNew收集器是激活 CMS后（-XX:+UseConcmarkSweepGC）的默认新生代收集器，也可以使用 -XX:+/-UseParNewGC 选项来强制指定或者禁用它。
- G1是一个面向全堆的收集器，不再需要其他新生代收集器的配合工作。所以自JDK 9开始，ParNew 加 CMS 收集器的组合就不再是官方推荐的服务端模式下的收集器解决方案了。官方希望它能完全被G1所取代，甚至还取消了 ParNew 加
Serial Old 以及 Serial 加 CMS 这两组收集器组合的支持（其实原本也很少人这样使用），并直接取消了 -XX:+UseParNewGC 参数，这意味着ParNew和CMS从此只能互相搭配使用，再也没有其他收集器能够和它们配合了。 - ParNew收集器在单核心处理器的环境中绝对不会有比Serial收集器更好的效果。随着可以被使用的处理器核心数量的增加，ParNew对于垃圾收集时系统资源的高效利用还是很有好处的；它默认开启的收集线程数与处理器核心数量相同，在处理器核心非常多的环境中，可以使用 -XX:ParallelGCThreads 参数来限制垃圾收集的线程数。
Parallel Scavenge收集器
- 基于标记-复制算法实现的收集器
- 并行收集的多线程收集器
- Parallel Scavenge 收集器的目标是达到一个可控制的吞吐量（Throughput 吞吐量就是处理器用于运行用户代码的时间与处理器总消耗时间的比值）
- 提供了两个参数用于精确控制吞吐量，
- 也经常被称作“吞吐量优先收集器”
- Parallel Scavenge 收集器还有一个参数
-XX:+UseAdaptiveSizePolicy。这是一个开关参数，当这个参数被激活之后，就不需要人工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象大小（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。- 只需要把基本的内存数据设置好（如-Xmx设置最大堆），
- 然后使用 -XX:MaxGCPauseMillis 参数（更关注最大停顿时间）
或-XX:GCTimeRatio（更关注吞吐量）参数给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。
Serial Old收集器
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
