转载自 ---- http://agapple.iteye.com/blog/1038336
背景
前段时间一直在关注一些牛人的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对象拆散,将其成员变量恢复为分散的变量,这就叫做标量替换。拆散后的变量便可以被单独分析与优化,可以各自分别在活动记录(栈帧或寄存器)上分配空间;原本的对象就无需整体分配空间了。
- 栈上分配
- 分析找到未逃逸的变量,将变量类的实例化内存直接在栈里分配(无需进入堆),分配完成后,继续在调用栈内执行,最后线程结束,栈空间被回收,局部变量也被回收。<span style= "font-family: Arial, sans-serif, Helvetica, Tahoma; white-space: normal;" > </span>
- 锁削除
- 锁削除是指虚拟机即时编译器在运行时,对一些代码上要求同步,但是被检测到不可能存在共享数据竞争的锁进行削除。锁削除的主要判定依据来源于逃逸分析的数据支持,如果判断到一段代码中
- 在堆上的所有数据都不会逃逸出去被其他线程访问到,那就可以把它们当作栈上数据对待,认为它们是线程私有的,同步加锁自然就无须进行
- 锁膨胀
- 原则上,我们在编写代码的时候,总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步,这样是为了使得需要同步的操作数量尽可能变小,如果存在锁竞争,那等待锁的线程也能尽快地拿到锁。
- 大部分情况下,上面的原则都是正确的,但是如果一系列的连续操作都对同一个对象反复加锁和解锁,甚至加锁操作是出现在循环体中的,那即使没有线程竞争,频繁地进行互斥同步操作也会导致不必要的性能损耗。 <span style="font-family: Arial, sans-serif, Helvetica, Tahoma; white-space: normal;" > </span>
-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-p 2
- -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的属性指针(静态成员变量)
- 每个对象的属性指针
- 普通对象数组的每个元素指针
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