目录
前言:
常见锁策略
CAS
CAS应用场景
标准库中基于CAS实现的原子类介绍
代码实现
ABA问题
Synchronized原理
锁升级
锁消除
锁粗化
小结:
前言:
通过这篇文章可以更加深入理解锁内部的一些实现原理,以及怎样描述一把锁。还有典型的CAS问题。
常见锁策略
通过一些锁实现的策略,就可以描述一把具体的锁。
1)乐观锁 vs 悲观锁
乐观锁:预测锁竞争不是很激烈,做的工作少。
悲观锁:预测锁竞争很激烈,做的工作多。
2)轻量级锁 vs 重量级锁
轻量级锁:加锁的开销比较小,效率高。
重量级锁:加锁的开销比较大,效率低。
- 多数情况下,乐观锁是轻量级锁(不完全保证)
- 多数情况下,悲观锁是重量级锁(不完全保证)
3)自旋锁 vs 挂起等待锁
自旋锁:始终监视锁的状态,第一时间就可以获得锁状态,加锁效率比较高(占用大量系统资源)。
挂起等待锁:被动的监视锁的状态,不能第一时间获得锁状态,加锁效率比较低(节省系统资源,可以做些别的事情)
- 自旋锁是典型的一种轻量级锁。
- 挂起等待锁是典型的一种重量级锁。
4)互斥锁 vs 读写锁
互斥锁:提供加锁和解锁两种功能。
读写锁:针对读和写操作区分对待,也可以释放锁。
- 读锁和读锁之间,不存在互斥。
- 读锁和写锁之间,存在互斥。
- 写锁和写锁之间,存在互斥。
5)公平锁 vs 非公平锁
公平锁:针对先来后到体现公平原则。阻塞时间久的线程先获得锁,以时间来排序。
非公平锁:没有先来后到的说法,一起竞争锁。
6)可重入锁 vs 不可重入锁
可重入锁:一个线程针对同一把锁,加锁多次不会产生锁竞争。
不可重入锁:一个线程针对同一把锁,加锁多次,会产生锁竞争,造成阻塞等待。
Synchronized对号入座
1)既是乐观锁也是悲观锁。默认是乐观锁,发现锁竞争比较激烈就会升级为悲观锁。
2)既是轻量级锁也是重量级锁。锁竞争不激烈就是轻量级锁,锁竞争激烈就是重量级锁。
3)当为轻量级锁就是自旋锁,当为重量级锁就是挂起等待锁。
4)是互斥锁。
5)是非公平锁。
6)是可重入锁。
CAS
CAS是一条cpu指令,CAS操作是原子的。比较且交换(cmopare and swap)
CAS应用场景
基于CAS这样一条cpu指令,可具体应用于一些特殊场景中,提升程序效率。
原子类
实现原子类:伪代码,实现加加操作
注意:这里只有当CAS判断相等,且交换成功后,while循环才会结束。这里就算第一个线程执行完load被切换走,当第二个线程在执行CAS(判断value和oldvalue相等,则把oldvalue + 1写入内存),修改了内存中的值。当第一个线程被切换回来时,发现oldvalue和value不相等,则重新读取value的值,然后再执行CAS(判断相等且交换,执行第二次加加操作)。这样就可以保证多线程情况下可以正常进行加加操作。
自旋锁
实现自旋锁(伪代码)
注意:while循环里,不断的执行CAS判断线程是否加锁。线程如果加锁就一直自旋等待,线程一旦释放锁后,立即就可以获得锁的状态。执行CAS获得当前线程的锁。
标准库中基于CAS实现的原子类介绍
Atomic系列:
这里介绍下AtomicInteger的使用,主要是实现多线程下安全的自增自减操作。
1)getAndIncrement()方法:后置加加
2)incrementAndGet()方法:前置加加
3)getAndDecrement()方法:后置减减
4)decrementAndGet()方法:前置减减
代码实现
public class ThreadDemo28 {
public static void main(String[] args) throws InterruptedException {
//原子类,基于CAS实现的原子类,提供了自增自减等操作。多线程下就是线程安全的
AtomicInteger count = new AtomicInteger(0);
Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
for(int i = 0; i < 5000; i++) {
count.getAndIncrement(); //count++
//count.incrementAndGet(); //++count
//count.getAndDecrement(); //count--
//count.decrementAndGet(); //--count
}
}
});
Thread t2 = new Thread(new Runnable() {
@Override
public void run() {
for(int i = 0; i < 5000; i++) {
count.getAndIncrement();
}
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(count.get());
}
}
注意:可以清楚看见运行结果是符合预期的。
ABA问题
CAS典型的ABA问题,就是当执行CAS判断的时候(看起来是没有变化),但是这个变量已经修改过了。
示例:
取钱问题。当使用CAS取钱的时候,假设余额有1000,CAS判断余额是否为1000,如果相等,则取500。如果机器卡顿这个人多按了几次,当执行第一次CAS取钱500,在这个瞬间又被转账了500,那么执行下一次CAS就会成功。出现了BUG。
改进方法:
增加版本号,每执行一次CAS版本号就加1,不使用余额判断而去使用版本号。当执行了第一次CAS版本号就改变,当执行第二次CAS发现版本号不一致,那么就不会执行了。也就不会出现BUG了。
Synchronized原理
锁升级
第一阶段:无锁
第二阶段:偏向锁
第三阶段:轻量级锁
第四阶段:重量级锁
1)首先是无锁状态。
2)当代码执行到需要加锁的时候,先设置个标志位(偏向锁)。然后继续执行加锁的这块代码,如果在这个期间没有出现锁竞争,那么当这块代码执行完就只需要清空标志位。如果在这个期间出现了锁竞争,立即就由偏向锁升级为轻量级锁,其他线程就只能阻塞等待了。
3)出现锁竞争由偏向锁升级为轻量级锁。
4)轻量级锁为自旋锁。如果这个时候要获取的锁对象,很长时间都不释放锁,那么就会一直自旋等待。直到一定的时间就会停止自旋(自旋需要消耗系统资源),升级为重量级锁,挂起等待锁。
锁消除
编译器会智能判定,当前代码是否需要加锁,如果不需要但是程序员加了,编译器就会取消这个加锁。
锁粗化
锁粒度:synchronized包含的代码越多锁粒度就越大,反之越小。
1)通常情况下锁粒度细一点比较好,因为加锁的代码无法并发执行,那么并发的代码越多程序效率就越高。
2)如果加锁开锁又加锁,这个期间时间间隔很短(几乎没有可以并发的代码),那么就可以考虑增大锁粒度(扩大范围),因为加锁开锁也是需要消耗系统资源的。
小结:
与大家共勉一句名言:少年不负岁月长,彼方尚有荣光在!