使用实时 Java 进行开发，第 2 部分: 改善服务质量

核心提示： 当垃圾收集器回收程序不再使用的内存时，它可以停止任何应用程序线程，使用实时 Java 进行开发，第 2 部分: 改善服务质量(2)，（这种类型的收集器称为 Stop-the-world 或 STW 收集器），或者它可以与应用程序同时执行自己的一些工作，（参见 “实时 Java，第 4

当垃圾收集器回收程序不再使用的内存时，它可以停止任何应用程序线程。（这种类型的收集器称为 Stop-the-world 或 STW 收集器）。或者它可以与应用程序同时执行自己的一些工作。无论是哪种情况，垃圾收集器需要的资源都不能供应用程序使用，所以，众所周知，垃圾收集（GC）是 Java 应用程序性能中的暂停和易变性的源头。尽管许多 GC 模型都具有自己的优缺点，但当应用程序的目标是缩短 GC 暂停时，两个主要的选择将是分代（generational）和实时 收集器。

分代收集器将堆组织为至少两个部分，这两个部分通常称为新 和旧（有时称为保留）空间。新对象始终在新空间中分配。当新空间耗尽空闲内存时，将仅在该空间中进行垃圾收集。使用相对较小的新空间可能时 GC 周期更短。在多次新空间垃圾收集过程中存留下来的对象会被提升到旧空间中。旧空间垃圾收集发生的频率通常比新空间垃圾收集低得多，但是由于旧空间比新空间大得多，所以这些 GC 周期可能长得多。分代垃圾收集器提供了相对较短的平均 GC 暂停时间，但是旧空间收集的开销可能导致这些暂停时间的标准偏差非常大。对于活动数据集不会经常更改，但会产生大量垃圾的应用程序而言，分代收集器是最有效的。在这种场景中，旧空间收集极少发生，因此 GC 暂停时间取决于短的新空间收集时间。

与分代收集器相反，实时垃圾收集器会控制自身的行为，以显著缩短 GC 周期的长度（通过在应用程序空闲时执行周期）或减轻这些周期对应用程序性能的影响（通过基于与应用程序之间的一种 “契约”，以更小的增量执行工作）。使用这类收集器，您可以预测完成特定任务的最遭情形。例如，IBM® WebSphere® Real-Time JVM 中的垃圾收集器将 GC 周期划分为较小的工作片段（称为 GC 限额），这些限额可以增量方式完成。对限额的调度对应用程序性能的影响极小，其延迟可低至几百微秒，通常小于 1 毫秒。为了达到这种延迟级别，垃圾收集器必须能够计划自己的工作，方法是引入应用程序利用契约 的概念。此契约管理允许 GC 中断应用程序执行工作的频率。例如，默认的利用契约为 70%，也就是在实时操作系统上运行时，仅允许 GC 使用每 10 毫秒中的至多 3 毫秒，典型的暂停时间大约为 500 微秒。（参见 “实时 Java，第 4 部分: 实时垃圾收集”，获取对 IBM WebSphere Real Time 垃圾收集器操作的详细介绍）。