jvm优化参数整理(持续补充)

背景

前段时间一直在关注一些牛人的blog，主要的关注点在一些性能优化上，一些细小的jvm参数优化上。以前这一块一直是自己的弱项，把这段时间看的内容做一个记录。

过程

先认识一下几位大牛的http://rednaxelafx.iteye.com , http://kenwublog.com/， 貌似都是taobao中间件团队的，blog文章都写的比较不错。

 

JIT优化

JIT全程： (Just-in-time) ， sun的一些资料文档： Just-In-Time Java Compiler  ,   http://java.sun.com/developer/onlineTraining/Programming/JDCBook/perf2.html#jit

主要的内容：

• Hot Spot Detection  (热点检测)
• Native code & Method Inlining  (本地代码&方法内联，根c++的内联inline方法有点类似)
• Dynamic Deoptimization (去优化，可以针对代码进行重复的优化/去优化的动作)

提到jit，必须得看一下jvm的解释模式/编译模式。

 

java -Xint -version ## 解释模式，输出interpreted mode
java –Xcomp -version ##编译模式，输出compiled mode
java -Xmixed -version ##混合模式，输出mixed mode

-XX:+PrintCompilation (输出jit编译信息)

 

  1       java.lang.Object::<init> (1 bytes)
  2       com.agapple.jvm.options.TestEAScalarReplacement::test (23 bytes)
  3       com.agapple.jvm.options.Point::<init> (15 bytes)
  4       com.agapple.jvm.options.TestEAScalarReplacement::driver0 (20 bytes)
  5       com.agapple.jvm.options.TestEAScalarReplacement::driver1 (20 bytes)
  6       com.agapple.jvm.options.TestEAScalarReplacement::driver2 (20 bytes)
  7       com.agapple.jvm.options.TestEAScalarReplacement::driver3 (20 bytes)
  8       com.agapple.jvm.options.TestEAScalarReplacement::driver (39 bytes)

 

其他参数：

 

• -XX:CompileCommand=exclude,the/package/and/Class,methodName  #判处指定的方法不做jit优化
• -XX:CompileCommand='compileonly,java/lang/StringBuffer.*' #指定方法做编译
• -XX:CompileThreshold=1000  #通过JIT编译器，将方法编译成机器码的触发阀值，可以理解为调用方法的次数，例如调1000次，将方法编译为机器码

逃逸分析

具体逃逸分析的解释，可以查看：　

 

• wiki文档：http://en.wikipedia.org/wiki/Escape_analysis
• 原理分析：http://kenwublog.com/jvm-optimization-escape-analysis
• 演示例子：http://rednaxelafx.iteye.com/blog/659108

 

针对逃逸分析的优化，可以引出的优化: 

 

• 标量替换
  

  scalar replacement：Java中的原始类型无法再分解，可以看作标量（scalar）；指向对象的引用也是标量；而对象本身则是聚合量（aggregate），可以包含任意个数的标量。
  如果把一个Java对象拆散，将其成员变量恢复为分散的变量，这就叫做标量替换。拆散后的变量便可以被单独分析与优化，可以各自分别在活动记录（栈帧或寄存器）上分配空间；原本的对象就无需整体分配空间了。

• 栈上分配
  

  分析找到未逃逸的变量，将变量类的实例化内存直接在栈里分配(无需进入堆)，分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量也被回收。 

• 锁削除
  

  锁削除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行削除。锁削除的主要判定依据来源于逃逸分析的数据支持，如果判断到一段代码中
  在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行

• 锁膨胀
  

  原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待锁的线程也能尽快地拿到锁。 
  大部分情况下，上面的原则都是正确的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。  

-XX:+DoEscapeAnalysis(开启逃逸分析，jdk6默认开启)

其他相关参数：

• -XX:+PrintInlining  #方法内联
• -XX:+PrintEscapeAnalysis  #逃逸分析内容
• -XX:+PrintEliminateAllocations  #标量替换
• -XX:+PrintAssembly #打印机器码

锁优化相关

几个锁优化的相关概念：

• 自旋锁
  

  自旋锁优化的原理是在线程进入OS互斥前，通过CAS自旋一定的次数来检测锁的释放。
  如果在自旋次数未达到预设值前锁已被释放，则当前线程会立即持有该锁。

