转载

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

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

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

前言1，资料

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

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

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

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

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

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

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

java -server -Xmx1024m -Xms1024m -XX:+UseConcMarkSweepGC -XX:+PrintFlagsFinal -version| grep ParallelGCThreads

前言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

UUID.randomUUID() 有时候会很慢，Thread Dump一看居然被锁住了，原因是里面用了SecureRandom，要等待机器产生新的噪音(比如机器里的某个文件发生了变化)才肯产生新的随机数。因此最好让熵池里没有新的噪音因子时重用当前的因子。详见

JVM上的随机数与熵池策略

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才能配置的就更不用说了，比如

-XX:+UnlockDiagnosticVMOptions -XX 关键业务系统的JVM启动参数推荐 arGCCardsPerStrideChunk=32768

1.5 -server

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

1.6 GC策略

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

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

-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly

因为我们的监控系统会通过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

运维有时会对启动参数做一些临时的更改，将每次启动的参数输出到stdout，将来有据可查。

打印出来的是命令行里设置了的参数以及因为这些参数隐式影响的参数，比如开了CMS后，-XX:+UseParNewGC也被自动打开。

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权限，用一下一下输出目录更好

echo "/{MYLOGDIR}/coredump.%p" > /proc/sys/kernel/core_pattern

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

2.4 -XX:+HeapDumpOnOutOfMemoryError

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

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${LOGDIR}/oom.hprof

2.5 GC日志

-Xloggc:${LOGDIR}/gc-$SERVER_API.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails

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

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

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

2.6 JMX

-Dcom.sun.management.jmxremote.port=${MY_JMX_PORT} -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=127.0.0.1

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

正文到此结束