java虚拟机参数优化_JAVA虚拟机JVM参数优化（2）：垃圾收集算法选择

JAVA虚拟机JVM优化重要性，昨天JAVA虚拟机JVM参数优化(1)文章中已经描述，今天我们来讨论JAVA虚拟机在不同性能要求下如何选择三种垃圾收集算法。

JVM内部结构如下图所示：

串行收集用于单个线程执行垃圾收集的情况，在这种情况下相对它是有效的，因为它不需要和其他线程进行通讯。它适用于单个处理器机器，或者在多处理器情况下数据量小于100MB。串行收集通过参数 -XX:+UseSerialGC声明工作。

并行收集通过并行较小的收集来降低整个垃圾收集周期。中等或者大型数据量的应用运行在多处理和多线程建议采用并行收集，它通过参数-XX:+UseParallelGC声明工作。并行压缩是允许并行收集器并行执行主要集合的功能。如果不进行并行压缩，则使用单个线程执行主要集合，这会显著限制可伸缩性。如果指定了-xx:+useParallelGC选项，则默认情况下启用并行压缩。关闭它的选项是-xx:-UseParallelOldGC。

大多数并发收集器同时执行其大部分工作(例如，当应用程序仍在运行时)，以缩短垃圾收集暂停时间。它是为具有中型到大型数据集的应用程序设计的，在这些数据集中，响应时间比总吞吐量更重要，通过用于最小化暂停的技术会降低应用程序性能。Java热点VM提供了两个主要并行收集器之间的选择；参见大多数并发收集器。使用选项-xx:+UseConcMarkSweepGC启用CMS收集器或-xx:+UseG1GC启用g1收集器。

选择收集器

除非应用程序有相当严格的暂停时间要求，否则首先运行应用程序并允许VM选择一个收集器。如有必要，请调整堆大小以提高性能。如果性能仍然不符合您的目标，那么使用以下准则作为选择收集器的起点。

如果应用程序有一个小的数据集(高达大约100 MB)，则

使用选项-xx:+UseSerialGC选择串行收集器。

如果应用程序将在单个处理器上运行，并且没有暂停时间要求，那么让虚拟机选择收集器，或者使用选项-xx:+UseSerialGC选择串行收集器。

如果(a)应用程序性能峰值是第一优先级，并且(b)没有暂停时间要求，或者可以接受1秒或更长的暂停，那么让虚拟机选择收集器，或者使用-xx:+useParallelGC选择并行收集器。

如果响应时间比总吞吐量更重要，并且垃圾收集暂停时间必须保持短于约1秒，则使用-xx:+useConcMarkSweepgc或-xx:+UseG1GC选择并发收集器。

这些准则仅为选择收集器提供了一个起点，因为性能取决于堆的大小、应用程序维护的活动数据量以及可用处理器的数量和速度。暂停时间对这些因素特别敏感，因此前面提到的1秒阈值只是近似值：在许多数据大小和硬件组合上，并行收集器将经历超过1秒的暂停时间；相反，在某些组合上，并发收集器可能无法保持低于1秒的暂停时间。

如果推荐的收集器没有达到所需的性能，请首先尝试调整堆和生成大小以满足所需的目标。如果性能仍然不足，请尝试其他收集器：使用并发收集器减少暂停时间，并使用并行收集器增加多处理器硬件上的总吞吐量。

SPEC JBB2015MULTI测试结果分析

选取SPEC JBB2015MULTI测试结果中Java HotSpot 64-bit Server VM，version 1.8.0_131，厂商报告Cisco思科、DELL戴尔、H3C华三、HP、Inspur浪潮、Levovo联想、Quanta台湾广达。

我们选取每个厂商中得分最高的测试结果，并且按使用堆内存数量大小升序排，如下所示。

Inspur Corporation Inspur NF5280M4 256GB/29GB 39635

-server -XX:LargePageSizeInBytes=2m -XX:+AggressiveOpts -XX:-UseAdaptiveSizePolicy -XX:+AlwaysPreTouch -XX:-UseBiasedLocking -XX:+UseLargePages -XX:+UseParallelOldGC -Xms29g -Xmx29g -Xmn27g -XX:SurvivorRatio=28 -XX:TargetSurvivorRatio=95 -XX:ParallelGCThreads=22 -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

Quanta Computer Inc. QuantaGrid D52B-2U 384GB/30GB 40874

-showversion -server -XX:+UseLargePages -XX:LargePageSizeInBytes=2m -XX:+AggressiveOpts -XX:-UseAdaptiveSizePolicy -XX:+AlwaysPreTouch -XX:-UseBiasedLocking -XX:+UseParallelOldGC -XX:SurvivorRatio=28 -XX:TargetSurvivorRatio=95 -XX:MaxTenuringThreshold=15 -Xms30g -Xmx30g -Xmn27g -XX:ParallelGCThreads=28

