垃圾收集器选型因素
- 应用程序的主要关注点是什么?如果是数据分析、科学计算类的任务,目标是尽快算出结果,那吞吐量就是主要关注点;如果是SLA应用,那停顿时间直接影响服务质量,严重的甚至会导致事物超时,这样延迟就是主要的关注点;而如果是客户端应用或者嵌入式应用,那垃圾收集的内存占用则是侧重点。
- 运行应用的基础设施如何?譬如硬件规格,要设计的系统时x86-32/64、SPARC还是ARM/Aarch64;处理器的数量是多少,分配的内存大小;选择的操作系统是Linux、Solaris还是Windos等。
- 使用的JDK的发行版是什么?版本号是多少?是ZingJDK/Zulu、OracleJDK、OpenJDK、OpenJ9抑或是其他公司的发行版?该JDK对应了《Java虚拟机规范》的哪个版本?
一般来说收集器的选择就从以上几点考虑,举个例子,假设某个直接面向用户提供服务的B/S系统准备选择垃圾收集器,一般来说延迟时间是这类应用的主要关注点,那么:
- 如果你有充足的预算单没有太多调优经验,那么一套代商业技术支持的专有硬件或者软件解决方案是不错的选择,Azul公司以前主推的Vega系统和现在主推的Zing VM是这方面的代表,这样你就可以使用传说中的C4收集器了。
- 如果你虽然没有足够预算去使用商业解决方案,但能够掌控软硬件型号,使用较新的版本,同时又特别注重延迟,那ZGC很值得尝试。
- 如果你对还处于试验状态的收集器的稳定性有所顾虑,或者应用必须运行在Windos操作系统下,那ZGC就无缘了,试试Shenandoah吧。
- 如果你接手的是遗留系统,软硬件基础设施和JDK版本都比较落后,那就根据内存规模衡量一下,对于大概4GB到6GB以下的堆内存,CMS一般能处理的比较好,而对于更大的堆内存,可重点考察一下G1。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。