使用实时Java进行开发,第2部分 改善服务质量 - 编程入门网
看看如何消除 Java 加载、JIT 本机代码编译、GC 和线程导致的延迟,从而消除这种易变性。
我们首先通过 -verbose:class 完整地运行应用程序,收集应用程序加载的类列表。我们将输出存储到一个文件,然后修改它,使该文件的每行上都具有一个格式正确的名称。我们将一个 preload() 方法包含到 Server 类中,以加载每个类,JIT 编译这些类的所有方法,然后禁用 JIT 编译器,如清单 9 所示: 清单 9. 预加载服务器的类和方法
在这个简单的服务器中,类加载并不是一个重大问题,因为 TaskHandler.run() 方法非常简单:一旦加载该类,就不会在以后执行 Server 时发生太多类加载操作,这可以通过运行 -verbose:class 来验证。主要的优点源自于在运行任何测试 TaskHandler 操作之前运行方法。尽管我们可以使用预备循环,但此方法是特定于 JVM 的,因为 JIT 编译器用于选择要编译方法的启发机制在各个 JVM 实现之间有所不同。使用 Compiler.compile() 服务器会提供更加可控的编译行为,但正如本文前面提到的,使用此方法应该会使吞吐量下降。使用这些选项运行应用程序的结果如下:
使用实时Java进行开发,第2部分 改善服务质量(8)时间:2011-01-27 IBM Mark Stoodley注意,尽管最长的延迟没有多大变化,但直方图比最初小多了。JTI 编译器明确引入了许多较短的延迟,所以较早执行编译,然后禁用 JIT 编译器显然是一大进步。另一个有趣的结果是,普通操作时间变得更长了(从 9 - 10 毫秒增加到了 11 - 12 毫秒)。操作变慢了,原因在于在调用方法之前强制执行 JIT 编译所生成的代码质量比完整编译的代码质量要低很多。这个结果并不奇怪,因为 JIT 编译器的一个最大优势是利用应用程序的动态特征来使其更高效地运行。 我们将在本文余下部分继续使用此类预加载和方法预编译代码。 由于我们的 GCStressThread 生成了一个不断变化的活动数据集,所以使用分代 GC 策略并不能提供太多暂停时间优势。相反,我们尝试使用 IBM WebSphere Real Time for Real Time Linux V2.0 SR1 产品中的实时垃圾收集器。最初的结果令人失望,甚至在添加了 -Xgcthreads8 选项之后也是如此,该选项允许收集器使用 8 个 GC 线程,而不是默认的 1 个线程。(使用一个 GC 线程,收集器无法可靠地跟上此应用程序的分配速度)。
|
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务,公司网站:http://www.lingzhong.cn 为了给广大客户了解更多的技术信息,本技术文章收集来源于网络,凌众科技尊重文章作者的版权,如果有涉及你的版权有必要删除你的文章,请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢! |