Hotspot VM 重要参数选项

        本文包含了重要的Java Hotspot VM(以下简称Hotspot VM)性能选项（以JDK1.7为例）。

        参数类型：

        -：标准参数，一般不会变化。

        -X：稳定参数，一般有对应的-XX参数，一般不会变化。

        -XX：不稳定参数，随JVM版本不同而可能变化。

        其中-XX类型参数是我们优化的重点，其中形如 -XX:<+|->featurename的参数选项，表示开启或关闭某项特性或属性，+代表开启，-代表关闭。

        形如 -XX:featurename=<n>的选项表示需要带有数字，n即为数字。一些控制属性大小值的数字后面还可以紧跟后缀k、m、g，分别表示KB、MB与GB。其他带数字的选项则表示比率或百分比。

 

        以下为标准及稳定的相关参数： 

        1）-client

        指示Hotspot VM把应用作为客户端类程序进行优化。该选项使Hotspot VM将运行时环境设置为client JVM。该选项应该在应用启动时使用，对这类应用程序而言，内存占用是最重要的性能标准，远比高吞吐量重要，即 -client适用于内存有限的设备。

 

        2）-server

        指示Hotspot VM把应用作为服务器类程序进行优化。该选项使Hotspot VM将运行时环境设置为server JVM。该选项适用于高吞吐量比启动时间和内存占用更重要的应用程序，64位运行环境默认且仅使用-server模式，相关配置可以参照$JAVA_HOME/jre/lib/amd64/jvm.cfg。

 

        3）-d64

        加载64位Hotspot VM而不是默认的32位Hotspot VM，用以表明运行环境为64位，当JVM为server模式时，默认为-d64。

        需要比32位Hotspot VM更大的Java堆时可以使用该选项。-Xmx和-Xms小于32GB时，该选项要与-XX:+UseCompressedOops联合使用。Java 6 update 23之后的Hotspot默认开启-XX:++UseCompressedOops。

 

        4）-Xms<n>[g|m|k]

        Java堆的初始及最小尺寸，是新生代和老年代的总和，<n>是尺寸大小，[g|m|k]表示尺寸的单位GB、MB或KB。java堆永远不会小于-Xms设定的值。

        如果-Xms小于-Xmx， java堆的大小会依据应用的需要而扩展或缩减。Java堆的扩展或缩减需要Full GC，所以注重延迟或吞吐量性能的应用程序通常应把-Xms和-Xmx设置成相同的值，以避免可用堆大小变化造成的Full GC开销。

 

        5）-Xmx<n>[g|m|k]

        Java堆的最大大小，是新生代和老年代的总和。<n>是尺寸大小，[g|m|k]表示尺寸的单位是GB、MB或KB。java堆的使用范围永远不会超过-Xmx设定的值。

        如果-Xmx大于-Xms， java堆的大小会依据应用的需要而扩展或缩减Java堆的扩展或缩减需要Full GC，所以注重延迟或吞吐量性能的应用程序通常应把-Xmx和-Xms设置成相同的值。

 

        6）-Xmn<n>[g|m|k]

        同时设置新生代的初始、最小及最大尺寸。<n>是尺寸大小，[g|m|k]表示尺寸的单位是GB、MB或KB。新生代的尺寸设定为这个值。

        如果期望将·-XX:NewSize和-XX:MaxNewSize设置成相同值，这是一个便利的命令行选项。

 

        7）-verbose: GC

        报告每次垃圾收集时的基本GC信息。

        建议使用-XX:+PrintGCdetails而不是-verbose:GC。

 

        8）-XlogGC:<filename>

        将垃圾收集的统计信息打印到文件中，文件名为<filename>。

        推荐的做法是，至少结合-XX:+PrintGCtimestamps(或.-XX:+PrintGCdatestamps)和-XX:+PrintGCdetails将输出捕获到日志文件中。

 

        9）-Xbatch

        关闭JIT编译器的后台编译，等价于-XX:-BackgroundCompilation。通常Hotspot VM以后台任务方式编译代码，用解释器模式运行代码直到后台编译完成。-XX:-BackgroundCompilation和-Xbatch可以关闭后台编译，使得JIT的代码编译以前台任务方式执行，直到完成。

        在写微基准测试时，可以关闭后台编译，这会使JIT编译器的行为更加明确，微基准测试的结果也更可靠。

        -Xbatch关闭后台编译，也可以用-XX:-BackgroundCompilation实现。

 

        10）-Xcheck:jni

        允许用了JNI的Java程序使用另一组调试接口，帮助调试与Java程序本地代码相关的错误或引入的错误。这个选项使用的JNI方法会严格地验证JNI调用的选项，也会执行额外的内部一致性检查。

        如果你想确认JVM执行遇到的问题是否由于JNI方法调用中的问题引起，可以使用该选项。

 

        以下为不稳定的相关参数： 

        1）-XX:++UseCompressedOops

        开启压缩指针特性。OOP (ordinary object pointer)是指普通对象指针，Hotspot VM内部以它来引用Java对象。

        Java引用的长度从32位增加到了64位，这给64位JVM带来了性能损失。

