由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系统还不具备所有可靠性保证,但在固定时间边界内还是可以提供一个更具预测性的系统。