【JavaEE】常见锁策略、CAS
目录
常见的锁策略
乐观锁 vs 悲观锁
重量级锁 vs 轻量级锁
自锁锁和挂起等待锁
读写锁
可重入锁 vs 不可重入锁
公平锁 vs 非公平锁
CAS
ABA问题
synchronized几个重要的机制
1、锁升级
2、锁消除
3、锁粗化
常见的锁策略
乐观锁 vs 悲观锁
乐观锁和悲观锁是锁的一种特性，不是一把具体的锁。
悲观和乐观，是对后续锁冲突是否频繁给出的预测：
- 如果预测接下来锁冲突的概率不大，就可以少做一些工作，称为乐观锁
- 如果预测接下来锁冲突的概率很大，就可以多做一些工作，称为悲观锁
重量级锁 vs 轻量级锁
轻量级锁，锁的开销比较小
重量级锁，锁的开销比较大
这两种锁和刚才的乐观悲观有关，乐观锁通常也就是轻量级锁，悲观锁通常也就是重量级锁。
自锁锁和挂起等待锁
自旋锁，属于轻量级锁的一种典型实现，往往是纯用户态实现，比如使用一个while循环，不停的检查当前锁是否被释放，如果没释放，就继续循环，释放了就获取到锁，从而结束循环（忙等，虽然消耗了cpu，但是换来了更快的响应速度）。
挂起等待锁，属于重量级锁的一种典型实现，要借助系统api来实现，一旦出现锁竞争了，就会在内核中触发一系列的动作（比如让这个线程进入阻塞状态，暂时不参与cpu调度）
读写锁
两个线程加锁过程中：
- 读和读之间，不会产生竞争
- 读和写之间，会产生竞争
- 写和写之间，会产生竞争
把加锁分成两种：
- 读加锁，读的时候，别的线程能读，但是不能写
- 写加锁，写的时候，其他线程不能读也不能写
可重入锁 vs 不可重入锁
一个线程针对同一把锁，连续加锁2次，不会死锁，就是可重入锁，会死锁就是不可重入锁。
可重入锁会记录加锁线程信息，以便线程二次加锁，同时引入计数器，每加锁一次就+1，直到计数器为0才释放锁
公平锁 vs 非公平锁
当很多线程去尝试加一把锁的时候，一个线程能够拿到锁，其他线程阻塞等待，一旦第一个线程释放锁之后，接下来是哪个线程能够拿到锁呢？
公平锁：按照“先来后到”的顺序
非公平锁：剩下的线程以“均等”的概率，来重新竞争锁
操作系统提供的加锁api，默认情况就属于“非公平锁”，如果要想实现公平锁，还需要引入额外的队列，维护这些线程的加锁顺序
上述这些锁策略都是描述了一把锁的基本特点的，synchronized属于哪种锁呢？
- 对于“悲观乐观”，自适应的
- 对于“重量轻量”，自适应的
- 对于“自旋 挂起等待”，自适应的
- 不是读写锁
- 是可重入锁
- 是非公平锁
所谓自适应就是，初始情况下，synchronized会预测当前的锁冲突的概率不大，此时以乐观锁的模式来运行（此时也就是轻量级锁，基于自旋锁的方式来实现）
在实际使用过程中，如果发现锁冲突的情况比较多，synchronized就会升级成悲观锁（也就是重量级锁，基于挂起等待的方式来实现）
CAS
什么是CAS
CAS：全称Compare and swap，字面意思“比较并交换”，一个CAS涉及到以下操作：
假设内存中存在原数据V，旧的预期值A，需要修改的新值B
- 比较A与V是否相等
- 如果比较相等，将B写入V
- 返回操作是否成功
比较交换的也就是内存和寄存器 ，如下例子：
有一个内存 M，两个寄存器 A,B
CAS(V,A,B)
- 如果M和A的值相同，把M和B的值进行交换，同时返回true
- 如果M和A的值不同，无事发生，返回false
CAS其实就是一个cpu指令，一个cpu指令就能完成上述比较交换的逻辑，单个的cpu指令，是原子的，就可以使用CAS完成一些操作，进一步的替代“加锁”。
基于CAS实现线程安全的方式，也称为“无锁编程”
java中AtomicInteger和其他原子类，就是基于CAS的方式对int进行了封装 ，进行++就是原子的了。
public class Main {
public static AtomicInteger count=new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
Thread t1=new Thread(()->{
//count++
count.getAndIncrement();
//++count
count.incrementAndGet();
//count--
count.getAndDecrement();
//--count
count.decrementAndGet();
});
Thread t2=new Thread(()->{
//count++
count.getAndIncrement();
//++count
count.incrementAndGet();
//count--
count.getAndDecrement();
//--count
count.decrementAndGet();
});
t1.start();
t2.start();
}
}
前面的“线程不安全”本质上是进行自增的过程中，穿插执行了
CAS也是让这里的自增，不要穿插执行，核心思路和加锁是类似的
- 加锁是通过阻塞的方式，避免穿插
- CAS则是通过重试的方式，避免穿插
基于CAS实现自旋锁
public class spinLock{
private Thread owner=null;
public void lock()
{
while(!CAS(this.owner,null,Thread.currentThread())) {}
}
public void unLock(){
this.owner=null;
}
}
ABA问题
CAS进行操作的关键，是通过值“没有发生变化”来作为“没有其他线程穿插执行的判断依据”，但是这种判断方式不够严谨，更极端的情况下，可能有另一个线程穿插进来，把值从A->B->A，针对第一个线程来说，看起来好像是这个值没变，但是实际上已经被穿插执行了。
要避免ABA问题，我们可以让判定的数值，按照一个方向增长即可，有增有减就可能出现ABA，只是增加，或者只是减少就不会出现ABA，但是一些情况下，本身就应该要能增能减，我们可以引入一个额外的变量，版本号，约定每次修改余额，都会让版本号自增，此时在使用CAS判定的时候，就不是直接判定余额了，而是判定版本号，看版本号是否是变化了，如果版本号不变，注定没有线程穿插执行了。
synchronized几个重要的机制
1、锁升级
JVM将synchronized锁分为无锁，偏向锁，轻量级锁，重量级锁状态，会依据情况，进行依次升级。
无锁->偏向锁->自旋锁（轻量级锁）->重量级锁
锁升级的过程是单向的，不能再降级了。
偏向锁：不是真的加锁，只是做了一个标记，核心思想就是“懒汉模式”的另一种体现，如果有别的线程竞争锁再升级成轻量级锁。
2、锁消除
锁消除是编译器优化的手段，编译器会自动针对你当前写的加锁代码，做出判定，如果编译器觉得这个场景不需要加锁，此时就会把你写的synchronized给优化掉。
比如StringBuilder不带synchronized，StringBuffer带有synchronized，如果在单个线程中使用StringBuffer，此时编译器就会自动的把synchronized给优化掉
3、锁粗化
锁的粒度，synchronized里头，代码越多，就认为锁的粒度越粗，代码越少锁的粒度越细。
粒度细的时候能够并发执行的逻辑更多，更有利于充分利用好多核CPU资源，但是如果粒度细的锁，被反复进行加锁解锁，可能实际效果还不如粒度粗的锁。