Java 进入实时领域

在 Java One 上 Sun 最终宣布了 JSR-1（2006 年 7 月最终定稿的 Java 实时规范）第一个实现的发布。根据 JSR 的定义，实时规范是用来支持“在线程调度，同步额外开支（Synchronization Overhead），锁队列顺序，类的初始化，最大中断响应反应时间以及垃圾回收特性等各个方面需要很强的确定性保证和控制能力的”系统。

Sun 的这个实现，又被称为 Sun Java 实时系统（Real-Time System，RTS）2.0 ，将通过常规的 OEM 渠道提供给开发人员。

营销卖点

RTS 2.0 基于 Java 5 并遵循 JSR1 规范，提供了一个健壮的实时时序调度系统（Scheduling System）。这个系统的核心（Centerpiece）是一个实时垃圾回收器，这是一个高度可配置且非常具有可预测性的垃圾回收器。（它不会在所有的硬件平台上都很有效率，因为有些平台没有对真正的实时系统提供必要的硬件支持，但是 RTS 依然能提供较好的控制性和可预测性）。对 RTS 的支持已集成到 NetBeans 了。

RTS 与 WebLogic 实时系统的比较：我也一样吗？

如 Bill Roth 昨天在他的 Blog 里间接提到的那样，两年前 BEA 发布了一个 Java 实时系统，它设计用来减少垃圾回收对 Java 应用系统性能的影响，并增加这些应用系统的可预测性。其目的是平滑性能，减少由于长时间的垃圾回收带来的性能干扰。Sun 在实时 Java 方面的资深工程师 Greg Bollella 评价说这对实时垃圾回收来说只是一个较少暂停（Low Pause）的方法。所以为什么不把更多的注意力投向 RTS 2.0 呢？

RTS 2.0 强调的是系统的可预测性，这是与 JSR1 规范相一致的。正如以前在InfoQ 上报导的，WebLogic 的实时提供了小于30 毫秒的反应时间，这对标准的垃圾回收来说是一个引人注目的改进。虽然Sun 对“实时”的解释是这样的一个实现中要保证来自垃圾回收的干扰小于200 毫秒，开发人员通过一些额外的工作能控制更多的可预见性工作的执行，从而摆脱垃圾回收带来的不良影响。

开发人员的看法

实时垃圾回收器在它自己的一个单独线程中运行，它有一个赋给它的优先级。当一个开发人员创建了一个java.lang.RealtimeThread 并赋给它一个优先级，这个优先级可以高于也可以低于垃圾回收器的优先级。如果优先级高于垃圾回收器，此线程将只在垃圾回收过程中特定的临界区域（Critical Sections）等待垃圾回收器。根据Greg 的分析，这些临界区域的典型执行时间不会超过120 毫秒。

对那些需要更多控制权的系统来说，还有更复杂的java.lang.NoHeapRuntimeThread（NHRT）可以用。一个NHRT 在它自己私有的堆上进行操作，在垃圾回收器之外，因此在通常条件下它不需要等待垃圾回收器。NHRT 唯一的延迟来自Solaris 10 的分发系统（Dispatching System），一般会引起10 毫秒内的延迟。

好的实时编程方法还在设计中（The key to good real-time programming is still in design）。RealtimeThread 严重依赖于用于调整实时垃圾回收器的命令行参数，不适当的调节参数会导致线程等待垃圾回收器释放内存。NHRT 的复杂性非常显著：因为Java 开发人员必须学会管理他们的私有堆（NHRT 和正常堆中的对象之间的通信也很复杂）。

下一步如何？

Greg Bollella 还提供了他未来实时 Java 的深入见解。RTS 2.1 可能会包含一些工具以及一些有用的脚本和指南。这些工具用于帮助开发人员调整所有重要的用于管理实时垃圾收集的命令行参数。可能还会添加对垃圾收集的“人体工程学（Ergonomic）”调优的支持。RTS 2.0 还没有支持 JSR 282 中的扩展特性，也没有考虑 JSR 302 中关于重大安全要求的支持，后者能为系统的提升提供充足的机会。

查看英文原文： Java Goes Real Time