共计 749 个字符，预计需要花费 2 分钟才能阅读完成。
垃圾收集器选型因素
- 应用程序的次要关注点是什么？如果是数据分析、科学计算类的工作，指标是尽快算出后果，那吞吐量就是次要关注点；如果是 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。
正文完
