一、常见的锁策略

1.1 悲观锁 vs 乐观锁

悲观和乐观是指锁竞争的激烈情况。

1. 悲观锁：加锁的时候预测接下来的锁竞争会非常激烈，就需要针对这样的激烈情况额外做工作；
2. 乐观锁：加锁的时候预测接下来的锁竞争不激烈，就不需要额外做工作去处理锁竞争情况；

1.2 重量级锁 vs 轻量级锁

这两种锁就对应上诉的悲观乐观情况下的处理机制。

1. 重量级锁：应对上面的锁竞争激烈的悲观情况，效率更低；
2. 轻量级锁：应对上面的锁竞争不激烈的情况，效率更高。

1.3 挂起等待锁 vs 自旋锁

这又是对上面的重量级与轻量级锁的典型实现。

1. 挂起等待锁：重量级锁的典型实现，是操作系统内核级别的，加锁发生竞争，线程进入阻塞后，就需要内核进行唤醒。获取锁的周期会变长，但是这期间不会消耗CPU资源。
2. 自旋锁：轻量级锁的典型实现，是应用程序级别的，加锁时发生竞争，一般不进行阻塞，而是通过忙等，等待后续程序唤醒。获取锁的周期很短，可以及时获取到锁，但是这期间会一直消耗CPU资源。

1.4 普通互斥锁 vs 读写锁

这两种锁是针对加锁解锁时的线程安全问题。

• 普通互斥锁只有加锁，解锁操作，并且读操作不会出现线程安全问题；
• 而读写锁有读加锁，写加锁，和解锁操作，
  读锁与读锁之间不互斥；
  读锁与写锁之间存在互斥；
  写锁与写锁之间也存在互斥。
  读写锁主要是针对读操作多，写操作少的情况服务。

1.5 可重入锁 vs 不可重入锁

这组锁就是针对同一个线程多次嵌套获取同一把锁。

• 可重入锁：字面意思是“可以重新进入的锁”，即允许同一个线程多次获取同一把锁。
• 不可重入锁：字面意思是“不可以重新进入的锁”，即同一个线程多次获取同一把锁，会报错。

1.6 不公平锁 vs 公平锁

这组锁是针对线程获取锁的概率设置的。

• 不公平锁：在Java中不公平锁是概率均等的随机分配锁；
• 公平锁：在Java中公平锁是按照等待的时间先来后到分配锁。因为操作系统是随机调度，为了实现公平锁就需要数据结构来记录先后调度顺序。

二、synchronized特性

2.1 synchronized的锁策略

锁策略如下：

• synchronized是一个自适应的锁，开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁。
• 开始是轻量级锁实现, 如果锁被持有的时间较长, 就转换成重量级锁。
• 是一种普通互斥锁。
• 是一种不公平锁。
• 是一种可重入锁。

2.2 synchronized加锁过程

synchronized的自适应过程称为锁升级：无锁 -> 偏向锁 -> 自旋锁 -> 重量级锁。

• 偏向锁：偏向锁不是真的 “加锁”, 只是给对象头中做一个 “偏向锁的标记”, 记录这个锁属于哪个线程.
  如果后续没有其他线程来竞争该锁, 那么就不用进行其他同步操作了(避免了加锁解锁的开销)
  如果后续有其他线程来竞争该锁(刚才已经在锁对象中记录了当前锁属于哪个线程了, 很容易识别
  当前申请锁的线程是不是之前记录的线程), 那就取消原来的偏向锁状态, 进入一般的轻量级锁状态.
  就像跟你搞暧昧，但是不正式跟你确认关系，如果没人来追求你就一直不确定关系，如果有人追求你就确认关系。

• 无锁 -> 偏向锁 ：这个阶段是进入synchronized代码块；

• 偏向锁 -> 自旋锁：这个阶段是拿到偏向锁后，遇到其他线程来竞争这个锁；

• 自旋锁 -> 重量级锁：这个阶段是JVM发现当前的锁竞争非常激烈。

2.3 其它优化措施

除了上面的synchronized锁升级以外，还有以下的优化措施：

