使用实时Java进行开发，第2部分 改善服务质量 - 编程入门网

使用实时Java进行开发，第2部分 改善服务质量

Java 应用程序中的易变性（通常是由暂停或延迟导致的，其发生时间无法预测）可能在整个软件栈中发生。延迟可由以下因素引起：

硬件（缓存期间）

固件（处理 CPU 温度数据等系统管理中断的过程中）

操作系统（响应一个中断或执行定期调度的后台活动）

在相同系统上运行的其他程序

JVM（垃圾收集、即时编译和类加载）

Java 应用程序本身

很难在较高级别上补偿较低级别上的延迟，所以，如果您试图仅在应用程序级别解决易变性，您可能只是转移了 JVM 或 OS 延迟，并没有解决实际问题。幸运的是，较低级别的延迟可能比较高级别上的延迟相对短一些，所以只有在降低易变性的需求非常强烈时，才需要深入到比 JVM 或 OS 更低的级别上。如果需求不是那么强烈，您可以将精力集中在 JVM 级别上或应用程序中。

实时 Java 提供了必要的工具来堵截 JVM 和应用程序中的易变性源头，交付用户要求的服务质量。本文详细介绍 JVM 和应用程序级别上的易变性源头，介绍可用于减轻其影响的工具和技术。然后介绍一个简单的 Java 服务器应用程序来演示其中一些概念。

解决易变性源头

JVM 中的易变性主要源自于 Java 语言的动态特性：

内存绝不会被应用程序显式释放，而是被垃圾收集器定期回收。

类在被应用程序首次使用时才进行解析。

本机代码在应用程序运行时由即时（JIT）编译器编译（而且可以重新编译），基于经常调用的类和方法。

在 Java 应用程序级别上，线程管理是与易变性相关的关键区域。

垃圾收集暂停

当垃圾收集器回收程序不再使用的内存时，它可以停止任何应用程序线程。（这种类型的收集器称为 Stop-the-world 或 STW 收集器）。或者它可以与应用程序同时执行自己的一些工作。无论是哪种情况，垃圾收集器需要的资源都不能供应用程序使用，所以，众所周知，垃圾收集（GC）是 Java 应用程序性能中的暂停和易变性的源头。尽管许多 GC 模型都具有自己的优缺点，但当应用程序的目标是缩短 GC 暂停时，两个主要的选择将是分代（generational）和实时 收集器。

分代收集器将堆组织为至少两个部分，这两个部分通常称为新 和旧（有时称为保留）空间。新对象始终在新空间中分配。当新空间耗尽空闲内存时，将仅在该空间中进行垃圾收集。使用相对较小的新空间可能时 GC 周期更短。在多次新空间垃圾收集过程中存留下来的对象会被提升到旧空间中。旧空间垃圾收集发生的频率通常比新空间垃圾收集低得多，但是由于旧空间比新空间大得多，所以这些 GC 周期可能长得多。分代垃圾收集器提供了相对较短的平均 GC 暂停时间，但是旧空间收集的开销可能导致这些暂停时间的标准偏差非常大。对于活动数据集不会经常更改，但会产生大量垃圾的应用程序而言，分代收集器是最有效的。在这种场景中，旧空间收集极少发生，因此 GC 暂停时间取决于短的新空间收集时间。

与分代收集器相反，实时垃圾收集器会控制自身的行为，以显著缩短 GC 周期的长度（通过在应用程序空闲时执行周期）或减轻这些周期对应用程序性能的影响（通过基于与应用程序之间的一种 “契约”，以更小的增量执行工作）。使用这类收集器，您可以预测完成特定任务的最遭情形。例如，IBM® WebSphere® Real-Time JVM 中的垃圾收集器将 GC 周期划分为较小的工作片段（称为 GC 限额），这些限额可以增量方式完成。对限额的调度对应用程序性能的影响极小，其延迟可低至几百微秒，通常小于 1 毫秒。为了达到这种延迟级别，垃圾收集器必须能够计划自己的工作，方法是引入应用程序利用契约 的概念。此契约管理允许 GC 中断应用程序执行工作的频率。例如，默认的利用契约为 70%，也就是在实时操作系

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!