本文主要是介绍JavaEE之锁策略,cas 和 synchronized 优化过程深入浅出，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
题外话
正题
锁策略
乐观锁和悲观锁
轻量锁和重量锁
CAS算法(Compare And Swap)
自旋锁和挂起等待锁
普通互斥锁和读写锁
公平锁和非公平锁
可重入锁和不可重入锁
synchronized原理
基本特点
锁升级
其它锁优化
锁消除
锁粗化
小结
题外话
时间紧任务重,直接开始讲解,今天内容大都是概念内容
正题
锁策略
乐观锁和悲观锁
乐观锁:乐观锁会认为锁竞争不是很激烈,做的准备工作比较少,开销更小(时间开销,系统资源开销),效率更高一些
悲观锁:悲观锁会认为锁竞争很激烈,做的准备工作比较多,开销更大(时间开销,系统资源开销),效率更低一些
具体使用哪种锁要看实际情况,应用场景
乐观锁一般用在线程竞争一个锁冲突比较少的情况
悲观锁恰恰相反,一般用在线程竞争一个锁冲突比较多的情况
轻量锁和重量锁
轻量锁:开销比较小的锁,需要在用户态中完成,加锁机制一般依赖CAS算法实现
重量锁:开销比较大的锁,需要在内核态中完成, 加锁机制重度依赖了OS提供了mutex
CAS算法(Compare And Swap)
CAS算法是一种无锁算法
无锁算法:基于硬件原语实现,在不使用锁(没有线程被阻塞)的情况下实现多线程之间的变量同步
算法涉及到三个操作数:
需要读写的内存值V
进行比较的值A
要写入的新值B
返回值为boolean类型
算法执行步骤
A和V先比较是否相等(比较)
如果相等,把B写入V(交换)
相等返回true,不相等返回false
自旋锁和挂起等待锁
自旋锁:当线程获取不到锁的时候,不会放弃CPU,会频繁的循环尝试去获取锁,会造成CPU的资源浪费,当锁释放的时候,可以第一时间获取锁, synchronized中的轻量级锁策略⼤概率就是通过⾃旋锁的方式实现的.
挂起等待锁:当线程获取不到锁的时候,会进行堵塞等待,放弃CPU,进入等待队列中,等到锁释放的时候再让系统调度
举个例子
先说自旋锁
挂起等待锁
希望以上例子能帮助大家更好的理解,自旋锁和挂起等待锁
普通互斥锁和读写锁
普通互斥锁:在Java中,只有加锁和解锁两个操作的锁,就是普通互斥锁,如synchronized
读写锁:多线程之间，数据的读取⽅之间不会产⽣线程安全问题，但数据的写入方互相之间以及和读者之间都 需要进行互斥。如果两种场景下都⽤同⼀个锁，就会产⽣极⼤的性能损耗。所以读写锁因此⽽产⽣。
读锁和读锁之间不会产生互斥
写锁和写锁之间会产生互斥
写锁和读锁之间会产生互斥
synchronized不是读写锁
公平锁和非公平锁
公平锁:当多个线程获取锁的时候,会根据先来后到的原则,当锁被释放的时候,最先等待的线程会获取到锁,公平锁需要记录线程先来后到,需要额外的数据结构
非公平锁:当多个线程获取锁的时候,不会根据先来后到的原则,而是根据机会均等的原则,当锁被释放的时候,每个线程都有机会获取到锁
synchronized是非公平锁
举个例子:当厕所里有人占用,有很多人排队,而你比其他人来的都早,等厕所里面的人出来,你就可以占用厕所,这就是公平锁
当厕所里有人占用,但是这个厕所不能排队,一群人在门口等待,每个人占用厕所的几率是均等的,哪怕你来的很早,也不一定能轮到你
可重入锁和不可重入锁
可重入锁:允许一个线程多次获取同一把锁
⽐如⼀个递归函数⾥有加锁操作，递归过程中这个锁会阻塞自己吗？如果不会，那么这个锁就是可重入锁（因为这个原因可重⼊锁也叫做递归锁）。
不可重入锁:不允许一个线程多次获取同一把锁
Java⾥只要以Reentrant开头命名的锁都是可重⼊锁，⽽且JDK提供的所有现成的Lock实现类，包括 synchronized关键字锁都是可重⼊的。
synchronized原理
基本特点
结合上⾯的锁策略,我们就可以总结出,synchronized具有以下特性(只考虑JDK1.8):
1. 开始时是乐观锁,如果锁冲突频繁,就转换为悲观锁.
2. 开始是轻量级锁实现,如果锁被持有的时间较⻓,就转换成重量级锁.
3. 实现轻量级锁的时候⼤概率⽤到的⾃旋锁策略
4. 是⼀种不公平锁
5. 是⼀种可重⼊锁
6. 不是读写锁
锁升级
JVM将synchronized锁分为⽆锁、偏向锁、轻量级锁、重量级锁状态。会根据情况，进⾏依次升 级。
无锁:代码中没有加锁
偏向锁:第一个尝试加锁的进程,会进入"偏向锁"的状态,偏向锁不是真的加锁,而是给对象头中做⼀个"偏向锁的标记"
偏向锁本质上相当于"延迟加锁".能不加锁就不加锁,尽量来避免不必要的加锁开销. 但是该做的标记还是得做的,否则⽆法区分何时需要真正加锁.
轻量级锁:随着其他线程进入竞争，偏向锁状态被消除，进入轻量级锁状态(自适应的自旋锁).
此处的轻量级锁就是通过CAS来实现.
●通过CAS检查并更新一块内存(比如null =>该线程引用)
如果更新成功,则认为加锁成功
●如果更新失败, 则认为锁被占用，继续自旋式的等待(并不放弃CPU).
自旋操作是一直让CPU空转，比较浪费CPU资源.
因此此处的自旋不会一直持续进行， 而是达到一定的时间/重 试次数,就不再自旋了.
也就是所谓的"自适应"
重量级锁:如果竞争进一步激烈,自旋不能快速获取到锁状态，就会膨胀为重量级锁
此处的重量级锁就是指用到内核提供的mutex.
●执行加锁操作,先进入内核态.在内核态判定当前锁是否已经被占用
●如果该锁没有占用，则加锁成功，并切换回用户态.
●如果该锁被占用，则加锁失败.此时线程进入锁的等待队列，挂起.等待被操作系统唤醒.
●经历了一系列的沧海桑田，这个锁被其他线程释放了,操作系统也想起了这个挂起的线程，于是唤醒这个线程,尝试重新获取锁.
其它锁优化
锁消除
编译器+JVM判断锁是否可消除.如果可以,就直接消除
什么是"锁消除"有些应用程序的代码中,用到了synchronized,但其实没有在多线程环境下.
在单线程情况下,加锁没有必要,而且会浪费资源开销
锁粗化
⼀段逻辑中如果出现多次加锁解锁,编译器+JVM会自动进行锁的粗化
锁粗化就是多个连续加锁,解锁的操作放在一起,这样会使锁的粒度越粗,否则锁的粒度就越细
小结
以上就是本篇博客所有内容
喜欢的麻烦给个三连(点赞关注收藏!!!)
这篇关于JavaEE之锁策略,cas 和 synchronized 优化过程深入浅出的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