长度的增加使得缓存行中可容纳的OOP变少，CPU高速缓存的效率也因此降低。64位JVM上CPU高速缓存效率的降低常常导致64位JVM的性能比32位JVM降低8%~20%。

        开启-XX:++UseCompressedOops，使得64位JVM不但有更大的堆，而且还有32位JVM的性能。

有些Java应用在64位Hotspot VM上开启压缩指针后，性能甚至比32位Hotspot VM更好。压缩指针之所以能改善性能，是因为它可以将64位指针转换为相对于Java堆基地址的32位偏移。

        如果Java堆超过了32位Hotspot VM自的限制，但又不想辆牲32位VM性能，可以使用该选项。

如果Java堆上限不超过32Gb(-Xmx32g)时，应该使用该选项，不过上限大约为26Gb(-Xmx26g)时的性能最好。

 

        2）-XX:NewSize=<n>[g|m|k]

        新生代的初始和最小尺寸。<n>是尺寸大小，[g|m|k]表示尺寸的单位是GB、MB或KB。新生代大小永远不会小于这个值。

        如果-XX:NewSize小于·-XX:MaxNewSize，新生代的大小会依据应用的需要而自动扩展和缩减。

新生代的扩展和缩减需要Full GC，所以注重延迟或吞吐量性能的应用程序通常把-X:NewSize和-XX:MaxNewSize设置成相同的值。

 

        3）-XX:MaxNewSize=<n>[g|m|k]

        新生代的最大大小。<n>是尺寸大小，[g|m|k]表示尺寸的单位是GB、MB或KB。新生代大小永远不会超过这个值。

        如果-XX:MaxNewSize大于-XX:NewSize，新生代的大小会依据应用的需要而扩展和缩减。

新生代的扩展和缩减需要Full GC，所以注重延迟或吞吐量性能的应用程序通常把-XX:MaxNewSize和-XX:NewSize设置成相同的值。

 

        4）-XX:NewRatio=<n>

        新生代和老年代的大小比例。例如，n为3，则比例为1∶3，即新生代占新生代与老年代大小总和的1/4。如果Java堆扩展或缩减，Hotspot VM将依据此比率调整新生代和老年代的大小。

如果-Xms和-Xmx不同，并且希望新生代和老年代的大小维持特定比率时，这是个便利的命令行选项。

 

        5）-XX: PermSize=<n>[g|m|k]

        永久代的初始和最小尺寸。<n>是尺寸大小，[g|m]k]表示尺寸的单位是GB、MB或KB。永久代永远不会小于这个值。

        如果-XX:PermSize小于·-XX:MaxPermSize，永久代的尺寸会随着应用的需要而扩展或缩减，特别是需要加载类或存储intern String的情况。永久代的扩展或缩减需要Full GC，所以注重延迟或吞吐量性能的应用程序通常应把-XX:PermSize和--XX:MaxPermSize设置成相同的值。

        JDK1.7及以下版本适用。

 

        6）-XX:MaxPermSize=<n>[g|m|k]

        永久代的最大尺寸。<n>是尺寸大小，[g|m]k]表示尺寸的单位是GB、MB或KB。永久代永远不会超过这个值。

        如果·-XX:MaxPermSize大于-XX:PermSize，永久代的尺寸会随着应用的需要而扩展或缩减，特别是在需要加载类或存储intern String时。永久代的扩展或缩减需要Full GC，所以注重延迟或吞吐量性能的应用程序通常应把·-XX:MaxPermSize和-XX:PermSize设置成相同的值。

        JDK1.7及以下版本适用。

 

        7）-XX:MetaspaceSize=<n>[g|m|k]

        元空间的初始和最小尺寸。<n>是尺寸大小，[g|m]k]表示尺寸的单位是GB、MB或KB。元空间永远不会小于这个值。

        用法与-XX: PermSize一致，JDK1.8及以上版本适用。

        注意元空间隶属于“堆”内存。

 

        8）-XX:MaxMetaspaceSize=<n>[g|m|k]

        元空间的最大尺寸。<n>是尺寸大小，[g|m]k]表示尺寸的单位是GB、MB或KB。元空间永远不会超过这个值。

        用法与-XX:MaxPermSize一致，JDK1.8及以上版本适用。

 

        9）-XX: SurvivorRatio=<n>

        单块Survivor区与Eden区的大小比例，<n>是比率。依据·-XX:SurvivorRatio=<n>指定的比率，可用以下等式计算Survivor区的大小:

Survivor Size = -Xmn<n>/(-XX:SurvivorRatio=<n>+2)

        其中-Xmn<n>是新生代的尺寸，而-XX:SurvivorRatio=<n>是比率值。等式中的+2是因为有两块Survivor区，指定的比率越大，Survivor区的尺寸越小。

在使用CMS收集器或Throughput（即Parallel Scavenge）收集器，并且自适应尺寸调整关闭(-XX:-UseAdaptiveSizePolicy)时，如果想显式调整Survivor区从而控制对象的老年化，那就应该使用-XX:SurvivorRatio=<n>。

        在使用Throughput收集器，并且自适应尺寸调整开启时，不要使用-XX:SurvivorRatio=<n>。通过-XX:+UseparallelGC或-XX:+UseparallelOldGC选择的Throughput收集器，默认开启自适应尺寸调整。如果想为Throughput收集器的自适应尺寸调整设定初始Survivor比率，则可使用选项-XX:InitialSurvivorRatio=<n>。

 

        10）-XX:InitialSurvivorRatio=<n>

        Survivor区初始比例应与Throughput收集器配合使用，<n>是比率。它只是初始时的Survivor区比例。这个选项通常是在Throughput（即Parallel Scavenge）收集器开启自适应尺寸调整时使用。自适应调整Survivor区大小使得应用可以正常运行。

        对于给定的-XX:InitialSurvivorRatio=<r>比率，以下等式可以计算Survivor区的初始尺寸:

Initial Survivor Size =-Xmn<n>/(-XX:InitialSurvivorRatio=<n>+2)

        -Xmn<n>是新生代的大小，-XX:InitialSurvivorRatio=<n>是比率。等式中的+2是因为有两块Survivor区。所以初始比率越大，Survivor区的初始尺寸就越小。

        在使用Throughput收集器，并且开启自适应尺寸调整时，如果你想指定Survivor区的初始大小，应该使用·-XX:InitialSurvivorRatio=<n>。

        通过-XX:+UseParallelGC或-XX:+UseparallelOldGC为Throughput收集器默认开启自适应尺寸调整。

在自适应尺寸调整关闭或使用的是CMS垃圾收集器时，如果你想显式调整Survivor区，从而控制整个应用执行过程中的对象老年化，应该使用-XX:SurvivorRatio=<n>。

 

        11）-XX:TargetSurvivorRatio=<percent>

        在Hotspot VM Minor GC之后，Survivor区被占用的最大值。值是Surivor区被占用的百分数，而不是比率，默认为50%。

        eg：-XX:TargetSurvivorRatio=50

        这个选项很少需要调优。Hotspot VM工程团队针对大量各种不同类型应用程序的负载做过测试，发现大多数应用程序在设置Survivor区占用上限为50%时，运行得最好，因为对于许多类型的Java应用来说，这个百分比有助于应对Minor GC中出现的存活对象数突然上升的情况。

        如果应用经过细致的调优，对象分配速率相对稳定，提高Survivor区占用上限也是可以接受的，比如·-XX:TargetSurvivorRatio=80或-XX:TargetSurvivorRatio=90。

        这样做的好处是，有助于提高Survivor区的使用率。但-XX:TargetSurvivorRatio<percent>设置过高的风险在于，当出现对象分配速率突升时，Hotspot VM不能很好地适应对象老化，而这很快就会导致你所不期望看到的对象晋升。对象晋升太快，老年代的占用量就会增加，但因为某些晋升对象的存活期并不长，必定会在将来的并发垃圾收集周期中被回收，所以这更容易导致空间碎片化。应该避免碎片化，因为它使得Hotspot VM离FullGC又近了一步。

 

        12）-XX:+UseSerialGC

        开启单线程、Stop-The-World的新生代和老年代垃圾收集器。它是Hotspot VM中最古老而成熟的垃圾收集器。

        一般来说，只在Java堆比较小（如-Xmx256m或更小)时才使用-XX:+UseSerialGC。堆比较大时，可优先使用Throughput收集器或者CMS垃圾收集器，而不是。-XX:+UseSerialGC。

        注意：新生代是Serial收集器，老年代是SerialOld收集器。

 

        13）-XX:+UseParallelGC

        开启Hotspot VM的多线程、Stop-The-World的Throughput（即Parallel Scavengel）收集器。不过只是新生代使用多线程垃圾收集器，而老年代依旧使用单线程、Stop-The-World垃圾收集器（即SerialOld）。

