网站制作厦门公司,免费简单网站,网站建设高等教育出版社,网站邮箱登陆代码目录
一、常见的锁策略
1乐观锁VS悲观锁
1.1乐观锁
1.2悲观锁
2.轻量级锁VS重量级锁
2.1轻量级锁
2.2重量级锁
3.自旋锁VS挂起等待锁
3.1自旋锁
3.2挂起等待锁
4.互斥锁VS读写锁
4.1互斥锁
4.2读写锁
5.公平锁VS非公平锁
5.1公平锁
5.2非公平锁
6.可重入锁VS不…目录
一、常见的锁策略
1乐观锁VS悲观锁
1.1乐观锁
1.2悲观锁
2.轻量级锁VS重量级锁
2.1轻量级锁
2.2重量级锁
3.自旋锁VS挂起等待锁
3.1自旋锁
3.2挂起等待锁
4.互斥锁VS读写锁
4.1互斥锁
4.2读写锁
5.公平锁VS非公平锁
5.1公平锁
5.2非公平锁
6.可重入锁VS不可重入锁
6.1可重入锁
6.2不可重入锁
7.关于synchronized
二、CAS
1.CAS涉及的下操作
2.CAS的应用场景
2.1实现原子类
伪代码编辑
2.2实现自旋锁
伪代码
3.CAS中的ABA问题
三、Synchronized原理
1.锁升级/锁膨胀
1.1无锁
1.2偏向锁
1.3轻量级锁
1.4重量级锁
2.锁消除
3.锁粗化 一、常见的锁策略
接下来进行学习的内容不仅仅局限于java任何和“锁”相关的话题都会涉及到。
1乐观锁VS悲观锁
站在锁冲突概率的预测角度
1.1乐观锁
假设数据一般情况下不会产生并发冲突所以在数据进行提交更新的时候才会正式对数据是否产生并发冲突进行检测如果发现并发冲突了则让返回用户错误信息让用户决定如何去做。
1.2悲观锁
总是假设最坏的情况每次去拿数据的时候都认为别人会修改所以每次在拿数据的时候都会上锁这样别人想拿这个数据就会阻塞直到它拿到锁。
2.轻量级锁VS重量级锁
2.1轻量级锁
加锁解锁开销较小效率更高
2.2重量级锁
开锁解锁开销较大效率更低
站在加锁操作的开销角度
3.自旋锁VS挂起等待锁
3.1自旋锁
典型的轻量级锁更大几率获取到锁加锁速度快
3.2挂起等待锁
典型的重量级锁“傻等”被动的等待省下来CPU去做别的工作加锁的时间比较长。
4.互斥锁VS读写锁
4.1互斥锁
互斥锁就是前面用过的像synchronized这样的锁提供加锁和解锁两个操作。如果一个线程加锁了另一个线程也尝试加锁就会阻塞等待。
4.2读写锁
提供三种操作1针对读加锁。2针对写加锁。3解锁
基于一个事实多线程针对同一个变量并发读这个时候是没有线程安全问题的也不需要加锁控制。读写锁就是针对这种情况采取的特殊的处理
读锁和读锁之间没有互斥。写锁和写锁之间存在互斥。写锁和读锁之间存在互斥。当前代码中如果只是读操作加读锁即可如果有写操作加写锁。
5.公平锁VS非公平锁
5.1公平锁
这里的公平定义为先来后到。B比C先来的当A释放锁后B就能先于C获取到锁。
5.2非公平锁
不遵守先来后到B和C都有可能获取到锁。
OS内部的线程调度就可视为是随机的如果不做任何额外的限制锁就是非公平的如果要想实现公平锁就需要额外的数据结构来记录线程们的先后顺序。
公平锁和非公平锁之间没有好坏之分关键还得看适用场景。
6.可重入锁VS不可重入锁
6.1可重入锁
一个线程针对一把锁连续加锁多次不会死锁。
6.2不可重入锁
一个线程针对一把锁连续加锁两次出现死锁。
7.关于synchronized
1synchronized既是一个悲观锁也是一个乐观锁
synchronized默认是乐观锁但是如果发现当前锁竞争比较激烈就会变成悲观锁。
2synchronized既是轻量级锁也是重量级锁。
synchronized默认是轻量级锁如果发现当前锁竞争比较激烈的话就会变成重量级锁。
3synchronizaed这里的轻量级锁是基于自旋锁的方式实现的。synchronized这里的重量级锁是基于挂起等待锁的方式实现的。
4synchronized不是读写锁。
5synchronized是非公平锁。
6synchrnized是可重入锁。
上述谈到的六种锁策略可以视为是“锁的形容词”
二、CAS
全称Compare and swap 比较和交换
1.CAS涉及的下操作
我们设内存中的原始数据V旧的预期值A需要修改的新值B
1.比较A与的V值是否相等比较
2.如果比较相等。将B写入V交换
3.返回操作是否成功
此处特别的是上述的CAS的过程并不是通过一段代码实现的而是通过一条CPU指令完成的。也就是说CAS操作是原子的就可以在一定程度上回避线程安全问题所以说我们解决线程安全问题除了加锁之外就又有了一个新的方向。
CAS可以理解为是CPU给咱们提供的一个特殊的指令通过这个指令就可在一定程度上处理线程安全问题。
2.CAS的应用场景
2.1实现原子类
JAVA标准库中提供的类
AtomicInteger count new AtomicInteger(0);
伪代码
使用原子类来解决线程安全问题代码实现
创建两个线程t1和t2,在前面的学习中当两个线程不加锁的时候就会出现bug所以采用了加锁策略这里使用原子类来实现不需要加锁也可以达到预期的效果
public class ThreadD28 {public static void main(String[] args) throws InterruptedException {AtomicInteger count new AtomicInteger(0);//使用原子类来解决线程安全问题Thread t1 new Thread(() -{for (int i 0; i 50000; i) {//因为java不支持运算符重载所以只能使用普通方法来表示自增自减count.getAndIncrement();}});Thread t2 new Thread(() -{for (int i 0; i 50000; i) {count.getAndIncrement();}});t1.start();t2.start();t1.join();t2.join();System.out.println(count.get());}
}
运行结果 2.2实现自旋锁
伪代码 3.CAS中的ABA问题
CAS在运行中的核心检查value和oldValue是否一致如果一致就视为value没有被修改过所以进行下一步的交换操作是没问题的。但是需要注意的是这里的一致可能是改过但是还原回来的。【买手机可能是新机也有可能是翻新机被销售商回收了经过一些翻新的操作将外壳换掉重新包装】
下面看一个取钱的例子概率极低 以上情况发生的概率极低但是这种问题一旦出现的话就是容易解决的提前防患于未然是更好的选择。针对当前的问题采取的方案就是加上一个版本号。想象成初始的版本号是1每次修改的版本号都1然后进行CAS的时候就不是以金额为准了而是以版本号为基准此时版本号要是没变就一定没发生改变版本号只能增长不能降低
三、Synchronized原理
两个线程针对同一个对象加锁就会产生阻塞等待。
synchronized内部还有一些优化机制存在的目的是了让这个锁更高效更好用。
1.锁升级/锁膨胀
1.1无锁
1.2偏向锁
在进行加锁的时候首先要进入到偏向锁的状态。偏向锁并不是真正的加锁而是占个位置有需要才会进行加锁没需要就不必加。相当于“懒汉模式”中提到的懒加载一样。偏向锁的状态做个标记这个过程是非常轻量的如果使用锁的过程中没有出现锁竞争在synchronized执行完之后解除偏向锁即可但是如果使用过程中另一个线程也尝试加锁这个时候就会迅速的将偏向锁升级称为真正的加锁状态另外的一个线程也只能阻塞等待了。
1.3轻量级锁
当synchronized发生锁竞争的时候就会从偏向锁升级为轻量级锁此时synchronized相当于通过自旋的方式来进行加锁的就类似于上述的CAS中的伪代码
1.4重量级锁
如果要是很快别人就释放了锁自旋还是划算的但是如果迟迟拿不到锁一直自旋是不划算的synchronized自旋不是无休止的自旋到一定程度就会在再次升级成为重量级锁挂起等待锁。这个锁则是基于操作系统的原生API来进行加锁的linux原生提供了mutex一组API操作系统内核提供的加锁功能这个锁会影响到线程的调度。此时如果线程进行了重量级的加锁并且发生了锁竞争此时线程会被放在阻塞队列中不参与CPU的调度。然后直到锁被释放这个线程才有机会被调度到并且有机会获取到锁。
2.锁消除
编译器智能的判定看当前代码是否真的要加锁如果这个场景不需要加锁程序员加了就会自动的把锁消除。
例如StringBuffer关键的方法有synchronized但是如果在单线程中使用StringBuffersynchronized加了也白加此时编译器就会直接将加锁操作消除。
3.锁粗化
锁的粒度synchronized包含的代码越多粒度就越粗包含的代码越少粒度就越细。
一般情况下认为锁的粒度细一点是比较好的加锁部分的代码是不能并发执行的锁的粒度越细能并发的代码就越多反之则越少。但是有些情况下锁的粒度粗一些就更好。
十一弹的续集会进行更新这一部分中在面试中的高频考点~
