由Sun的Brian Goetz和Robert Eckstein合作撰写的有关Java和实时系统的文章最近登载在Sun开发者网络上，该系列文章由两部分组成。
该系列第一部分介绍了实时程序设计的概念，及其与Java的关系，并描述了应用标准Java运行时系统创建实时应用的障碍：
操作系统问题：调度延迟、时钟精度较低。 线程优先级问题：不可靠的线程优先级保证和优先级倒置。 类加载延迟。 垃圾回收延迟。 应用程序代码不符合实时要求。 - 系统中存在其它优先级较高的活动。
作者随后介绍了RTSJ——Java实时规范(Real-Time Specification for Java)。RTSJ与当初的
JSR 1有所不同，从2002年最初的可用版本问世至今，已经过一系列维护版本。文章描述了实时规范对线程做出的改变：
在一个真正的实时环境中，线程优先级是极其重要的，没有一个系统可以保证，所有的任务都能够准时完成。然而，一个实时系统能够确保的是，当有些任务即将超过最终时限时，可以先牺牲低优先级的任务来保障它的执行。
RTSJ定义了至少28种优先权级别，并要求严格执行此规定。然而，正如本篇文章前面所说，RTSJ的实现依赖于支持多种优先权的实时操作系统，和高优先级线程抢占低优先级线程的能力。
Goetz和Eckstein接着提到Java实时系统规范的核心概念——实时线程：
此外，RTSJ可允许非实时和实时活动同时存在于一个Java应用中，对一个活动的时序保证程度依赖于活动所属线程类型： java.lang.Thread或javax.realtime.RealtimeThread线程类型。
- 标准java.lang.Thread(JLT)线程用来支持非实时的活动。JLT线程可以应用Thread类定义的10种优先权级别，但是它们不适用于实时活动，因为不能够提供时序执行保证。
- RTSJ还定义了javax.realtime.RealtimeThread (RTT)线程类型。RTTs可以利用RTSJ提供的强大的线程优先权支持，它的调度遵循运行直至阻塞(run-to-block)原则，而非按时间片运行原则。这就意味着，当有另外具有较高优先权的RTT出现时，调度程序会抢占该RTT。
第一部分讲到的最后一个概念是，支持内存管理所做的各种扩展。由于与垃圾回收及对象分配相关的延迟的存在，三个内存区域被划分出来：
- 标准堆(Standard heap)——与标准Java中的内存管理类似。
- 永久内存(Immortal memory)——必须由软件显式释放的内存。
- 作用域内存(Scoped memory)——具有不连续生命周期的内存，有固定大小。
引入RealtimeThread的扩展类——NoHeapRealtimeThread，以实时友好的方式辅助管理这些独特的内存区域：
RTSJ提供一个RTT的子类，称为NoHeapRealtimeThread (NHRT)。该子类得实例可以避免由垃圾回收引起的不稳定情况。这个NHRT类是为硬实时(hard-real-time)活动所准备的。
为最大化可预测性，NHRTs不能访问垃圾回收堆，也不能操纵堆变量。否则，线程会遭遇GC暂停，这将导致任务错过运行时限。与此相反的是，NHRT可以更具预测性的方式使用作用域内存和永久内存特性分配内存。
然而，即使软件正在使用特定的内存区域，它的资源使用依然很容易受到内存其它非关键部分的GC的影响。由于这个原因，该系列文章的
第二部分集中于和垃圾回收相关的问题，阐述了可用于实时Java系统的不同GC方法，然后介绍了Sun的商业实时Java系统：
Java RTS。在第二部分中描述了四种垃圾回收算法：
- 基于工作的GC(Work-Based GC)——回收由对象分配触发。
- 基于时间的GC(Time-Based GC)——回收通过标准的时间箱划定界限。
- Henriksson's GC——在关键和非关键线程之间有所区别的基于工作的GC(Work-based GC)。
- Java RTS Real-Time GC (RTGC)——可以用在Java RTS中，更加灵活/细粒度的Henriksson's GC的扩展。
如今可用的实时系统有很多，
Sun Java RTS和
IBM Websphere RT都是遵从RTSJ的实时系统平台。可以选择的还有
Oracle Weblogic Real Time，它是建立于标准Java的工具集，对RTSJ系统还不具备所有可靠性保证，但在固定时间边界内还是可以提供一个更具预测性的系统。
作者 R.J. Lorimer 译者 张凯峰 原文出处：
http://www.infoq.com/cn/news/2008/08/realtime_java 您可能对 [Java] 的这些文章也感兴趣：