关于JVM号令行标志您不知道的5件事:调优JVM性能和Java运行时[Java编程]

JVM 是大都开辟人员视为理所当然的 Java 功效和性能背后的重负荷机械.但是,我们很少有人能理解 JVM 是若何举行工作的 — 像任务分配和垃圾汇集、转动线程、翻开和关闭文件、中止和/或 JIT 编译 Java 字节码,等等.

不熟习 JVM 将不但会影呼利用程序性能,并且当 JVM 出问题时,尝试修复也会很艰难.

本期 5 件事 系列 将介绍一些号令行标志,您可以利用它们来诊断和调优您的 Java 虚拟机性能.

1. DisableExplicitGC

我已记不清有多少次用户要求我就利用程序性能问题供应咨询了,其实只要跨代码快速运行 grep,就会发现清单 1 所示的问题 — 原始 java 性能反情势:

清单 1. System.gc();

//　We　just　released　a　bunch　of　objects,　so　tell　the　stupid
//　garbage　collector　to　collect　them　already!
System.gc();

显式垃圾汇集是一个非常糟糕的主张 — 就像将您和一个猖獗的斗牛犬锁在一个电话亭里.固然调用的语法是依靠实现的,但假如您的 JVM 正在运行一个分代的垃圾回收器（大大都是）System.gc(); 逼迫 VM 履行一个堆的 “全部打扫”,固然有的没有必要.全部打扫比一个通例 GC 操作要高贵好几个数目级,这只是个简单数学问题.

您可以不把我的话放在心上 — Sun 的工程师为这个特别的人工错误供应一个 JVM 标志; -XX:+DisableExplicitGC 标志自动将 System.gc() 调用转换成一个空操作,为您供应运行代码的机会,您自己看看 System.gc() 关于整个 JVM 履行有害还是有利.

2. HeapDumpOnOutOfMemoryError

您有没有阅历过这样的情形:JVM 不能利用,不断抛出 OutOfMemoryError,而您又不能为自己成立调试器来捕捉它或查看呈现了什么问题?像这类偶发和/或不肯定的问题,普通使开辟人员发狂.

买者自负

并非任何 VM 都支持全部号令行标志,Sun/Oracle 的 VM 除外.查明一个标志能否被支持的最好办法是试用它,看它能否正常工作.假使这些标志在技术上是不支持的,那么,利用它们您要承当全部责任.假如这些标志中的任何一个使您的代码、您的数据、您的服务器或您的一切消逝得无影无踪,我、Sun/Oracle 和 IBM® 都将不负责任.为以防万一,倡议先在虚拟（非常生产）环境中实行.

在这个时刻您想要的是,在 JVM 灭亡之际捕捉堆的一个快照 — 恰好 -XX:+HeapDumpOnOutOfMemoryError 号令可以完成这一操作.

运行该号令告诉 JVM 拍摄一个 “堆转储快照”,并将其保存在一个文件中以便处理,普通利用 jhat 实用工具（我在 上一篇文章 中介绍过）.您可以利用呼应的 -XX:HeapDumpPath 标志指定到保存文件的实际途径.（不管文件保存在哪,务必确保文件系统和/或 Java 流程必必要有权限配置,可以在此中写入.）

3. bootclasspath

按期将一个类放入类途径是很有帮忙的,这类途径与库存 JRE 附带的类途径大概以某种方法扩大的 JRE 类途径略有差别.（新 Java Crypto API 供应商就是一个例子）.假如您想要扩大 JRE ,那么您定制的实现必须可以利用指导程序 ClassLoader,该指导程序可以加载 rt.jar 中的 java.lang.Object 及其全部相关文件.

固然您可以 不法翻开 rt.jar 并将您的定制实现或新数据包移入此中,但从技术上您就违反了您下载 JDK 时赞成的协议了.

相反,利用 JVM 自己的 -Xbootclasspath 选项,以及皮肤 -Xbootclasspath/p 和 -Xbootclasspath/a.

-Xbootclasspath 使您可以设置完好的指导类途径（这普通包含一个对 rt.jar 的引用）,以及一些其他 JDK 附带的（不是 rt.jar 的一部份）JAR 文件.-Xbootclasspath/p 将值前置到现有 bootclasspath 中,并将 -Xbootclasspath/a 附加到此中.

比方,假如您改正了库中的 java.lang.Integer,并将改正放在一个子途径 mods 下,那么 -Xbootclasspath/a mods 参数将新 Integer 放在默许的参数前面.

4. verbose

关于虚拟的或任何范例的 Java 利用程序,-verbose 是一个很有效的一级诊断利用程序.该标志有三个子标志:gc、class 和 jni.

开辟人员尝试探求能否 JVM 垃圾汇集器发生弊端大概招致性能低下,普通首先要做的就是履行 gc.不幸的是,注释 gc 输出很麻烦 — 充足写一本书.更糟糕的是,在号令行中打印的输出在差别的 Java 版本中大概不在差别的 JVM 中会发生改变,这使得精确注释变得更难.

普通来说,假如垃圾汇集器是一个分代汇集器（大都 “企业级” VMs 都是）.某种虚拟标志将会呈现,来指出一个全部打扫 GC 通路;在 Sun JVM 中,标志在 GC 输出行的开始以 “[Full GC ...]” 情势呈现.

想要诊断 ClassLoader 和/或不匹配的类冲突,class 可以帮上大忙.它不但报告类什么时刻加载,还报告类从何处加载,包含到 JAR 的途径（假如来自 JAR）.

jni 很少利用,除了利用 JNI 或本地库时.翻开时,它将报告各种 JNI 事件,比方,本地库什么时刻加载,办法什么时刻弹回;再一次夸大,在差别 JVM 版本中,输出会发生改变.

5. Command-line -X

我列出了 JVM 中供应的我喜好的号令行选项,但是还有一些更多的需求您自己发现,运行号令行参数 -X,列出 JVM 供应的全部非尺度（但大部份都是安全的）参数 — 比方:

-Xint,在注释情势下运行 JVM（关于测试 JIT 编译器实际上能否对您的代码起作用大概考证能否 JIT 编译器中有一个 bug,这都很有效）.

-Xloggc:,和 -verbose:gc 做一样的事,但是记录一个文件而不输出到号令行窗口.

JVM 号令行选项经常发生改变,因此,按期查看是一个好主张.乃至,您深夜盯着监控器和下午 5 点回家和老婆孩子吃顿晚餐,（大概在 Mass Effect 2 中清除您的仇人,按照您的爱好）,它们都是不一样的.

完毕语

在生产环境中,号令行标志不是为永久利用而计划的 — 事实上,除了您终止用来调优 JVM 垃圾汇集器的标志,没有一个非尺度号令行标志是专用于生产利用的.但是,作为工具来刺探在其他方面完好不透明的虚拟机的内部工作,是非常有效的.