Java并发：偏向锁、轻量级锁、重量级锁

锁的状态

锁的状态一共有四种：无锁、偏向锁、轻量级锁、重量级锁

锁的状态保存在对象的头文件中，以32位JDK为例：

锁状态	25 bit			4bit	1bit	2bit
	23bit		2bit		是否是偏向锁	锁标志位
轻量级锁	指向栈中锁记录的指针					00
重量级锁	指向互斥量（重量级锁）的指针					10
GC标记	空					11
偏向锁	线程ID	Epoch		对象分代年龄	1	01
无锁	对象的hashCode			对象分代年龄	0	01

锁的初始为无所状态，随着锁的竞争，锁的升级过程为: 偏向锁 ---> 轻量级锁--->重量级锁，锁的升级是单向的，不会出现锁的降级

锁升级过程

（初始：无锁状态）

场景一、线程#1 获取偏向锁 

    1. 线程#1 访问同步块

    2. 当前对象头，锁标志位：01，是否是偏向锁：0

    3. CAS更新Mark Word，设置偏向锁标志位1，设置线程ID为线程#1的ID

线程#1成功获取偏向锁，偏向锁获取成功后，线程不会主动释放，即使线程执行完毕

场景二、线程#1拥有偏向锁

    1. 线程#1 又要访问同步块

    2. 判断锁标志位为01，是偏向锁，判断线程ID是线程#1的ID

    3. 执行同步代码

场景三、线程#2 竞争偏向锁

    1. 发现当前对象头是偏向锁

    2. 判断线程ID是否为线程#2的ID：否

    3. 判断线程#1是否还存在，不存在--->场景四，存在--->场景五

场景四、线程#2 竞争偏向锁，线程#1 不存在，线程#2 获取偏向锁

    1. 设置偏向锁标志位为0

    2. 类似场景一，线程#2 获取偏向锁

场景五、线程#2 竞争偏向锁，线程#1 存在，偏向锁升级为轻量级锁

    1.  到达全局安全点（在这个时间点上没有字节码正在执行），线程#1挂起

    2. 设置锁标志位为00，将线程#1 的mark word复制到线程栈的lock record中，更新mark word，将mark word指向线程#1中monitor record的指针 (升级为轻量级锁)

    3. 继续执行线程#1 的代码

    4. 线程#2 自旋获取锁对象

场景六、线程#3竞争轻量级锁

    1. 拷贝对象头的mark word到线程栈的lock record中

    2. CAS操作将mark word更新为指向lock record的指针，并将Lock record里的owner指针指向object mark word，成功--->3，失败--->4

    3. 更新成功，线程#3则获取到了锁

    4. 更新失败，检查对象的mark word是否指向当前线程的栈帧，如果是则说明已经拥有该对象锁，直接进入同步快执行。否则轻量级锁膨胀为重量级锁，mark word中存储的是指向重量级锁（互斥量）的指针

轻量级锁CAS操作之前堆栈与对象的状态

轻量级锁CAS操作之后堆栈与对象的状态

重量级锁、轻量级锁和偏向锁之间的转换

总结

锁	优点	缺点	适用场景
偏向锁	加锁和解锁不需要额外的消耗，和执行非同步方法比仅存在纳秒级的差距。	如果线程间存在锁竞争，会带来额外的锁撤销的消耗。	只有一个线程执行同步块
轻量级锁	竞争的线程不会阻塞，提高了程序的响应速度。	如果始终得不到锁竞争的线程使用自旋会消耗CPU。	线程交替执行同步块 追求响应时间。 同步块执行速度非常快。
重量级锁	线程竞争不使用自旋，不会消耗CPU。	线程阻塞，响应时间缓慢。	追求吞吐量。 同步块执行速度较长。

参考文章：http://www.cnblogs.com/paddix/p/5405678.html