上一篇 <<<锁的深入化
下一篇 >>>Java内存模型(JMM)
锁的升级顺序：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态。
锁可以从偏向锁升级到重量级锁，是单向的，不会出现锁的降级。
用户态和内核态
内核态（Kernel Mode）：运行操作系统程序，操作硬件 读取io流、
用户态（User Mode）：运行用户程序
偏向锁
- 定义：从始至终只有一个线程在请求锁和释放锁
- 偏向线程： 占用锁的线程
- 好处： 偏向锁适合于只有一个线程重复获取锁的时候，没有任何的竞争，从而提高锁的效率。
原理/实现过程：
a、当获取到锁的时候
--对象头的偏向模式设置为“1”、偏向锁标志位设置01，进入偏向模式。
--对象的栈桢中记录偏向锁的线程ID（也就是mark word中）
b、下次获取锁的时候，判断偏向锁ID和当前线程一致，则直接进入代码块执行，减少CAS的操作，也就是减少CPU用户态和内核态的切换
--如果为0（表示线程还不是偏向锁，是无锁状态）；采用CAS操作将偏向锁字段设置为1；并且更新自己的线程ID到mark word 字段中；
--如果为1且不是当前线程，表示此时偏向锁已经被别的线程获取；则此时线程不断尝试使用CAS获取偏向锁；或者将偏向锁撤销，升级成轻量级锁； （升级概率较大）
如何开启偏向锁:
jdk5中默认关闭，jdk6之后默认开启，但在应用程序启动几秒钟之后才激活可以使用-XX:BiasedLockingStartupDelay=0参数关闭延迟
如果确定应用程序中所有锁通常情况下处于竞争状态，可以通过
-XX:-UseBiasedLocking=false参数关闭偏向锁
偏向锁撤销场景：
a、有其他线程来竞争的时候才会释放偏向锁
b、偏向锁的撤销必须等待全局安全的点
c、将对象头中的标记01恢复为00
d、hash计算
轻量级锁
- 应用场景： 当多个线程在间隔的方式竞争我们的锁对象，短暂结合自旋控制。
锁的获取:
(1). 判断当前对象是否处于无锁状态（hashcode、0、01），若是，则JVM首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝（官方把这份拷贝加了一个Displaced前缀，即Displaced Mark Word）；否则执行步骤（3）；
(2). JVM利用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，如果成功表示竞争到锁，则将锁标志位变成00（表示此对象处于轻量级锁状态），执行同步操作；如果失败则执行步骤（3）；
(3). 判断当前对象的Mark Word是否指向当前线程的栈帧，如果是则表示当前线程已经持有当前对象的锁，则直接执行同步代码块；否则只能说明该锁对象已经被其他线程抢占了，这时轻量级锁需要膨胀为重量级锁，锁标志位变成10，后面等待的线程将会进入阻塞状态；
锁的释放
(1). 取出在获取轻量级锁保存在Displaced Mark Word中的数据；
(2). 用CAS操作将取出的数据替换当前对象的Mark Word中，如果成功，则说明释放锁成功，否则执行（3）；
(3). 如果CAS操作替换失败，说明有其他线程尝试获取该锁，则需要在释放锁的同时需要唤醒被挂起的线程。
重量级锁
没有获取到锁的线程会变为阻塞的状态，效率极低
线程的竞争不会使用自旋，不会消耗cpu资源，适合于同步代码执行比较长的时间。
偏向锁、轻量级锁和重量级锁区别与转换
a.偏向锁：加锁和解锁不需要额外的开销，只适合于同一个线程访问同步代码块，如果多个线程同时竞争的时候，会撤销该锁。
b.轻量级锁：竞争的线程不会阻塞，提高了程序响应速度，如果始终得不到锁的竞争线程，则使用自旋的形式，消耗cpu资源，适合于同步代码块执行非常快的情况下。
c.重量级锁： 线程的竞争不会使用自旋，不会消耗cpu资源，适合于同步代码执行比较长的时间。
锁之间的转换
锁的优缺点汇总
总结一下，其实无锁->偏向锁->轻量级锁->重量级锁的转化过程中没那么复杂，注意记住：
（1）只有一个线程获取锁时，就是偏向锁。
（2）多个线程时，不存在竞争（多个线程顺序执行），轻量级锁。
（3）多个线程存在竞争时重量级锁。
代码示例
64位虚拟机mark word图示
[markOop.hpp文件]
enum { locked_value = 0, // 0 00 轻量级锁
unlocked_value = 1,// 0 01 无锁
monitor_value = 2,// 0 10 重量级锁
marked_value = 3,// 0 11 gc标志
biased_lock_pattern = 5 // 1 01 偏向锁
};
tips：对象的布局情况请参考Java基础-对象布局
锁的消除
锁削除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行削除。锁削除的主要判定依据来源于逃逸分析的数据支持，如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行。
/**
* StringBuffer的append方法每个都含有synchronized关键字，而且都是this锁
* 每个线程都有自己独立锁，等于是没锁
* @param args
*/
public static void main(String[] args) {
andString("jarye", "xiaowang", "xiaohong");
}
public static String andString(String s1, String s2, String s3) {
return new StringBuffer().append(s1).append(s2).append(s3).toString();
}
锁的粗化/合并
通常情况下，为了保证多线程间的有效并发，会要求每个线程持有锁的时间尽可能短，但是大某些情况下，一个程序对同一个锁不间断、高频地请求、同步与释放，会消耗掉一定的系统资源，因为锁的讲求、同步与释放本身会带来性能损耗，这样高频的锁请求就反而不利于系统性能的优化了，虽然单次同步操作的时间可能很短。
锁粗化就是告诉我们任何事情都有个度，有些情况下我们反而希望把很多次锁的请求合并成一个请求，以降低短时间内大量锁请求、同步、释放带来的性能损耗。
/**
* StringBuffer的append方法每个都含有synchronized关键字
* 在执行的时候，会合并在for之前加锁，之后释放锁
* @param args
*/
public static void main(String[] args) {
StringBuffer sf = new StringBuffer();
for(int i=0;i<10;i++){
sf.append(i);
}
}
Synchronized优化方案
a.减少Synchronized同步的范围，只会使用偏向锁或者轻量锁
b.类似Conhashmap底层实现分段锁原理 降低锁的粒度
c.锁一定要做做读写分离
相关文章链接：
多线程基础
线程安全与解决方案
锁的深入化
Java内存模型(JMM)
Volatile解决JMM的可见性问题
Volatile的伪共享和重排序
CAS无锁模式及ABA问题
Synchronized锁
Lock锁
AQS同步器
Condition
CountDownLatch同步计数器
Semaphore信号量
CyclicBarrier屏障
线程池
并发队列
Callable与Future模式
Fork/Join框架
Threadlocal
Disruptor框架
如何优化多线程总结
网友评论