• 轻量锁
  

  轻量级锁（Lightweight Locking）,从Java6开始引入了轻量级锁的概念，本意是为了减少多线程进入互斥的几率，并不是要替代互斥。
  它利用了CPU原语Compare-And-Swap(CAS，汇编指令CMPXCHG)，尝试在进入互斥前，进行补救。
  相比于synchronized产生的bytecode原语：monitorenter与monitorexit这两个控制多线程同步的是JVM依赖操作系统互斥(mutex)来实现的。
  互斥是一种会导致线程挂起，并在较短的时间内又需要重新调度回原线程的，较为消耗资源的操作。
  
  白话：每次进行lock之前，先尝试一次CAS

• 偏向锁
  

  Java偏向锁(Biased Locking)是Java6引入的一项多线程优化。它通过消除资源无竞争情况下的同步原语，进一步提高了程序的运行性能。
  与轻量级锁区别在于，轻量级锁是通过CAS来避免进入开销较大的互斥操作，而偏向锁是在无竞争场景下完全消除同步，连CAS也不执行（CAS本身仍旧是一种操作系统同步原语，始终要在JVM与OS之间来回，有一定的开销）。
  
  白话：记录上一次访问的ThreadId，后续有其他线程对资源竞争时，会触发进行偏向锁清除的动作

• 锁消除
  

  在逃逸分析的基础上，如果堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行

• 锁膨胀
 

可以看下几篇文章，介绍的比较详细，相信看了之后也比较有感触，不多做介绍

• sun 文档 ： http://java.sun.com/performance/reference/whitepapers/6_performance.html
• 轻量锁 : http://kenwublog.com/theory-of-lightweight-locking-upon-cas
• 偏向锁： http://kenwublog.com/theory-of-java-biased-locking
• jvm相关参数： http://kenwublog.com/docs/java6-jvm-options-chinese-edition.htm
• Do Java 6 threading optimizations actually work? http://www.infoq.com/articles/java-threading-optimizations-p1 ,  http://www.infoq.com/articles/java-threading-optimizations-p2
• 
  

相关参数：

•  -XX:+DoEscapeAnalysis && -XX:+EliminateLocks   #开启锁消除，注意锁消除是基于逃逸分析的基础，默认两者都打开
• -XX:+PrintEliminateLocks  #打印锁消除日志
• -XX:+UseBiasedLocking  #开启偏向锁
• -XX:+UseSpinning & -XX:PreBlockSpin=10  #启用自旋锁

指针压缩 (-XX:+UseCompressedOops)

OOP = “ordinary object pointer” 普通对象指针。

在64位HotSpot中使用32位指针，默认64位会比32位的内存使用多出1.5倍

启用CompressOops后，会压缩的对象：

• 每个Class的属性指针（静态成员变量）
• 每个对象的属性指针
• 普通对象数组的每个元素指针

比如指向PermGen的Class对象指针，本地变量，堆栈元素，入参，返回值，NULL指针不会被压缩

详细的可以看下http://kenwublog.com/compressedoops

getter方法优化(-XX:UseFastAccessorMethods)

 

Use optimized versions of Get<Primitive>Field. 估计也是使用Jit + inline技术提升相应的访问速度。

其他

还有一些jvm优化主要就是内存参数，GC算法。

 

内存参数主要关注-Xms -Xmn -Xmx -XX:PermSize -Xss 等参数的设置，其中eden堆的设置taobao的一位仁兄的建议是每次request消耗的内存大小×100，也有点道理。

每次request消耗内存的计算 =  young区大小/（young gc时间间隔×每秒请求数)

 

GC算法主要是一些CMS , G1算法。后续再补充

感触 

随着自己看jvm blog越来越多，发现自己对jvm真的是越来越陌生。

神啊，大家简历中尽量少提自己精通jvm了，不然会遭BS，简历和面试中是一大忌。

至少我现在看别人的面试简历就是有这样的一种心态，O(∩_∩)O

评论

5 楼 RednaxelaFX 2011-05-19  

agapple 写道

不是把，最近我们刚在jdk update 18上加上了UseCompressedOops参数，校长没提bug的事

现在jdk update 18遇到了几次jvm crash，主要归为两类： velocity jit优化导致crash，另一个就是GCTaskThread崩溃(一个现象就是eden区100%)

