关键业务系统的JVM启动参数推荐

在关键的业务系统里，除了继续追求技术人员最爱的高吞吐与低延时之外，系统的稳定性与出现问题时排查的便捷性也很重要。

这是本文的一个原则，后面也会一次又一次的强调，所以与网上其他的文章略有不同，请JVM调优高手和运维老大们多指引。

前言1，资料

学习开源项目的启动脚本是个不错的主意，比如 Cassandra家的 ， 附送一篇 解释它的文章 。

偶然翻到Linkedin工程师的 一篇文章 。

更偶然翻到的 一份不错的参数列表 。

前言2， -XX:+PrintFlagsFinal打印参数值

当你在网上兴冲冲找到一个可优化的参数时，先用-XX: +PrintFlagsFinal看看，它可能已经默认打开了，再找到一个，还是默认打开了....

JDK7与JDK8，甚至JDK7中的不同版本，有些参数值都不一样，所以不要轻信网上任何文章，一切以生产环境同版本的JDK打出来的为准。

经常以类似下面的语句去查看参数，偷懒不起应用，用-version代替。有些参数设置后会影响其他参数，所以查看时也把它带上。

前言3，关于默认值

JDK8会默认打开-XX:+TieredCompilation多层编译，而JDK7则不会。JDK7u40以后的版本会默认打开-XX:+OptimizeStringConcat优化字符串拼接，而之前的则不打开。

对于这些参数，我的建议是顺势而为，JDK在那个版本默认打开不打开总有它的理由。安全第一，没有很好的因由，不要随便因为网上某篇文章的推荐(包括你现在在读的这篇)就去设置。

1. 性能篇

先写一些不那么常见的，后面再来老生常谈。

1.1 取消偏向锁 -XX:-UseBiasedLocking

JDK1.6开始默认打开的偏向锁，在没有竞争的情况下，会取消线程同步的原语，比如那个所有方法都挂着synchronized关键字的StringBuffer，如果始终只有一条线程在访问它，就略过同步操作以获得性能提升。

但一旦有第二个线程访问这把锁，JVM就要撤销偏向锁恢复到未锁定线程的状态，用"-XX:+PrintSafepointStatistics -XX: PrintSafepointStatisticsCount=1"可以看到不少RevokeBiasd的纪录，像GC一样，会Stop The World的干活，虽然只是很短很短的停顿，但对于多线程并发的应用，取消掉它反而有性能的提升和延时的极微的缩短，所以Cassandra就取消了它。

1.2 启动时访问并置零内存页面-XX:+AlwaysPreTouch

启动时就把参数里说好了的内存全部舔一遍，可能令得启动时慢上一点，但后面访问时会更流畅，比如页面会连续分配，比如不会在晋升新生代到老生代时才去申请页面使得GC停顿时间加长。不过这选项对32G之类的大堆才会更有感觉一点。

1.3 -Djava.security.egd=file:/dev/./urandom

1.4 -XX:AutoBoxCacheMax=20000 与 不建议打开的-XX:+AggressiveOpts

Integer i = 3; 这语句有着 int自动装箱成Integer的过程，JDK默认缓存 -128~ +128的int 和 long，超出范围的数字就要即时构建新的Integer对象。设为20000后，我们应用的QPS从48,000提升到50,000，足足4%的影响。详见 Java Integer(-128~127)值的==和equals比较产生的思考

这是-XX:+AggressiveOpts中的其中一项，AggressiveOpts是一些还没默认打开的优化参数集合。但如前所述，关键系统里不建议打开。虽然通过-XX:+AggressiveOpts 与 -XX:-AggressiveOpts 的对比，目前才改变了三个参数，但为免以后某个版本的JDK里默默改变更多激进的配置，还是不要了。

Linkined那种黑科技，先要解锁VMOptions才能配置的就更不用说了，比如

1.5 -server

-server 与 -client的JVM默认参数完全不一样，虽然在Linux 64位JVM里默认会被认成server模式，但还是顺手写上吧。

1.6 GC策略

为了稳健，还是CMS好了，G1的细节实现起来难度太大，从理论提出到现在都做了六七年了。

CMS真正可设的东西也不多，详见 JVM实用参数（七）CMS收集器

因为我们的监控系统会通过JMX监控内存达到90%的状况（留点处理的时间），所以设置让它75%就开始跑了。为了让这个设置生效，还要设置-XX:+UseCMSInitiatingOccupancyOnly，否则75只被用来做开始的参考值，后面还是JVM自己算。

-XX:MaxTenuringThreshold=2，这是GC里改动效果最明显的一个参数了。对象在Survivor区熬过多少次Young GC后晋升到年老代，JDK7里看起来默认是6，跑起来好像变成了15。

Young GC是最大的应用停顿来源，而新生代里GC后存活对象的多少又直接影响停顿的时间，所以如果清楚Young GC的执行频率和应用里大部分临时对象的最长生命周期，可以把它设的更短一点，让其实不是临时对象的新生代赶紧晋升到年老代，别呆着。

用-XX:+PrintTenuringDistribution观察下，如果后面几代都差不多，就可以设小，比如JMeter里是2，一般6也够了。

-XX: ParallelRefProcEnabled, 默认为false，并行的处理Reference对象，如WeakReference，除非在GC log里出现Reference处理时间较长的日志，否则效果不会很明显，但我们总是要JVM尽量的并行，所以设了也就设了。

其他不必设的参数

-XX:+CMSClassUnloadingEnabled，在CMS中清理永久代中的过期的Class而不等到Full GC，JDK7默认关闭而JDK8打开。看自己情况，比如有没有运行动态语言脚本如Groovy产生大量的临时类。它会增加CMS remark的暂停时间，所以如果新类加载并不频繁，这个参数还是不开的好。