• 锁消除：编译器优化措施，编译器会对加锁的代码进行判断（但这种判断是非常保守的，只有100%确定当前是单线程），如果当前逻辑不需要加锁，编译器就会自动去除synchronized。

• 锁粗化：一个代码对细粒度的代码反复加锁解锁，就会将这个步骤优化为更粗粒度的加锁解锁。
  

• 锁的粒度：加锁和解锁之间，包含的代码执行的逻辑/时间越多，则锁的粒度就越粗，反之越细。

三、CAS

3.1 CAS概念

CAS: 全称Compare and swap，字面意思:”比较并交换“，一个 CAS 涉及到以下操作：

我们假设内存中的原数据V，旧的预期值A，需要修改的新值B。

1. 比较 A 与 V 是否相等。（比较）
2. 如果比较相等，将 B 写入 V。（交换）
3. 返回操作是否成功。

伪代码表示如下：

java">boolean CAS(address, expectValue, swapValue) {if (&address == expectedValue) {&address = swapValue;return true;}return false;
}

3.2 CAS应用场景

3.2.1 实现原子类。

原子类：特指java.util.concurrent.atomic 包下的类，这些类中的操作都是原子的。

像我们前面Thread类详解，这篇文章介绍的非原子的操作带来的线程安全问题，如果使用原子类就不存在了。
例如执行下面这段代码：结果就一直是100000。

java">
import java.util.concurrent.atomic.AtomicInteger;public class Demo {private static AtomicInteger count = new AtomicInteger(0);public static void main(String[] args) throws InterruptedException {Thread thread1 = new Thread(() -> {for (int i = 0; i < 50000; i++) {count.getAndAdd(1);}});Thread thread2 = new Thread(() -> {for (int i = 0; i < 50000; i++) {count.getAndAdd(1);}});thread1.start();thread2.start();thread1.join();thread2.join();System.out.println(count.get());}
}

原子类线程安全的原理：

假设两个线程同时调用 getAndIncrement ：

1. 两个线程都读取 value 的值到 oldValue 中。 (oldValue 是一个局部变量, 在栈上. 每个线程有自己的栈)
2. 线程1 先执行 CAS 操作. 由于 oldValue 和 value 的值相同, 直接进行对 value 赋值。
3. 线程2 再执行 CAS 操作, 第一次 CAS 的时候发现 oldValue 和 value 不相等, 不能进行赋值。因此需要进入循环。在循环里重新读取 value 的值赋给 oldValue。
4. 线程2 接下来第二次执行 CAS, 此时 oldValue 和 value 相同, 于是直接执行赋值操作。
5. 线程1 和 线程2 返回各自的 oldValue 的值即可。
   

3.2.2 实现自旋锁

基于 CAS 实现更灵活的自旋锁, 获取到更多的控制权。

主要逻辑如下：

• 通过 CAS 看当前锁是否被某个线程持有。
• 如果这个锁已经被别的线程持有, 那么就自旋等待。
• 如果这个锁没有被别的线程持有, 那么就把 owner 设为当前尝试加锁的线程.

伪代码描述如下：

java">public class SpinLock {private Thread owner = null;public void lock(){while(!CAS(this.owner, null, Thread.currentThread())){}}public void unlock (){this.owner = null;}
}

3.3 CAS的ABA问题

3.3.1 ABA问题简介

假设存在两个线程 t1 和 t2. 有一个共享变量 num, 初始值为 A。
接下来, 线程 t1 想使用 CAS 把 num 值改成 Z, 那么就需要先读取 num 的值, 记录到 oldNum 变量中.。
使用 CAS 判定当前 num 的值是否为 A, 如果为 A, 就修改成 Z。
但是, 在 t1 执行这两个操作之间, t2 线程可能把 num 的值从 A 改成了 B, 又从 B 改成了 A。
线程 t1 的 CAS 是期望 num 不变就修改. 但是 num 的值已经被 t2 给改了. 只不过又改成 A 了. 这
个时候 t1 究竟是否要更新 num 的值为 Z 。就不符合预期出现bug。

过程图：

bug例子：

假如你去取钱有1000，取500，不小心按了两次取款，我们只想扣一次500，第一次按相当于T2，第二次按相当于T1，先执行T2读取操作修改为500，这时又正好有人给你汇款了500，内存中与寄存器中又相等了，T1扣款的操作也会执行成功。

