synchronized 锁优化:html
JDK1.6对锁的实现引入了大量的优化,如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减小锁操做的开销。 三种不一样的锁:偏向锁、轻量级锁和重量级锁。java
所谓锁的升级,降级就是JVM优化synchronized运行的机制,当JVM检测到不一样的竞争状态时,会自动切换到适合的锁实现,这种切换就是锁的升级,降级。程序员
偏向锁:当没有竞争出现时,默认会使用偏向锁。JVM会利用CAS操做,在对象头上的Mark Word部分设置线程ID,以表示这个对象偏向与当前线程,因此并不涉及真正的户斥锁。数组
轻量级锁:当有另外的线程试图锁定某个已经被偏向过的对象,JVM就撤销偏向锁,切换到轻量级锁。安全
synchronized用的锁是存在Java对象头里的,那么什么是Java对象头呢?多线程
Hotspot虚拟机的对象头主要包括两部分数据:Mark Word(标记字段)、Klass Pointer(类型指针)。其中Klass Point是是对象指向它的类元数据的指针,虚拟机经过这个指针来肯定这个对象是哪一个类的实例,Mark Word用于存储对象自身的运行时数据,它是实现轻量级锁和偏向锁的关键。并发
Mark Word用于存储对象自身的运行时数据,如哈希码(HashCode)、GC分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等。Java对象头通常占有两个机器码(在32位虚拟机中,1个机器码等于4字节,也就是32bit),可是若是对象是数组类型,则须要三个机器码,由于JVM虚拟机能够经过Java对象的元数据信息肯定Java对象的大小,可是没法从数组的元数据来确认数组的大小,因此用一块来记录数组长度。app
锁主要存在四中状态,依次是:无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态。他们会随着竞争的激烈而逐渐升级。注意锁能够升级不可降级,这种策略是为了提升得到锁和释放锁的效率。性能
---------------------------总结----------------------------------测试
自旋锁:就是让该线程等待一段时间,不会被当即挂起,看持有锁的线程是否会很快释放锁。
自旋锁就是竞争失败的线程,并不会马上在操做系统层面挂起等待,而是JVM让线程作几个空循环,基于预测在不久的未来就能得到锁,在通过几回循环后,若是能够得到锁,那么进入临界区,若是尚未得到,才会真正将线程在操做系统层面挂起等待。优势减小上下文切换,在竞争不激烈且锁占用时间很是短但代码块来讲会有较大的性能提高,由于自旋的消耗小雨线程阻塞挂起的消耗。但对于竞争激烈和锁占用时间较长的代码块,会更多的额外作空转操做,作无用功,消耗CPU。
在JDK1.6中默认开启。同时自旋的默认次数为10次,能够经过参数-XX:PreBlockSpin来调整。
适应自旋锁:JDK 1.6引入了更加聪明的自旋锁,即自适应自旋锁。所谓自适应就意味着自旋的次数再也不是固定的,它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定,动态调整:线程若是自旋成功了,那么下次自旋的次数会更加多。
锁消除:JVM检测到不可能存在共享数据竞争,这时JVM会对这些同步锁进行锁消除。锁消除的依据是逃逸分析的数据支持。
锁粗化:就是将多个连续的加锁、解锁操做链接在一块儿,扩展成一个范围更大的锁。
若是一系列的连续加锁解锁操做,可能会致使没必要要的性能损耗,因此引入锁粗化的概念。
偏向锁:在无多线程竞争的状况下尽可能减小没必要要的轻量级锁执行路径。
比轻量级锁,减小CAS执行次数。只须要检查是否为偏向锁、锁标识为以及ThreadID便可
检测Mark Word是否为可偏向状态,
测试线程ID是否为当前线程ID,
不是当前线程ID,则经过CAS操做竞争锁,竞争成功,则将Mark Word的线程ID替换为当前线程ID
经过CAS竞争锁失败,证实当前存在多线程竞争状况,当到达全局安全点,得到偏向锁的线程被挂起,偏向锁升级为轻量级锁,而后被阻塞在安全点的线程继续往下执行同步代码块;
执行同步代码块。
轻量级锁:减小传统的重量级锁使用操做系统互斥量产生的性能消耗。
当关闭偏向锁功能或者多个线程竞争偏向锁致使偏向锁升级为轻量级锁,则会尝试获取轻量级锁
比偏向锁多的:
在线程中增长锁记录(Lock Record),用于存储锁对象目前的Mark Word的拷贝,
利用CAS操做尝试将对象的Mark Word更新为指向Lock Record的指正,若是成功表示竞争到锁,则将锁标志位变成00
判断当前对象的Mark Word是否指向当前线程的栈帧,若是是则表示当前线程已经持有当前对象的锁,则直接执行同步代码块;
不然只能说明该锁对象已经被其余线程抢占了,这时轻量级锁须要膨胀为重量级锁,锁标志位变成10,后面等待的线程将会进入阻塞状态;
重量级锁:经过Monitor实现
-------------------------------------------------------------
自旋锁
线程的阻塞和唤醒须要CPU从用户态转为核心态,频繁的阻塞和唤醒对CPU来讲是一件负担很重的工做,势必会给系统的并发性能带来很大的压力。同时咱们发如今许多应用上面,对象锁的锁状态只会持续很短一段时间,为了这一段很短的时间频繁地阻塞和唤醒线程是很是不值得的。
因此引入自旋锁。
何谓自旋锁?
所谓自旋锁,就是让该线程等待一段时间,不会被当即挂起,看持有锁的线程是否会很快释放锁。
怎么等待呢?
执行一段无心义的循环便可(自旋)。
自旋等待不能替代阻塞,先不说对处理器数量的要求(多核,貌似如今没有单核的处理器了),虽然它能够避免线程切换带来的开销,可是它占用了处理器的时间。若是持有锁的线程很快就释放了锁,那么自旋的效率就很是好;反之,自旋的线程就会白白消耗掉处理的资源,它不会作任何有意义的工做,典型的占着茅坑不拉屎,这样反而会带来性能上的浪费。
因此说,自旋等待的时间(自旋的次数)必需要有一个限度,若是自旋超过了定义的时间仍然没有获取到锁,则应该被挂起。自旋锁在JDK 1.4.2中引入,默认关闭,可是可使用-XX:+UseSpinning开开启,在JDK1.6中默认开启。同时自旋的默认次数为10次,能够经过参数-XX:PreBlockSpin来调整。
若是经过参数-XX:preBlockSpin来调整自旋锁的自旋次数,会带来诸多不便。假如我将参数调整为10,可是系统不少线程都是等你刚刚退出的时候就释放了锁(假如你多自旋一两次就能够获取锁),你是否是很尴尬?因而JDK1.6引入自适应的自旋锁,让虚拟机会变得愈来愈聪明。
适应自旋锁
JDK 1.6引入了更加聪明的自旋锁,即自适应自旋锁。所谓自适应就意味着自旋的次数再也不是固定的,它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。
它怎么作呢?
线程若是自旋成功了,那么下次自旋的次数会更加多,由于虚拟机认为既然上次成功了,那么这次自旋也颇有可能会再次成功,那么它就会容许自旋等待持续的次数更多。反之,若是对于某个锁,不多有自旋可以成功的,那么在之后要或者这个锁的时候自旋的次数会减小甚至省略掉自旋过程,以避免浪费处理器资源。有了自适应自旋锁,随着程序运行和性能监控信息的不断完善,虚拟机对程序锁的情况预测会愈来愈准确,虚拟机会变得愈来愈聪明。
锁消除
为了保证数据的完整性,咱们在进行操做时须要对这部分操做进行同步控制,可是在有些状况下,JVM检测到不可能存在共享数据竞争,这是JVM会对这些同步锁进行锁消除。锁消除的依据是逃逸分析的数据支持。
若是不存在竞争,为何还须要加锁呢?
因此锁消除能够节省毫无心义的请求锁的时间。变量是否逃逸,对于虚拟机来讲须要使用数据流分析来肯定,可是对于咱们程序员来讲这还不清楚么?咱们会在明明知道不存在数据竞争的代码块前加上同步吗?可是有时候程序并非咱们所想的那样?
咱们虽然没有显示使用锁,可是咱们在使用一些JDK的内置API时,如StringBuffer、Vector、HashTable等,这个时候会存在隐形的加锁操做。
好比StringBuffer的append()方法,Vector的add()方法:
public void vectorTest(){
Vector<String> vector = new Vector<String>();
for(int i = 0 ; i < 10 ; i++){
vector.add(i + "");
}
System.out.println(vector);
}
在运行这段代码时,JVM能够明显检测到变量vector没有逃逸出方法vectorTest()以外,因此JVM能够大胆地将vector内部的加锁操做消除。
锁粗化
咱们知道在使用同步锁的时候,须要让同步块的做用范围尽量小,仅在共享数据的实际做用域中才进行同步。这样作的目的是为了使须要同步的操做数量尽量缩小,若是存在锁竞争,那么等待锁的线程也能尽快拿到锁。
在大多数的状况下,上述观点是正确的,LZ也一直坚持着这个观点。可是若是一系列的连续加锁解锁操做,可能会致使没必要要的性能损耗,因此引入锁粗化的概念。
那什么是锁粗化?
就是将多个连续的加锁、解锁操做链接在一块儿,扩展成一个范围更大的锁。
如上面实例:vector每次add的时候都须要加锁操做,JVM检测到对同一个对象(vector)连续加锁、解锁操做,会合并一个更大范围的加锁、解锁操做,即加锁解锁操做会移到for循环以外。
轻量级锁
引入轻量级锁的主要目的是在多没有多线程竞争的前提下,减小传统的重量级锁使用操做系统互斥量产生的性能消耗。
当关闭偏向锁功能或者多个线程竞争偏向锁致使偏向锁升级为轻量级锁,则会尝试获取轻量级锁,其步骤以下:获取锁。
判断当前对象是否处于无锁状态(hashcode、0、01),如果,则JVM首先将在当前线程的栈帧中创建一个名为锁记录(Lock Record)的空间,用于存储锁对象目前的Mark Word的拷贝(官方把这份拷贝加了一个Displaced前缀,即Displaced Mark Word);不然执行步骤(3);
JVM利用CAS操做尝试将对象的Mark Word更新为指向Lock Record的指正,若是成功表示竞争到锁,则将锁标志位变成00(表示此对象处于轻量级锁状态),执行同步操做;若是失败则执行步骤(3);
判断当前对象的Mark Word是否指向当前线程的栈帧,若是是则表示当前线程已经持有当前对象的锁,则直接执行同步代码块;不然只能说明该锁对象已经被其余线程抢占了,这时轻量级锁须要膨胀为重量级锁,锁标志位变成10,后面等待的线程将会进入阻塞状态;
释放锁轻量级锁的释放也是经过CAS操做来进行的,主要步骤以下:
取出在获取轻量级锁保存在Displaced Mark Word中的数据;
用CAS操做将取出的数据替换当前对象的Mark Word中,若是成功,则说明释放锁成功,不然执行(3);
若是CAS操做替换失败,说明有其余线程尝试获取该锁,则须要在释放锁的同时须要唤醒被挂起的线程。
对于轻量级锁,其性能提高的依据是“对于绝大部分的锁,在整个生命周期内都是不会存在竞争的”,若是打破这个依据则除了互斥的开销外,还有额外的CAS操做,所以在有多线程竞争的状况下,轻量级锁比重量级锁更慢;
偏向锁
引入偏向锁主要目的是:为了在无多线程竞争的状况下尽可能减小没必要要的轻量级锁执行路径。上面提到了轻量级锁的加锁解锁操做是须要依赖屡次CAS原子指令的。那么偏向锁是如何来减小没必要要的CAS操做呢?咱们能够查看Mark work的结构就明白了。
只须要检查是否为偏向锁、锁标识为以及ThreadID便可,处理流程以下:获取锁。
检测Mark Word是否为可偏向状态,便是否为偏向锁1,锁标识位为01;
若为可偏向状态,则测试线程ID是否为当前线程ID,若是是,则执行步骤(5),不然执行步骤(3);
若是线程ID不为当前线程ID,则经过CAS操做竞争锁,竞争成功,则将Mark Word的线程ID替换为当前线程ID,不然执行线程(4);
经过CAS竞争锁失败,证实当前存在多线程竞争状况,当到达全局安全点,得到偏向锁的线程被挂起,偏向锁升级为轻量级锁,而后被阻塞在安全点的线程继续往下执行同步代码块;
执行同步代码块。
释放锁偏向锁的释放采用了一种只有竞争才会释放锁的机制,线程是不会主动去释放偏向锁,须要等待其余线程来竞争。偏向锁的撤销须要等待全局安全点(这个时间点是上没有正在执行的代码)。
其步骤以下:
暂停拥有偏向锁的线程,判断锁对象石是否还处于被锁定状态;
撤销偏向苏,恢复到无锁状态(01)或者轻量级锁的状态。
重量级锁
重量级锁经过对象内部的监视器(monitor)实现,其中monitor的本质是依赖于底层操做系统的Mutex Lock实现,操做系统实现线程之间的切换须要从用户态到内核态的切换,切换成本很是高。
https://mp.weixin.qq.com/s/wHz0uL_LEe4OgLsSFGEZEg
四种自旋转的特色和实现
https://mp.weixin.qq.com/s/WzO6DbVH6EApryGFC23aZA
java 几种锁机制
(偏向锁,轻量级锁,重量级锁,自旋锁)
http://blog.csdn.net/u014470581/article/details/53559100
synchronized & 偏向锁 & 轻量级锁 & 重量级锁 & 各自优缺点及场景 & AtomicReference
http://www.cnblogs.com/charlesblc/p/5994162.html