Java进入实时领域

在2007年5月举行的JavaOne大会上，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规范相一致的。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，第1部分：使用Java语言编写实时系统

• 实时Java，第2部分：比较编译技术

• 漫漫征途 Java EE 6离我们还有多远