造成ABA问题的原因就是内存值既有加又有减，所以我们的解决ABA的方式如下。

3.3.2 解决方案

给要修改的值, 引入版本号. 在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期。
CAS 操作在读取旧值的同时, 也要读取版本号。
真正修改的时候,：

• 如果当前版本号和读到的版本号相同, 则修改数据, 并把版本号 + 1。
• 如果当前版本号高于读到的版本号. 就操作失败(认为数据已经被修改过了)。

四、JUC组件

JUC组件就是指 java.util.concurrent 这个包下面的类。

4.1 Callable接口

Callable 接口就和java.lang包下的Runnable接口的定位差不多，只不过给了我们一个返回值，在Runnable接口要重写run方法，而在Callable接口中要重写call方法。

在使用Callable接口传入线程时需要借助JUC下的另一个类FutureTask。

使用例子一般如下：

java">public class Demo {public static void main(String[] args) {//创建实现了Callable接口的方法Callable<Integer> callable = new Callable<Integer>() {@Overridepublic Integer call() throws Exception {return null;}};//将实现Callable接口的对象作为参数传入FutureTask，泛型参数要一致FutureTask<Integer> futureTask = new FutureTask<>(callable);//将FutureTask对象作为参数传入Thread thread = new Thread(futureTask);}
}

4.2 ReentrantLock类

ReentrantLock类可重入互斥锁，和synchronized的定位是差不多的。

ReentrantLock 的用法:

• public void lock(): 加锁, 如果获取不到锁就死等。
• public boolean trylock(超时时间): 加锁, 如果获取不到锁, 等待一定的时间之后就放弃加锁。
• public void unlock(): 解锁。
  使用这个类加锁需要我们手动解锁，为避免解锁执行不到的情况，我们一般将unlock放在finally代码块中。

java">		ReentrantLock locker = new ReentrantLock();try {locker.lock();}finally {locker.unlock();}

ReentrantLock与synchronized的区别：

• ReentrantLock是类，是Java代码实现的，synchronized是关键字由JVM使用c++代码实现的。
• ReentrantLock是需要lock()方法加锁，unlock()方法解锁。synchronized是通过进出代码块加锁解锁。
• ReentrantLock还提供了tryLock()方法可以设置超时时间，不会一直阻塞，加锁成功返回true，调用者可以根据返回值自己操作。
• ReentrantLock还提供了公平锁的实现，默认是非公平锁，但是构造方法传参true实现公平锁。
  
• ReentrantLock搭配的通知机制是Condition类，可以更精确控制唤醒某个指定的线程，相比wait / notify功能更强大。

4.3 Semaphore类

信号量,：用来表示 “可用资源的个数”。 本质上就是一个计数器，能够协调多个线程之间的资源调配。
最主要的就是申请资源（P操作，调用acquire方法）释放资源（V操作，调用release方法）

• 可以把信号量想象成是停车场的展示牌: 当前有车位 100 个。表示有 100 个可用资源。
• 当有车开进去的时候, 就相当于申请一个可用资源, 可用车位就 -1 (这个称为信号量的 P 操作)
• 当有车开出来的时候, 就相当于释放一个可用资源, 可用车位就 +1 (这个称为信号量的 V 操作)
• 如果计数器的值已经为 0 了, 还尝试申请资源, 就会阻塞等待, 直到有其他线程释放资源.

4.4 CountDownLatch类

CountDownLatch类的作用：同时等待 N 个任务执行结束。（就像跑步比赛，10个选手依次就位，哨声响才同时出发；所有选手都通过终点，才能公布成绩。）

使用多线程的时候，经常会把一个大任务拆分为多个子任务，使用CountDownLatch衡量子任务完成，让整个任务完成。

• 构造 CountDownLatch 实例, 参数传入任务个数，初始化 10 表示有 10 个任务需要完成。
• 每个任务执行完毕, 都调用 countDown()方法 . 在 CountDownLatch 内部的计数器同时自减.
• 主线程中使用 await()方法; 阻塞等待所有任务执行完毕后wait结束。 相当于计数器为 0 了。