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/amods参数将新Integer放在默认的参数前面。
verbose
对于虚拟的或任何类型的Java应用程序，-verbose是一个很有用的一级诊断使用程序。
该标志有三个子标志：gc、class和jni。
开发人员尝试寻找是否 JVM 垃圾收集器发生故障或者导致性能低下，通常首先要做的就是 执行 gc。不幸的是，解释 gc 输出很麻烦 — 足够写一本书。更糟糕的是，在命令行中打印 的输出在不同的Java或JVM 中会发生改变，这使得正确解释变得更难。
一般来说，如果垃圾收集器是一个分代收集器（多数「企业级」VMs都是）。某种虚拟标志
将会出现，来指出一个全部清扫GC通路；在Sun JVM中，标志在GC输出行的开始以
[FullGC...]形式出现。
想要诊断ClassLoader或不匹配的类冲突，class可以帮上大忙。它不仅报告类何时加载， 还报告类从何处加载，包括到JAR的路径（如果来自JAR）。
jni很少使用，除了使用JNI或本地库时。打开时，它将报告各种JNI事件，比如，本地库 何时加载，方法何时弹回；再一次强调，在不同JVM版本中，输出会发生变化。
Command-line-X
我列出了JVM中提供的我喜欢的命令行选项，但是还有一些更多的需要您自己发现，运行
命令行参数-X，列出JVM提供的所有非标准（但大部分都是安全的）参数—例如：
-
-Xint，在解释模式下运行JVM（对于测试JIT编译器实际上是否对您的代码起作用或者验证是否JIT编译器中有一个bug，这都很有用）。 -
-Xloggc:，和-verbose:gc做同样的事，但是记录一个文件而不输出到命令行窗口。
JVM命令行选项时常发生变化，因此，定期查看是一个好主意。