如果所用的Hotspot VM版本支持-XX:+UseParallelOldGC，可优先使用-XX:+UseParallelOldGC，而不是-XX:+UseParallelGC。

 

        14）-XX:+UseParallelOldGC

        开启Hotspot VM的多线程、Stop-The-World的Throughput收集器。与-XX:+UseParallelGC不同，新生代和老年代用的都是多线程垃圾收集器。

        设定-XX:+UseParallelOldGC时会自动开启-XX:+UseParallelGC。

如果所用的Hotspot VM版本不支持-XX:+UseParallelOldGC，可以迁移到最新的Hotspot VM或者使用-XX:+UseParallelGC。

 

        15）-XX:-UseAdaptiveSizepolicy

        关闭（“-”代表关闭）自适应调整新生代Eden区和Survivor区尺寸的特性。只有Throughput收集器支持自适应尺寸调整。开启或关闭自适应尺寸调整在CMS收集器或Serial收集器时不起作用。

        用-XX:+UseParallelGC和-XX:+UseParallelOldGC设定Throughput收集器时，会自动开启自适应尺寸调整。应该只有在自适应尺寸调整所能提供的性能吞吐量不能满足要求的情况下时，才关闭自适应尺寸调整。

 

        16）-XX:+UseConcMarkSweepGC

        开启Hotspot VM的CMS收集器。它会自动开启-XX:+UseParNewGC，新生代使用多线程垃圾收集器，老年代使用CMS收集器。

        当Throughput收集器无法满足应用的延迟需求时，可使用CMS收集器。使用CMS收集器时，通常需要对新生代大小、Survivor区大小和CMS垃圾收集周期的初始阶段进行细致调优。

 

        17）-XX:+UseParNewGC

        开启多线程、Stop-The-World的新生代垃圾收集器，需要配合以并发为主的老年代垃圾收集器CMS。

设定-XX:+UseConcMarkSweepGC时，会自动开启-XX:+UseparnewGC。

 

        g1相关参数：

        18）-XX:+UseG1GC

        使用 G1 (Garbage First) 垃圾收集器。

 

        19）-XX:MaxGCPauseMillis=n

        设置最大GC停顿时间(GC pause time)指标(target)。这是一个软性指标(soft goal)，JVM 会尽量去达成这个目标。

 

        20）-XX:InitiatingHeapOccupancyPercent=n

        启动并发GC周期时的堆内存占用百分比. G1之类的垃圾收集器用它来触发并发GC周期,基于整个堆的使用率,而不只是某一代内存的使用比. 值为 0 则表示"一直执行GC循环"。默认值为 45。

 

        21）-XX:G1ReservePercent=n

        设置堆内存保留为假天花板的总量,以降低提升失败的可能性。默认值是 10。

 

        22）-XX:G1HeapRegionSize=n

        使用G1时Java堆会被分为大小统一的的区(region)。此参数可以指定每个heap区的大小. 默认值将根据 heap size 算出最优解。最小值为 1Mb, 最大值为 32Mb。

 

        23）-XX:ParallelGCthreads=<n>

        控制多线程垃圾收集器垃圾收集线程的并行数，<n>是运行的线程数从Java6 update23开始，如果Java API Runtime. Availableprocessors()小于等于8，则<n>默认为这个值，否则默认为：

