虚拟机夯实之路————选择适合的垃圾收集器

Epsilon收集器

    它更像一个“自动内存管理子系统”。一个垃圾收集器除了垃圾收集这个本职工作之外，它还要负责堆的管理与布局、对象的分配、与解释器的协作、与编译器的协作、与监控子系统协作等职责，其中至少堆的管理和对象的分配这部分功能是Java虚拟机能够正常运作的必要支持，是一个最小化功能的垃圾收集器也必须实现的内容。

收集器的权衡

衡量垃圾收集器的三项最重要的指标是: 内存占⽤(Footprint)、吞吐量(Throughput)和延 迟(Latency)，三者共同构成了⼀个“不可能三⻆”。三者总体的表现会随技术进步⽽越来 越好，但是要在这三个⽅⾯同时具有卓越表现的“完美”收集器是极其困难甚⾄是不可能 的，⼀款优秀的收集器通常最多可以同时达成其中的两项。

我们应该如何选择⼀款适合⾃⼰应⽤的收集器呢?这个问题的答案主要受以下三个因素影响:

1. 应⽤程序的主要关注点是什么? 如果是数据分析、科学计算类的任务，⽬标是能尽快算出结果，那吞吐量就是主要关注点; 如果是SLA应⽤，那停顿时间直接影响服务质量，严重的甚⾄会导致事务超时，这样延迟就是主要关注点; ⽽如果是客户端应⽤或者嵌⼊式应⽤，那垃圾收集的内存占⽤则是不可忽视的。
2. 运⾏应⽤的基础设施如何? 譬如硬件规格，要涉及的系统架构是x86-32/64、SPARC还是 ARM /Aarch64; 处理器的数量多少，分配内存的⼤⼩; 选择的操作系统是Linux、Solaris 还是Windows等。
3. 使⽤JDK的发⾏商是什么? 版本号是多少? 是ZingJDK/Zulu、OracleJDK、Open-JDK、 OpenJ9抑或是其他公司的发⾏版?该JDK对应了《Java虚拟机规范》的哪个版本? ⼀般来说，收集器的选择就从以上这⼏点出发来考虑。举个例⼦，假设某个直接⾯向⽤户提供服务的B/S系统准备选择垃圾收集器，⼀般来说延迟时间是这类应⽤的主要关注点。

虚拟机及垃圾收集器日志

    HotSpot所有功能的日志都收归到了“-Xlog”参数上，这个参数的能力也相应被极大拓展 了：

    命令行中最关键的参数是选择器（Selector），它由标签（Tag）和日志级别（Level）共同组成。标签可理解为虚拟机中某个功能模块的名字，它告诉日志框架用户希望得到虚拟机哪些功能的日志输出。垃圾收集器的标签名称为“gc”，由此可见，垃圾收集器日志只是HotSpot众多功能日志的其中一 项，全部支持的功能模块标签名如下所示：

日志级别从低到高，共有Trace，Debug，Info，Warning，Error，Off六种级别，日志级别决定了输出信息的详细程度，默认级别为Info，HotSpot的日志规则与Log4j、SLF4j这类Java日志框架大体上是一致的。另外，还可以使用修饰器（Decorator）来要求每行日志输出都附加上额外的内容，支持附加 在日志行上的信息包括：

time：当前日期和时间。

uptime：虚拟机启动到现在经过的时间，以秒为单位。

timemillis：当前时间的毫秒数，相当于System.currentTimeMillis()的输出。

uptimemillis：虚拟机启动到现在经过的毫秒数。

timenanos：当前时间的纳秒数，相当于System.nanoTime()的输出。

uptimenanos：虚拟机启动到现在经过的纳秒数。

pid：进程ID。

tid：线程ID。

level：日志级别。

tags：日志输出的标签集。

如果不指定，默认值是uptime、level、tags这三个，此时日志输出类似于以下形式：