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 版本中，输出会发生变化。