8+(Runtime. Availableprocessors()-8)*5/8

        如果同一个系统上运行了多个应用，建议用-XX:ParallelGCthreads显式设置垃圾收集线程的并行数，该数应该小于Hotspot VM的默认值。运行在一个系统上的垃圾收集线程，总数不应该超过Runtime. Availableprocessors()。

 

        24）-XX:MaxTenuringThreshold=<n>

        老年代最大晋升阈值为<n>，即对象的年龄超过该阀值后将被晋升至老年代。

        Hotspotvm将这个值用作对象的最大年龄，它会将达到这个阈值的对象从新生代提升到老年代。

        使用CMS收集器时，为了使对象老化的算法更有效，可使用-XX:MaxTenuringThreshold微调Survivor区。

 

        25）-XX:CMSInitiatingOccupancyFraction=<percent>

        老年代占用达到该百分比时，就会引发CMS的第一次垃圾收集周期。后续CMS垃圾收集周期的开始点则由Hotspot自动优化计算得到的占用量而决定。

        如果还设定了-XX:+UseCMSInitiatingOccupancyOnly，则每次老年代占用达到该百分比时，就会开始CMS的垃圾收集周期。

        一般来说，建议同时使用-XX:CMSInitiatingOccupancyFraction=<percent>和-XX:+UseCMSInitiatingOccupancyOnly。

 

        26）-XX:+UseCMSInitiatingOccupancyOnly

        表示只有在老年代占用达到-XX:CMSInitiatingOccupancyFraction设定的值时，才会引发CMS的并发垃圾收集周期。

        一般来说，建议同时使用-XX:CMSInitiatingOccupancyFraction=<percent>和-XX:+UseCMSInitiatingOccupancyOnly。

 

        27）-XX:CMSInitiatingPermOccupancyFraction=<percent>

        永久代占用达到该百分比时，就会引发CMS的第一次垃圾收集周期。后续CMS垃圾收集周期的开始点则由Hotspot自动优化计算得到的占用量而决定。

        如果还设定了-XX:+UseCMSInitiatingOccupancyOnly，则每次永久代占用达到设定的百分比时，就会开始CMS的垃圾收集周期。

        一般来说，建议同时使用-XX:CMSInitiatingPermOccupancyFraction=<percent>和-XX:+UseCMSInitiatingOccupancyOnlys

 

        28）-XX:+CMSClassUnloadingEnabled

        开启永久代的并发垃圾收集。

        希望永久代使用CMS进行垃圾收集时，应该开启-XX:+CMSClassUnloadingEnabled。如果使用Java6 update3或更早的版本，还需要开启-XX:+CMSPermgensweepingenabled。

 

        29）-XX:+CMSPermGenSweepingEnabled

        开启永久代的CMS垃圾清除。

        只用在Java6update3或更早的JDK上，并且需要开启-XX:+CMSPermGenSweepingEnabled

-XX:+CMSScavengeBeforeRemark

        指示Hotspot VM在执行CMS重新标记之前，进行Minor GC。

在CMS重新标记之前进行Minor GC，可以缩小扫描老年代到新生代可达对象的查找范围，从而尽量减少重新标记阶段的工作。

        如果想减少完成CMS周期的持续时间，特别是CMS重新标记阶段所花费的时间时，可以使用该选项。

 

        30）-XX:+ScavengeBeforeFullGC

        开启-XX:+UseParallelGC或-XX:+UseparallelOldGC的情况下，指示Hotspot VM在执行Full GC之前，进行Minor GC。这是Hotspot VM的默认设置。

        开启-XX:+ScavengeBeforeFullGC， Hotspot VM在FulGC前会先做一次MinorGC，分担一部分Full GC原本要做的工作，在这两次独立的GC之间，Java线程有机会得以运行，从而缩短最大停顿时间，但也会拉长整体的停顿时间。

 

        31）-XX:+ParallelRefprocEnabled

        开启多线程引用处理。

        这个选项可以缩短Hotspot VM处理Reference对象和finalizer所花费的时间。

 

        32）-XX:+ExplicitGCInvokesConcurrent

        请求Hotspot VM显式地并发执行GC，也就是System.GC()调用，使用CMS而不是Stop-the-World式GC。

        希望避免显式的Stop-The-World式Full GC时，可以使用该选项。

        一般来说，建议使用-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses而不是-XX:+ExplicitGCInvokesConcurrent。

 

        33）-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses

        除了是从永久代卸载类以外，其他与-XX:+ExplicitGCInvokesConcurrent相同。

        一般来说，建议使用-:Xx:+ExplicitGCInvokesConcurrentAndUnloadsClasses而不是-XX:+ExplicitGCInvokesConcurrent。

 

        34）-XX:+disableExplicitGC

        禁止因显式调用System.gc()而引起的Full GC。

        希望禁止应用中调用System.gc()显式请求Full GC时，可以使用该选项。

 

        35）-XX:+CMSIncrementalMode

        开启增量式CMS收集器，即CMS的并发阶段为增量方式，定期暂停并发，将处理器让步给应用线程。

        一般不建议在多核系统或者Java堆比较大时使用-XX:+CMSIncrementalpacing允许增量式CMS收集器在放弃处理器前，依据应用程序的行为，自动控制工作量。只能与.-XX:+CMSIncrementalMode-一起使用。

 

        36）-XX:+PrintGC

        报告每次垃圾收集时的基本GC信息。

        报告的信息与-verbose:GC相同。

        建议使用-XX:+PrintGCdetails而不是-XX:+PrintGC。

 

        37）-XX:+PrintGCdetails

        开启新生代、老年代和永久代垃圾收集统计信息的详细报告。

        推荐使用-XX:+PrintGCdetails而不是-verbose:GC，并用-XlogGC:<filename>将数据捕获到日志文件中。

 

        38）-XX:+PrintGCTimestamps

        在每次垃圾收集时打印时间戳，此时间戳为JVM启动后经过的时间。

        推荐结合使用-XX:+PrintGCTimestamps(或-XX:+PrintGCDateStamps )和-XX:+Print-