用了CMS，新生代收集默认就是-XX:+UseParNewGC，不用自己设。

并发收集线程数，ParallelGCThreads＝8+( Processor - 8 ) ( 5/8 )， ConcGCThreads = (ParallelGCThreads + 3)/4，比如双CPU，六核，超线程就是24个处理器，小于8个处理器时ParallelGCThreads按处理器数量，大于时按上述公式 ParallelGCThreads＝18， ConcGCThreads＝5。这线程数调整了变化也不大，还是别乱动了。

-XX:+DisableExplicitGC， 详见 Netty之堆外内存扫盲篇 ，禁了system.gc() 未必是好事，只要自己的代码里没有调它，也没用什么特别烂的类库，真有人调了总有调的原因。

1.7 大小的设置

这些关于大小的参数，给人感觉是最踏实可控的。

其实JVM除了显式设置的堆内存，还有一堆其他占内存的地方，在容量规划的时候要留意。

关键业务系统的服务器上内存一般都是够的，所以尽管设得宽松点。

-Xmx, -Xms, 堆内存大小，2～4G均可，再大了GC时间会拖长。

-Xmn or -XX:NewSize and -XX:MaxNewSize or -XX:NewRatio， JDK默认新生代占堆大小的1/3， 个人喜欢把对半分，用-Xmn 直接赋值(等于-XX:NewSize and -XX:MaxNewSize同值的缩写)，或把NewRatio设为1。 增大新生代的大小，能减少GC的频率（但也会加大每次GC的停顿时间），主要是看老生代里没多少长期对象的话，占2/3太多了。

-XX: PermSize=128m -XX:MaxPermSize=512m （JDK7）现在的应用有Hibernate/Spring这些闹腾的家伙AOP之后类都比较多，可以一开始就把初始值从64M设到128M，并设一个更大的Max值以求保险。

-XX:MetaspaceSize=128m（JDK8），JDK8的永生代几乎可用完机器的所有内存，同样设一个128M的初始值。

其他可选项

-XX:SurvivorRatio新生代中每个存活区的大小，默认为8，即1/10的新生代 1/(SurvivorRatio+2)，有人喜欢设小点省点给新生代，但要避免太小使得存活区放不下临时对象而要晋升到老生代，还是从GC Log里看实际情况了。

-Xss在堆之外，线程占用栈内存，默认每条线程为1M（以前是256K）。除了方法调用出参入参的栈，逃逸分析后也会把只在该线程里可见的对象直接分配在线程栈里，而不是公共的Heap里，也就减少了新生代的GC频率。有人喜欢设小点节约内存开更多线程，但反正内存够也就不必要设小，有人喜欢再设大点。

-XX:MaxDirectMemorySize，堆外内存/直接内存的大小，默认和堆内存差不多大，详见 Netty之堆外内存扫盲篇 。

-XX:ReservedCodeCacheSize， JIT编译后二进制代码的存放区，满了之后就不再编译。JDK7默认50M，而JDK8开启了多层编译所以默认为256M。可以在JMX里看看 CodeCache的大小，JDK7下的50M不开多层编译一般够了，也可以把它设大点，反正内存多。

2. 监控篇

JVM输出的各种日志，如果未指定路径，通常会生成到运行应用的相同目录，为了避免有时候在不同的地方执行启动脚本，一般将日志路径集中设到一个固定的地方。

2.1 -XX:+PrintCommandLineFlags

2.2 -XX:-OmitStackTraceInFastThrow

为异常设置StackTrace是个昂贵的操作，所以当应用在相同地方抛出相同的异常N次（两万？）之后，JVM就会优化，只输出异常信息而不带异常栈。此时，你可能会看到日志里一条条Null Point Exception，而真正输出完整栈的日志早被滚动到不知哪里去了，也就完全不知道这NPE发生在什么地方，欲哭无泪。 所以，将它禁止吧。

2.3 coredump与 -XX:ErrorFile=${MYLOGDIR}/hs_err_%p.log

JVM crash时，hotspot 会生成一个error文件，提供JVM状态信息的细节。如前所述，将其输出到固定目录，避免到时会到处找这文件。文件名中的%p会被自动替换为应用的PID

当然，更好的做法是生成coredump，从CoreDump能够转出Heap Dump 和 Thread Dump 还有crash的地方，非常实用。

在启动脚本里加上 ulimit -c unlimited或其他的设置方式，如果有root权限，用一下一下输出目录更好

什么？你不知道这东西什么用？看来你是没遇过JVM Segment Fault的幸福人。

2.4 -XX:+HeapDumpOnOutOfMemoryError

在Out Of Memory，JVM快死快死掉的时候，输出Heap Dump到指定文件。不然开发很多时候还真不知道怎么重现错误。

2.5 GC日志

详见 JVM实用参数（八）GC日志 ，有人担心写GC日志会影响性能，但测试下来实在没什么影响，还是留一份用来排查好。

另外，“-XX:+PrintGCApplicationStoppedTime” 还可以打印除GC外的停顿时间，比如取消偏向锁，instrumentation，code deoptimization等。

GC日志默认会在重启后清空，但有人担心长期运行不重启的应用会把文件弄得很大，有些-XX:+UseGCLogFileRotation相关的参数可以让日志滚动起来。但重启后的文件名太混乱太让人头痛，所以还是不加。

2.6 JMX

以上设置，只让本地的Zabbix之类监控软件通过JMX监控JVM，不允许远程访问。