sorry我把两个参数记混了。压缩指针是一直没有禁用的。在JDK 6u18-20里禁用的是 DoEscapeAnalysis

引用

Note that Escape analysis-based optimization ( -XX:+DoEscapeAnalysis) is disabled in 6u18. This option will be restored in a future Java SE 6 update.

4 楼 agapple 2011-05-19  

RednaxelaFX 写道

agapple 写道

很悲剧公司的jdk用的是jdk 6 update 18，上次想迁移到jdk 6 update 23时，发现了jps的一个bug：因为我们用了jetty的原因，导致jps不能用了。所以这事被hold了，不过貌似最近的jdk 6 update 25已经fix该问题，估计最近会有动作

在jdk update 20这个版本下，-XX:+UseCompressedOops参数居然不支持，就让我有点困惑

UseCompressedOops在JDK 6 update 18-20都不支持吧。有bug没修好所以把这个参数强制禁用了。
最近在6u23上也遇到了疑似是跟压缩指针相关的VM crash。所以让遇到crash的应用暂时关闭掉这个功能了。麻烦的就是没有合适的环境再现出这个问题。要在线上跑十来个小时它才偶尔的crash了。

印象中6u18里有个啥很糟糕的问题所以B2B那边是不用这个版本（而退回到6u17）的。貌似是校长说的？

不是把，最近我们刚在jdk update 18上加上了UseCompressedOops参数，校长没提bug的事

现在jdk update 18遇到了几次jvm crash，主要归为两类： velocity jit优化导致crash，另一个就是GCTaskThread崩溃(一个现象就是eden区100%)

3 楼 RednaxelaFX 2011-05-19  

agapple 写道

很悲剧公司的jdk用的是jdk 6 update 18，上次想迁移到jdk 6 update 23时，发现了jps的一个bug：因为我们用了jetty的原因，导致jps不能用了。所以这事被hold了，不过貌似最近的jdk 6 update 25已经fix该问题，估计最近会有动作

在jdk update 20这个版本下，-XX:+UseCompressedOops参数居然不支持，就让我有点困惑

UseCompressedOops在JDK 6 update 18-20都不支持吧。有bug没修好所以把这个参数强制禁用了。
最近在6u23上也遇到了疑似是跟压缩指针相关的VM crash。所以让遇到crash的应用暂时关闭掉这个功能了。麻烦的就是没有合适的环境再现出这个问题。要在线上跑十来个小时它才偶尔的crash了。

印象中6u18里有个啥很糟糕的问题所以B2B那边是不用这个版本（而退回到6u17）的。貌似是校长说的？

2 楼 agapple 2011-05-18  

RednaxelaFX 写道

那个…我不是在中间件团队而是核心系统的

DoEscapeAnalysis在早期JDK6里不是默认开启的。到update 21还是23才默认开了。
可以参考一些环境里HotSpot VM参数的默认值。

自己用-XX:+PrintFlagsFinal来试试看就能知道自己的版本的默认值是什么了。
<< 不过这个参数也是在比较新的JDK6上才加的。比较老的版本上应该是用不了吧。试了一下，是在JDK 6 update 21才开始支持的，前面的版本都不行。

很悲剧公司的jdk用的是jdk 6 update 18，上次想迁移到jdk 6 update 23时，发现了jps的一个bug：因为我们用了jetty的原因，导致jps不能用了。所以这事被hold了，不过貌似最近的jdk 6 update 25已经fix该问题，估计最近会有动作

在jdk update 20这个版本下，-XX:+UseCompressedOops参数居然不支持，就让我有点困惑

-XX:+PrintFlagsFinal这个参数好啊，以后可以试试，多谢撒迦的提携

1 楼 RednaxelaFX 2011-05-18  

那个…我不是在中间件团队而是核心系统的

DoEscapeAnalysis在早期JDK6里不是默认开启的。到update 21还是23才默认开了。
可以参考一些环境里HotSpot VM参数的默认值。

自己用-XX:+PrintFlagsFinal来试试看就能知道自己的版本的默认值是什么了。
<< 不过这个参数也是在比较新的JDK6上才加的。比较老的版本上应该是用不了吧。试了一下，是在JDK 6 update 21才开始支持的，前面的版本都不行。