GCdetails，可以输出垃圾收集发生时的时间信息。

 

        39）-XX:+PrintGCDateStamps

        在每次垃圾收集时打印本地日期和时间戳，指示当时系统的日期和时间。

        如果想看到垃圾收集所花费时间而不是自JVM启动以来的时间戳，应该用-XX:+PrintGCDateStamps而不是-XX:+PrintGCTimestamps。

        推荐结合使用-XX:+PrintGCTimestamps(或-XX:+PrintGCDateStamps )和-XX:+PrintGCdetails，可以输出垃圾收集发生时的时间信息。

 

        40）-XX:+PrintTenuringDistribution

        报告与对象晋升相关的统计数据，包括Survivor区的占用量以免过早将对象从Survivor提升到老年代，Hotspot VM计算的晋升阈值、当前最大的晋升阈值以及显式当前Survivor中对象年龄的直方图。

        为了控制对象老化而调优新生代Survivor区时，或者用CMS或Serial收集器晋升对象到老年代时，可以用这个选项获取晋升信息和对象年龄信息。

        建议在强调低延迟和需要持续细调对象老化的应用中使用，或者当对象从Survivor区提升到老年代时使用。

 

        41）-XX:+PrintAdaptiveSizePolicy

        报告Throughput收集器GC的详细统计信息，包括Minor GC后的字节数、Minor GC中提升的字节数、Survivor区是否溢出、Minor GC开始时的时间戳、主要成本、赋值函数成本、吞吐量目标、存活空间的字节数、空闲空间的字节数、前一次提升的大小、前一次Eden区大小、期望的提升大小，期望的Eden区大小以及当前Survivor区的大小。

        用-XX:-UseAdaptiveSizePolicy关闭自适应尺寸调整时，只会报告Minor GC后的字节数、Minor GC中提升的字节数以及Survivor区是否溢出。

        需要关闭自适应尺寸调整时，可以使用-XX:-UseAdaptiveSizePolicy。为了使对象老化和Survivor晋升对象到老年代变得更有效，需要直接对新生代的Eden和Survivor区进行仔细调优，此时可以利用这些生成的统计数据。

 

        42）-XX:+PrintGCApplicationStoppedTime

        打印由Hotspot VM内部操作使得应用线程停止所持续的时间，这些操作包括Stop-The-World垃圾收集、CMS收集器的Stop-The-World阶段和任何其他的安全点操作。

        这个选项适用于强调低延迟的应用程序，如果想让应用程序的延迟事件与Hotspot VM安全点操作引起的延迟相关联，这个选项就非常有用。

 

        43）-XX:+PrintGCApplicationConcurrentTime

        打印应用线程随Hotspot VM内部线程并发执行所用的时间。换句话说，是应用线程在Hotspot VM停止应用线程的操作之间所运行的时间。

        这个选项适用于强调低延迟的应用程序，如果想让应用的延迟事件与Hotspot VM安全点操作所引起的延迟相关联，这个选项也非常有用。

 

        44）-XX:+PrintSafePointStatistics

        打印Hotspot VM已经发生的安全点操作和发生的时间。在Hotspot VM退出时打印这些统计数据。发生的每个安全点在输出中都占有一行。每行包括自Hotspot VM启动该安全操作以来的时间、Hotspot VM操作类型、当前Hotspot VM中的活跃线程数、当前线程数、当前开始运行的线程数、当前阻塞等待的线程数、线程白旋的时间（毫秒)、线程阻寒的时间（毫秒)、线程同步的时间（毫秒），线程清除的时间（毫秒），VM操作的毫秒时间和页面中断数最后打印的是总计，包括不同安全点操作的总数、最长同步时间（毫秒）和用时最多的安全点操作。

        有些应用强调低延迟，如果想让应用的延迟事件与Hotspot VM安全点操作所引起的延迟相关联，就可以使用这个选项。

 

        45）-XX:+BackgroundCompilation

        指示JIT编译器作为后台任务运行，以解释模式运行方法直到后台编译完成。Hotspot VM默认开启该选项。

        在写微基准测试时，可用-XX:-BackgroundCompilation关闭后台编译，这会使JIT编译器的行为更加明确，微基准测试的结果也更可靠。

        关闭后台编译除了-XX:-BackgroundCompilation之外，也可以用-Xbatch。

 

        46）-XX:+TieredCompilation

        开启（多层）JIT编译策略，先是进行快速的JIT编译，类似Hotspot VM的-client运行时环境所作的优化，然后是更高级的JIT编译，接近Hotspot VM的-server运行时环境为程序中频繁调用的Java方法所作的优化。

        简单来说，该策略汲取了-client运行时环境和-server运行时环境的精华，先快速编译，再为高频度Java方法进行高级优化。

        运行在Java6 update 25或更高版本上的客户端应用，可以考虑用此选项结合-server运行时环境（-server -XX:+TieredCompilation)替代-client运行时环境。建议你测量应用的启动性能和响应能力，以评估-server运行时环境结合-XX:+TieredCompilation是否比-client运行时环境更合适。

 

 

        47）-XX:+PrintInlining

        报告已经或试图内联的方法，以及方法字节码的字节长度。

        使用-XX:+PrintInliningn需要Hotspot Debug VM的虚拟机版本。

        -XX:+PrintInlining:输出的信息可用来仔细对-XX:MaxintineSize=<n>进行调优。

 

        48）-XX:MaxinlineSize=<n>

        除非有足够的证据，例如性能分析信息表明这个方法是热方法，否则字节码长度超出这个最大值的方法不会被内联。

        不建议使用该选项。几乎没有应用能从显示设定-XX:MaxinlineSize中得到什么好处。

 

        49）-XX:+PrintOptoAssembly

        打印Hotspot Server JIT编译器所作的优化决策，包括生成的汇编码。

        需要Hotspot debug Server VM(只在Hotspot debug VM开启-server时有效)。

        可用于理解和评估Server JIT编译器所作的优化决策，特别是在微基准测试中。

        一般来说，性能分析工具，例如Oracle solaris或Linux上的Coracle solaris studio performance Analyzer，为比微基准测试规模还大的应用程序提供了更好的方法，可以观察编译器的生成代码。

        但在Performance Analyzer显示的汇编码中，无法提供任何关于编译器优化策略的信息。

 

        50）-XX:+HeapDumpOnOutOfMemoryError

        在OutOfMemoryError发生时，生成JVM堆的转储文件。

        堆的转储文件创建在启动JVM的目录里，文件名形如java_pid<jvm process id>. Hprof，<JVM process id>是执行Java程序的JVM进程的进程id。

        如果你想在Java程序发生OutOfMemoryError时进行内存使用情况分析，可以用此选项。

 

        51）-XX:HeapDumpPath=<Path>

        设置堆转储文件的生成目录路径为<Path>。可以将堆转储文件直接生成到指定的目录位置。

 

        52）-XX:OnOutOfMemoryError=<command or set of commands>

        允许Hotspot VM遇到OutoMemoryError时可以运行一个或者一组命令。在发生OutOfMemory时希望能执行指定的命令，可以使用该选项。

 

        53）-XX:+ShowMessageBoxOnError

        允许Hotspot VM退出前显示对话框(GUI)，表明它遇到了致命错误。

        这个选项是为了避免Hotspot VM直接退出而设计的，你有机会使用调试器连接Hotspot VM，调查致命错误的原因。

        如果想在Hotspot VM遇到致命错退出前进行诊断，可以使用该选项。

 

        54）-XX:OnError=<command or set of commands>

        允许应用程序遇到Hotspot VM意外退出时调用一组命令。如果你想搜集特定的系统信息或者立即调用调试器（例如Oracle solaris或Linux上的dbx或Windows上的Winddbg)检查VM的意外退出，可以使用该选项。

 

 

        55）-XX:+AggressiveOpts

        允许使用最新的Hotspot VM性能优化。

        想在Java程序上尝试一切能找到的性能优化时，可以使用该选项。

        性能优化第一次引人Hotspot VM中时，常常在这个选项下。发布了若干优化后，才会成为默认优化。

        对于稳定性或可用性高于性能的应用程序，不建议使用该选项。

 

        56）-XX:+AggressiveHeap

        建议使用-XX:+AggressiveOpts而不是-XX:+AggressiveHeap

 

        57）-XX:+UsebiasedLocking

        开启偏向锁特性。

        Java 5 Hotspot VM引入了该特性，开启时，Hotspot VM会偏向先前保持该锁的线程。在没有锁竞争的情况下，几乎没有锁开销。

        在Java 5 Hotspot VM中，使用该特性必须显式开启-XX:+UsebiasedLocking。在Java 6 Hotspot VM中，这个特性默认自动开启。如果不希望在Java 6 hotspot VM以上使用该特性，必须显式关闭-XX:-UsebiasedLocking。

        一般来说，对大多数Java应用程序都适用该特性。有些应用程序中，获取锁的线程与刚获取锁的线程不同。例如锁主要是在Worker线程池和Worker线程之间轮换的应用，对于这类Java应用程序来说，撤销偏向锁需要Hotspot VM安全点操作，关闭偏向锁-XX:-UsebiasedLocking会更有利。

 

        58）-XX:+DoescapeAnalysis

        开启逃逸分析的优化特性。某个执行线程分配的对象，如果能为其他某个线程所见，那它就是"逃逸"了。如果一个对象没有逃逸，Hotspot VM Server JIT编译器就可以执行以下优化。

