多线程进阶1 --- 锁策略+CAS+synchronized原理
目录
一，常见锁策略
二，CAS
2.1 什么是CAS
2.2 CAS 的应用
编辑
2.3 AtomiticInteger 的伪代码
2.3 ABA 问题
三，synchronized 原理
3.1 锁升级
3.2 锁消除
3.3 锁粗化
一，常见锁策略
此处的锁策略并非是某个具体的锁，而是 "锁的一种特性"
- 乐观锁：预测下面发生锁冲突的概率比较小，就可以少做一些工作(由具体场景和程序员的经验进行调整)，乐观锁通常是一种轻量级锁。
- 悲观锁：预测下面发生所冲突的概率很大，就要多做一些工作(由具体场景和程序员的经验进行调整)，悲观锁通常是一种重量级锁。
- 轻量级锁：锁的开销比较小(由实际消耗的开销决定)
- 重量级锁：锁的开销比较大(由实际消耗的开销决定)
- 自旋锁：轻量级锁的一种典型实现，比如使用一个 while 循环，不停的检查当前锁是否被释放，如果没释放，就继续循环，释放就获取到锁，就类似于定时器中的忙等。
- 挂起等待锁：重量级锁的一种典型实现，比如让这个线程进入阻塞的状态
- 读写锁：将读和写操作分别加锁，有三种情况：1. 读锁和读锁之间不会竞争 2. 读锁和写锁会竞争 3. 写锁和写锁之间会加锁
- 公平锁：当有多个线程去竞争一把锁的时候，这些线程按照 "先来后到" 的顺序去竞争锁
- 非公平锁：当有多个线程去竞争一把锁的时候，这些线程有 "相同的概率" 去竞争锁
二，CAS
2.1 什么是CAS
CAS 全称 Compare and swap，就是比较和交换，只不过比较交换的是 内存 和 寄存器，CAS本质上是一个CPU指令，也就是说该操作是原子的，可以用来代替加锁操作。类似于下面的伪代码：
//M 是 内存，A,B 是 寄存器
boolean CAS(M, A, B){
if(M == A){
M = B;
return true;
}
return false;
}
CAS是 cpu 提供的指令 ——》 被操作系统封装，提供 api ——》 被JVM封装，提供 api ——》可以被程序员使用。
2.2 CAS 的应用
就比如 ++ 操作，正常有三步，即 load， add， save。JAVA中提供了AtomicInteger 类，他的底层就是使用 CAS 来实现的，举个例子：
import java.util.concurrent.atomic.AtomicInteger;
public class Demo2 {
public static AtomicInteger cnt = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
for (int i = 0; i < 10000; i++) {
cnt.getAndIncrement();//后置++
//cnt.getAndDecrement();后置--
//cnt.decrementAndGet();前置--
//cnt.incrementAndGet();前置++
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 10000; i++) {
cnt.getAndIncrement();
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println("cnt = " + cnt.get());
}
}
2.3 AtomiticInteger 的伪代码
getAndIncrement()的伪代码：
class AtomicInteger {
private int value;
public int getAndIncrement() {
int oldValue = value;
while (!CAS(value, oldValue, oldValue+1)) {
oldValue = value;
}
return oldValue;
}
}画个图来理解一下为什么该操作不加锁也是线程安全的：
CAS 和 加锁 的思路是类似的，都是为了防止自增的时候穿插执行，只不过 CAS 是使用 while 循环来判断是否出现穿插执行，如果出现，直接++，以此来避免线程安全问题，而 加锁 是直接通过阻塞的方式来避免穿插。
2.3 ABA 问题
上面我们说 " CAS 使用 while 循环来判断是否出现穿插执行 "，这据话并不准确，比如当 t1 线程运行时穿插了另外两个线程，并且这两个线程所执行的操作是一增一减时，我们的 while 循环并不能判断出是否出现穿插执行。
当然在一般情况下，这不会影响到代码的正常运行，但如果在有关支付和收款时，这就会出现大问题，比如：A要给B转账1元，但是网络出了问题，于是他又进行转账操作，但是在这个时候C给A转了1元，最后A实际转了2元，画个图理解一下：
ABA问题实际上是由于数值有增有减造成的，只要我们的数值是单调增或单调减就不会出现ABA问题，所以针对账号余额这种本身就应该要能增能减的，就需要引入一个额外的变量 - 版本号，约定每次修改余额，都让版本号自增。
三，synchronized 原理
上面讲了那么多锁策略，那么 synchronized 属于那种锁呢？
1）对于 "乐观悲观" ，是自适应的
2）对于 "重量轻量"，是自适应的
3）对于 "自旋 挂起等待"，是自适应的
4）不是读写锁
5）是可重入锁
6）是非公平锁
自适应：可以根据情况来自行调整，比如：初始情况下，synchronized 会预测锁冲突的概率不大，此时是乐观锁，也就是轻量级锁，按照自旋锁的方式实现。在使用过程中，如果发现所冲突的情况增多，他会自动升级成悲观锁，也就是重量级锁，按照挂起等待锁的方式实现。
3.1 锁升级
synchronized 锁 ： 无锁 —— 偏向锁 —— 自旋锁 —— 重量级锁，自旋锁和重量级锁都讲过了，在此讲述一下什么是 偏向锁，没有真正的加锁，只是做了一个标记，就类似于 女生 和 男生 搞暧昧，但是没有承认身份，即有实无名。为什么会有偏向锁，是因为当一个操作至多有一个线程调用时，就不会产生锁冲突，就不需要加锁来产生额外的开销，即偏向锁是为了减少开销提高效率，而一旦有另一个线程也要调用该操作，产生锁冲突时，偏向锁就会升级成轻量级锁，这时候才真正的加锁。
3.2 锁消除
锁销除是一种编译器优化的手段，编译器会自动针对你当前写的 加锁的代码做出判定，如果编译器觉得该场景不会出现锁冲突，就会将 synchronized 锁给优化掉。
注：编译器只会在自己非常有把握的情况下，才会优化。
3.3 锁粗化
锁的粒度有粗细之分，synchronized 里面的代码越多，就认为锁的粒度越粗，代码越少，锁的粒度越细。
锁的粒度细，能够并发执行的逻辑就越多，更有利于利用 多核 cpu 资源，但是 cpu资源也是有限的，如果粒度细的锁，反复产生加解锁操作，可能实际效果还不如粒度粗的锁。