PowerEdge R640 786GB/180GB 69059

-showversion -server -XX:+AlwaysPreTouch -XX:+UseParallelOldGC -XX:-UseAdaptiveSizePolicy -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution -XX:-UseBiasedLocking -XX:+AggressiveOpts -XX:+UseLargePages -XX:LargePageSizeInBytes=2m -XX:SurvivorRatio=26 -XX:TargetSurvivorRatio=95 -Xms180g -Xmx180g -Xmn178g -XX:ParallelGCThreads=28 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

Lenovo Global Technology ThinkSystem SR650 768GB/350GB 114309

-server -Xms350g -Xmx350g -Xmn340g -XX:SurvivorRatio=40 -XX:MaxTenuringThreshold=15 -XX:+UseLargePages -XX:LargePageSizeInBytes=2m -XX:+UseParallelOldGC -Xnoclassgc -XX:+AggressiveOpts -XX:+AlwaysPreTouch -XX:-UseAdaptiveSizePolicy -XX:-UsePerfData -XX:TargetSurvivorRatio=98 -XX:ParallelGCThreads=56 -XX:-UseBiasedLocking -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps

H3C UniServer R4900 G3 1536GB/710GB 120287

-XX:+UseParallelOldGC -Xms710g -Xmx710g -Xmn690g -XX:-UsePerfData -server -XX:AllocatePrefetchInstr=2 -XX:LargePageSizeInBytes=2m -XX:+AggressiveOpts -XX:-UseAdaptiveSizePolicy -XX:+AlwaysPreTouch -XX:-UseBiasedLocking -XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m -XX:+UseLargePages -XX:SurvivorRatio=48 -XX:TargetSurvivorRatio=90 -XX:ParallelGCThreads=56 -XX:MaxTenuringThreshold=15

Hewlett Packard Enterprise ProLiant DL380 Gen10 1536GB/735GB 117090

-XX:-UsePerfData -server -XX:AllocatePrefetchInstr=2 -XX:LargePageSizeInBytes=2m -XX:+AggressiveOpts -XX:-UseAdaptiveSizePolicy -XX:+AlwaysPreTouch -XX:-UseBiasedLocking -XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m -XX:+UseLargePages -XX:+UseParallelOldGC -Xms735g -Xmx735g -Xmn681g -XX:SurvivorRatio=68 -XX:TargetSurvivorRatio=48 -XX:ParallelGCThreads=56 -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseRTMLocking -XX:InlineSmallCode=10k -XX:MaxGCPauseMillis=300

Cisco UCS C240 M5 1536GB/710GB jOPS:118551

-XX:+UseParallelOldGC -Xms710g -Xmx710g -Xmn690g -XX:-UsePerfData -server -XX:AllocatePrefetchInstr=2 -XX:LargePageSizeInBytes=2m -XX:+AggressiveOpts -XX:-UseAdaptiveSizePolicy -XX:+AlwaysPreTouch -XX:-UseBiasedLocking -XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m -XX:+UseLargePages -XX:SurvivorRatio=48 -XX:TargetSurvivorRatio=90 -XX:ParallelGCThreads=56 -XX:MaxTenuringThreshold=15

从上面数据可以得知SPEC JBB2015都是为了达到吞吐量最大化，再优化响应时间性能，因此所有厂商都不约而同选择了-server 默认并行收集，同时关闭默认并行压缩算法，开启-XX:+UseParallelOldGC；垃圾收集并行线程数-XX:ParallelGCThreads 设置为服务器总核数 56 28，加快并行收集效率

在堆划分-XX:-UseAdaptiveSizePolicy 采用系统自动适应策略；-XX:SurvivorRatio=28 48 ，尽可能把堆留给年轻对象；-XX:MaxTenuringThreshold=15对象被计数15次才会分配到老年；-XX:TargetSurvivorRatio=95

测试机器都普遍内存多，因此都使用了XX:+UseLargePages -XX:LargePageSizeInBytes=2m 优化大内存

另外-XX:+AggressiveOpts -XX:+AlwaysPreTouch -XX:-UseBiasedLocking这3个指令所有厂商也都不约而同使用

HP惠普还使用-XX:MaxGCPauseMillis=300参数，限制最大一次垃圾收集停顿时间。

总结：JVM调优中最重要还是堆内存的准确预估，可以通过JVM监控来掌握，选择并行垃圾收集普通情况下优于其他串行和并发收集。通过SPEC测试分析可以了解JVM并行收集影响性能最重要的参数，大部分厂商使用的参数基本相同。

文章参考：