【IT168技术文档】

　　关于实时
　　在开始讨论WebLogic Real Time之前，我们必须首先思考一下该产品中的两个单词的意思：“real”和“time”。关于“实时”（real time），存在着许多种定义，许多文章也描述了不同的概念——第一个Java Specification Request (JSR 1)甚至就是专门针对此主题的。然而，实时的定义并不是一成不变的。没有人可以给出一个确定的定义，说明到底什么是实时以及如何确定它，但是似乎大家都认为，如果看到实时，自己就会知道了。为了更好地说明实时的概念，我们将引入几个常见的定义。根据Douglas Jenson对实时的讨论，存在两种类型的实时：“软”实时和“硬”实时。

　　硬实时：定义了一个系统，其中所有可调度和不可调度的实体的执行都要遵守规定的完成时间约束。其它时间约束（也称为“上界”）可能也必须满足。实体的行为和运行时间是可预测的、确定的。
　　软实时：表示不属于硬实时的所有其它实时情况。所有时间约束都是软性的。基本上，这就意味着所有可调度和不可调度的实体都可能被优化以便以非常好的状态执行，但是执行时间不可预测。

　　在一个硬实时系统中，必须遵守时间期限，否则计算结果就会无效。例如，考虑汽车中的嵌入式系统。如果您要加速，而电子加速器的响应延迟了，那么就会得到无法预料的行为。而如果刹车系统延迟了，就会导致可怕的后果。软实时系统中的定时约束没这么严格，甚至在超出了时间约束之后，计算结果也可能仍然有用。

　　音频流就是一个软实时系统的例子。如果一个数据包延迟或丢失了，音频的质量会降低，但是流可能依然有效。

　　为了保证满足实时系统的定时需求，底层计算系统的行为和计时必须是可预测的。一个可预测的定时系统，其所有操作所需的时间必须是有限制的。这意味着所有操作在最坏情况下的定时是已知的。实时系统通常都是用多个异步线程实现的。这是因为他们通常需要响应事件以及控制异步设备。

　　另一个常见需求是优先级。因为特定事件的紧急程度以及需要处理的事件的数目都不同，因此必须支持优先级的概念，以便确保时间关键型的任务不会由于非时间关键型的任务而被延迟。让非关键型的任务以与时间关键型的任务相同的优先级运行就有可能导致此问题。由于这种优先级倒置，任务需要具有互相通信的能力。因此，实时系统必须提供同步和通信功能。简而言之，实时系统必须以最小的开销实现可预测性。

　　实时计算还有许多其它的理论，比如调度理论，在“参考资料”部分包括有相关的链接。您可能已经猜到了，我们将讨论的WLRT是软实时系统。这种对“硬性”和“软性”的讨论是有价值的，可以帮助理解期望从产品中获得的特性以及产品所针对的用例。下面是一些在讨论WebLogic Real Time相关概念时所使用的其它术语和定义：

　　实时是一种计算机响应等级，在这种等级下，用户可感知到足够快，或者计算机能够跟得上某个外部流程。
　　延迟是指系统花在从一个指定点传输数据到另一个指定点的时间。
　　抖动是延迟偏差。一个具有确定性的应用程序抖动应该较低。该术语基本上描述了一种度量确定性的方法。
　　吞吐量是计算机在给定的时间帧中所能处理的工作量。
　　确定性垃圾收集是一个执行概念，用于描述快速的、可预测暂停时间的内存堆垃圾收集。垃圾收集是从堆中清理废弃对象以便收回空间用于新对象的过程。

　　WebLogic Real Time

　　WebLogic Real Time server (WLRT)为事件驱动的应用提供了一个低延迟的轻量级基础架构。它旨在用于竞争性较高的环境中，在这种环境中，性能非常关键，每一毫秒都很重要。例如，特定的行业（比如电信或保险业）要求事务在给定的时间帧中以极低的延迟执行。然而，如果尝试用标准的Java来实现，则很可能会因为由垃圾收集过程所产生的无法预测的暂停时间而失败。这就是WLRT的用武之地了。它结合了JRockit JVM，后者引入了一种确定性垃圾收集机制，提供了一个用于执行这些关键型应用的J2EE运行时。确定性垃圾收集确保程序执行期间的暂停时间非常短，而且挂起的请求会在定义的时间帧中得到处理——从而允许购建高性能和确定性的应用程序。

　　架构

　　要了解该新产品，我们需要详细看一下整个产品组合。WLRT是一个依赖于JRockit JVM中的新特性的WebLogic Server，它使用集成的BEA Spring Framework支持轻量级编程：

　　BEA WebLogic Server 9.1是实时应用程序的J2EE服务提供程序。
　　BEA JRockit 5.0 R26为确定性垃圾收集提供了基础。
　　BEA Spring Framework 1.2.6是轻量级的编程模型。

　　下面我们将逐一详细介绍这3个组件。

　　BEA WebLogic Server 9.1 SP4

　　WebLogic Server 9.1是BEA有着良好口碑的著名企业Java应用服务器的最新版本。除了完全实现了J2EE 1.4规范外，它还提供了一组标准的API，用于创建可以访问各种服务（比如数据库、消息传递服务以及其它与外部企业系统的连接）的分布式Java应用程序。借助于WebLogic Server，企业可以在一个健壮、安全、高度可用且可伸缩的环境中部署任务关键型的应用程序。所有这些都可以使用一组集群化、管理和监控特性在给定的基础架构中实现。作为WLRT的一部分，WebLogic Server是事件驱动的低延迟应用程序的服务提供程序。

　　JRockit

　　垃圾收集对Java性能有着很大的影响。在full垃圾收集期间，Java进程会完全停止。当垃圾收集完成后，进程才会继续。从堆中清理废弃对象以及为新对象释放空间的过程需要进行高度优化，以便确保有效的内存管理。

　　JRockit可以使用一种动态的“确定性”垃圾收集优先级(-Xgcprio:deterministic)。该策略被优化以确保暂停时间非常短，并限制定义良好的时间帧（也称为“滑动窗口”（sliding window））中的这些暂停的总次数。这对特定的应用程序来说很有用，尤其是对事务延迟有严格要求的应用程序。然而，即使较短的确定性暂停时间也不一定能保证较高的应用程序吞吐量。确定性垃圾收集的目标是降低在执行垃圾收集时运行的应用程序的延迟。与常规垃圾收集相比，确定性垃圾收集产生的暂停时间会短得多。通过在JRockit 5.0 R26中引入确定性垃圾收集优先级，可以保证以下的事务延迟：

　　在99%的情况下，在任何50ms的滑动窗口中，每周由垃圾收集引起的总暂停时间不超过30m。
　　在任何130ms的滑动窗口中，由垃圾收集引起的总暂停时间不超过100ms。

　　对于具有1 GB堆以及在收集时平均30%或更少的活动数据的应用程序，这些目标很容易实现。WLRT文档声明，这已经在以下硬件上得到了验证：

　　2 x Intel Xeon 3.6 GHz，2 MB level 2缓存，4 GB RAM
　　4 x Intel Xeon 2.0 GHz，0.5 MB level 2缓存，8 GB RAM

　　在具有不同堆大小且/或者有更多活动数据的更慢的硬件上运行可能会破坏这一确定性行为。在这种情况下，可能需要使用-XpauseTarget选项增加暂停时间目标。确定性垃圾收集只作为WLRT的一部分可用。如果没有相应的许可文件而试图启用该功能，则会在服务器控制台上出现警告。