*对象爆炸:对象的字段分配在不同的地方，可能会消除对象分配。

        *标量替换:在CPU寄存器中存储标量字段。

        *线程栈分配:在栈帧中存储对象字段。

        *同步消除。

        *消除垃圾收集的读写屏障。

        -XX:+DoescapeAnalysis随-XX:+AggressiveOpts自动开启，但在Java 6 update 23之前的Java6中默认关闭。自Java 6 update14引入。

 

        59）-XX:+UseLargePages

        允许Hotspot VM使用大内存分页。

        Oracle Solaris平台自动开启该选项，Linux或Windows不会自动开启。使用该选项可以减少TLB(分页缓存）的未命中率。

        32位Intel和AMDX86支持4MB分页。

        64位Intel和AMDX86支持2MB分页。

        最新的64位Intel和AMDX86支持1GB分页。

        SPARCT系列支持最多256MB分页，最新的T系列支持最多2GB分页。

        Oracle Solaris的pagesize -a命令可以报告底层硬件系统支持的分页尺寸。Oracle Solaris上的大分页不需要更改操作系统的其他配置。

        Linux的get conf PAGESIZE或get conf PAGE_SIZE报告当前配置的分页尺寸。Linux需要其他的操作系统配置。所需的更改依据Linux发行版和Linux内核的不同而有所不同。建议向Linux管理员咨询或者查阅你的Linux发行文档，以便了解相应的改动。

 

        60）-XX:LargePageSizeInBytes=<n>[g|m|k]

        允许Hotspot VM使用指定尺寸的大内存分页。底层硬件平台必须支持<n>[g|m|k]大小的分页尺寸，否则就使用默认的分页尺寸。

        你还可以指定的分页尺寸，例如AMD或Intel平台支持IGB分页，可以指定1GB，又比如SPARCT系列的256MB分页，或最新SPARCT系列平台的2GB分页。

 

        61）-XX:+AlwaysPreTouch

        Hotspot VM在初始化时会提交所有内存分页，该选项强制Hotspot VM在初始化过程中，触碰所有这些归JVM使用的内存分页。默认情况下，内存分页只在需要它们的时候才会被提交。换句话说，这个选项确保在JVM堆空间填充时，内存分页已被提交了。

        垃圾收集要复制对象到Survivor区或提升对象到老年代，就必须使用新内存页，由但于新内存页要清零和提交，从而拉长垃圾收集的停顿时间。

        注意：这个额外的开销只是在首次需要该内存页时才有。

        如果Hotspot VM使用大内存分页而不开启这个选项，那么在垃圾收集过程中，新内存页清零和提交带来的额外开销就会相当可观。因此，在使用大内存分页时，应该开启-XX:+AlwaysPreTouch

        虽然开启-XX:++AlwaysPreTouch增加了应用程序的启动时间，但在Java堆消耗过程就不会出现因页面清零和提交而导致的漫长的垃圾收集停顿时间了。

 

        62）-XX:+PrintCommandLineFlags

        打印Hotspot VM依据命令行设定选项经过自动优化之后的设置。

        可以了解Hotspot VM自动优化选择的值，例如JVM堆尺寸和选择的垃圾收集器。

 

        63）-XX:+PrintFlagsFinal

        打印所有product（生产）类型的Hotspot VM命令行选项，包括名字和相应的值，这些值由Hotspot VM依据命令行显式指定的选项设置，如果没有指定，则采用Hotspot VM的默认值。Java 6 update 21开始引入。

        可以了解某个Java应用程序正在使用的Hotspot VM选项配置。

        与-XX:+PrintCommandLineFlags相比，-XX:+PrintFlagsFinal可以打印所有的Hotspot VM选项以及它们相应由Hotspot VM设定的值，而不仅是自动优化设定的值。