关于线上JVM动态参数设置调优

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

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

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

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

 笔者环境打印:

java -server -Xmx1024m -Xms1024m -XX:+UseConcMarkSweepGC -XX:+PrintFlagsFinal -version| grep ParallelGCThreads
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
uintx ParallelGCThreads = 4 {product}
java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)

1.1 取消偏向锁 -XX:-UseBiasedLocking

JDK1.6开始默认打开的偏向锁,会尝试把锁赋给第一个访问它的线程,取消同步块上的synchronized原语。如果始终只有一条线程在访问它,就成功略过同步操作以获得性能提升。

但一旦有第二条线程访问这把锁,JVM就要撤销偏向锁恢复到未锁定线程的状态,详见 JVM的Stop The World,安全点,黑暗的地底世界, 可以看到不少RevokeBiasd的纪录,像GC一样,会Stop The World的干活,虽然只是很短很短的停顿,但对于多线程并发的应用,取消掉它反而有性能的提升和延时的极微的缩短,所以Cassandra就取消了它。

 

1.2 -XX:AutoBoxCacheMax=20000

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

 

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

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

 

1.4 -XX:+PerfDisableSharedMem

Cassandra家的一个参数,一直没留意,直到发生高IO时的JVM停顿。原来JVM经常会默默的在/tmp/hperf 目录写上一点statistics数据,如果刚好遇到PageCache刷盘,把文件阻塞了,就不能结束这个Stop the World的安全点了。用此参数可以禁止JVM写statistics数据,代价是jps, jstat 用不了,只能用JMX取数据。有时用JMX取新生代老生代使用百分比还真没jstat方便。详见The Four Month Bug: JVM statistics cause garbage collection pauses

 

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

此江湖偏方原用于Tomcat显式使用SHA1PRNG算法时,初始因子从/dev/random读取导致堵塞。而使用此设置后,额外效果是默认的SecureRandom算法也变成SHA1了。 SHA1PRNG 比 NativePRNG消耗小一半,synchronized的代码少一半,所以没特殊安全要求的话建议用SHA1。详见 SecureRandom的江湖偏方与真实效果

原文地址:https://www.cnblogs.com/zhangfengshi/p/7068823.html