前言

本篇文章主要介绍多线程中锁策略、CAS和synchronized优化，这三个都是多线程中比较重要的部分。

1.锁策略

在多线程编程中，锁是保证线程安全的重要手段。不同的锁策略适用于不同的场景，了解这些策略有助于我们编写高效、安全的并发程序。

1.1 乐观锁和悲观锁

在使用锁的时候，预测这个锁遇到冲突的概率
如果预测锁冲突概率比较高，就称为“悲观锁”，在悲观锁中，更倾向于阻塞操作，在访问数据前就进行加锁。
如果预测锁冲突概率比较低，就称为“乐观锁”，在乐观锁中，就会尝试其他方式代替阻塞(例如忙等)。

1.2 重量级锁和轻量级锁

重量级锁表示加锁的开销比较大，等待锁的线程，等待时间可能会比较长。
轻量级锁表示加锁的开销比较小，等待锁的线程会相对的比较短。

1.3 挂起等待锁和自旋锁

这里的两个锁是实现层面的。
挂起等待锁是悲观锁/重量级锁的典型实现，遇到锁冲突，就会让线程挂起等待(调度出CPU，等待被CPU唤醒)
自旋锁则是乐观锁/轻量级锁的典型实现，遇到锁冲突，不会放弃CPU，而是通过忙等的方式，再次尝试获取锁。

1.4 公平锁和非公平锁

公平锁遵循“先来后到”，按照线程尝试抓取锁的顺序来进行获取。
非公平锁不遵循“先来后到”，而是“概率均等”，每一个尝试抓取锁的线程在线程解锁后都有可能抓取到。

1.5 可重入锁和不可重入锁

一个线程针对一个锁连续加锁两次，不触发死锁，则是可重入锁，反之则是不可重入锁。

1.6 读写锁

读写锁会把加锁操作分成两种：读锁和写锁，在很多场景下，数据读的次数比写的次数要频繁很多，所以把读写锁分开，在读锁和读锁之间不会产生互斥，读锁和写锁，写锁和写锁之间才会产生互斥。这样降低了很多锁冲突带来的性能损失。

2.CAS

CAS全称compare and swap（比较和交换）
我们假设内存中原数据是V，旧的预期值是A，需要修改的新值是B，我们首先比较V和A是否相等，如果相等，将B写入V，然后返回一个布尔值。
这里比较特殊的是，这个逻辑是通过一个CPU指令来完成的，
A和B是存储在两个寄存器当中，假设寄存器分别为寄存器1，寄存器2，将原数据与寄存器1的值比较，如果相等，就把原数据的值赋值给寄存器2。也就是说，这个操作是原子的，意味着线程安全，不需要加锁。

2.1 CAS的应用

1. cas实现原子类
   在标准库中java.util.concurrent.atomic包里面的类都是基于这种方式来实现的，下面是这个包中的各种类：
   
   这里典型的一个类就是AtomicInteger，其中getAndIncrement就相当于i++操作，下面看一个例子：

    private static AtomicInteger count = new AtomicInteger(0);public static void main(String[] args) throws InterruptedException {Thread t1 = new Thread(() -> {for (int i = 0; i < 50000; i++) {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);}

这里使用了AtomicInteger类来实现多线程实现同时自增一个变量，可以看到不进行加锁的情况下，结果也正确：

2. CAS实现自旋锁
   使用CAS可以实现自旋锁，下面看伪代码：

public class SpinLock {private Thread owner = null;public void lock(){// 通过 CAS 看当前锁是否被某个线程持有.// 如果这个锁已经被别的线程持有, 那么就⾃旋等待.// 如果这个锁没有被别的线程持有, 那么就把 owner 设为当前尝试加锁的线程.while(!CAS(this.owner, null, Thread.currentThread())){}}public void unlock (){this.owner = null;}
}

循环里判断锁是否被占用，如果被占用，就会一直循环，直到不被占用，解锁状态。

2.2 CAS的ABA问题

假设有两个线程T1和T2：
线程T1读取共享变量的值为A。
然后线程T2将共享变量的值从A修改为B，再修改回A。
最后线程T1再次读取共享变量的值为A，由于值与最初读取的A相同，因此CAS操作成功，但实际上共享变量的状态已经被T2修改过。
这样T1就无法区分这个变量是否经历了一系列修改还是始终是A
解决方案：
可以给要修改的值引入版本号，比较当前值和旧值时，也要比较版本号是否符合预期：如果当前版本号和读到的版本号相同, 则修改数据, 并把版本号 + 1；如果当前版本号⾼于读到的版本号. 就操作失败(认为数据已经被修改过了)。

3.synchronized优化

3.1锁升级

synchronized具有自适应的特性，会根据情况进行锁升级，JVM将synchronized分为无锁、偏向锁、轻量级锁、重量级锁状态，会依次进行升级。
轻量级锁和重量级锁前面已经简要介绍，这里介绍一下偏向锁。
偏向锁并没有给线程真正加锁，只是记录这个锁属于哪个线程，如果没有线程进行竞争这个锁，偏向锁状态就保持，直到最终解锁；如果遇到其他线程来竞争这个锁，就在其他线程获取锁之前，抢先获取到这个锁，也可以让其他线程阻塞，保证线程安全。

3.2锁消除

有些代码中写了加锁，但是如果JVM执行时发现不需要加锁，就会自动把锁去掉。比如StringBuffer带有synchronized锁，如果在单线程情况下使用，JVM和编译器则会进行判断，将锁”消除“。

3.3锁粗化

这里涉及的是锁的粒度
加锁和范围中代码越多，锁的粒度越粗。
如果有一系列独立的加锁、解锁操作，JVM可以回将他们合并成一个更大的锁范围，只加锁解锁一次，这样减少了系统的调用开销，同时也减少了锁竞争。

总结

本篇文章介绍了锁策略，CAS以及synchronized的优化，在后面会对synchronized进行总结。