针对时间而不是分配率进行调度的原因是：在应用程序执行期间，分配率通常都是不均匀的。完成 GC 工作对分配来说是个负担，GC 暂停很可能是不均匀分配的，这样降低了 GC 行为的确定性。通过使用基于时间的调度，Metronome GC 可以实现一致的、确定性的、有限的暂停时间。并且，由于不需要任何语言扩展或对现有代码做修改，常规 Java 应用程序可以透明地使用 Metronome 并从其确定性特征受益。

Metronome 将时间分为一些离散的量子（quanta），大约 500 微秒但是不会超过 1 毫秒，专门用于 GC 或者应用程序。尽管量子非常的短，如果将一些量子用于执行 GC 任务，那么应用程序仍然会感觉到较长的暂停时间，这会影响到 RT 时限。为了更好地支持 RT 时限，Metronome 将量子分配给 GC，而应用程序应该具有最小的时间百分比。这个百分比被称为 utilization，是用户提供的参数。在任何时间间隔内，用于应用程序量子数不得少于指定的 utilization。默认情况下，utilization 值为 70%：在任何 10 毫秒的时限内，至少有 7 毫秒专门用于应用程序。

用户可以在启动应用程序时设置 utilization 的值。图 3 展示了较长时间期限内应用程序 utilization 的示例。注意垃圾收集器活动状态下对应于时间量子的周期性下降。图 3 所示的整个时间期限内，应用程序 utilization 保持在指定的 70%（0.7）或以上。

图 3. 示例 utilization 图表

实时Java，第1部分: 使用Java语言编写实时系统(5)

图 4 演示了使用 Metronome 技术后的 GC 暂停时间的确定性。只有一小部分暂停超过了 500 微秒。

图 4. GC 暂停时间直方图

为保持较短的单次 GC 暂停时间，Metronome 在堆内使用了写屏障（write barrier）以及相关的亚结构（metastructure）来跟踪活动的和可能死亡了的对象。跟踪活动的对象需要一些 GC 量子来确定应该保持哪些对象为活动的，哪些对象应该回收。由于这种跟踪工作与程序的执行是交叉进行的，应用程序通过执行加载或存储将某些对象 “隐藏”，因此 GC 可能会丢失这些对象的跟踪。

隐藏活动的对象并不一定是恶意应用程序代码的结果。这种现象很常见，因为应用程序没有意识到垃圾收集器的行为。为了确保收集器不会丢失对象，GC 和 VM 互相协作，跟踪对象之间的链接，因为它们是通过存储应用程序执行的操作而被创建和销毁的。在应用程序执行存储操作之前执行写障碍将完成这种跟踪。写障碍的目的就是：如果存储将导致隐藏活动的对象，那么就记录对象链接状态的变化。这些写障碍表示平衡确定性行为的性能和内存占用开销。

大型对象的分配对很多 GC 策略都是件棘手的事情。在很多情况下，堆中存在太多碎片以至于无法存放一个大的对象，比如说数组。因此，必然会引发长时间的暂停来整理碎片或进行压缩，堆将很多小块的自由内存区域整合为一块大的自由内存区域，从而满足大型分配请求。Metronome 将一种新的两级对象模型用于 arraylets 数组。arraylets 将大数组分为一些小的数组，以使没有进行碎片整理的堆更容易满足大数组分配请求。arraylets 对象的第一级称为 spine，包含指针列表，指向数组的更小部分，称为 leaves。每一个 leaf 大小相同，这样简化了查找数组中特定元素的计算，并使收集器更容易查找到合适的自由空间来分配每个 leaf。将数组分成更小的不连接的部分，这样使数组可以分配在很多小的自由区域里（堆中经常会有这样

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!