目录
CAS
CAS伪代码
CAS的应用
实现原子类
实现自旋锁
CAS的ABA问题
ABA问题导致BUG的例子
相关面试题
synchronized原理
synchronized特性
加锁过程
相关面试题
Callable
相关面试题
JUC的常见类
ReentrantLock
ReentrantLock 和 synchronized 的区别:
原子类
信号量
相关面试题
CAS
CAS: 全称Compare and swap，字面意思:”比较并交换“，一个 CAS 涉及到以下操作：
我们假设内存中的原数据V，旧的预期值A，需要修改的新值B。
1. 比较 A 与 V 是否相等。（比较）
2. 如果比较相等，将 B 写入 V。（交换）
3. 返回操作是否成功。
CAS伪代码
下面写的代码不是原子的 , 真实的 CAS 是一个原子的硬件指令完成的 . 这个伪代码只是辅助理解 CAS 的工作流程。boolean CAS(address, expectValue, swapValue) { if (&address == expectedValue) { &address = swapValue; return true; } return false;}CAS其实是一个cpu指令，单个的cpu指令，是原子的！！！
就可以使用CAS完成一些操作，进一步代替“加锁”；
基于CAS实现线程安全的方式也称为“无锁化编程”。
优点：保证线程安全，同时避免阻塞，影响效率；
缺点：代码会变复杂，不好理解；只能够适用特定场景，不如加锁方式更普遍。
CAS的应用
实现原子类
标准库中提供了 java.util.concurrent.atomic 包, 里面的类都是基于这种方式来实现的.
典型的就是 AtomicInteger 类. 其中的 getAndIncrement 相当于 i++ 操作.
伪代码实现
class AtomicInteger { private int value; public int getAndIncrement() { int oldValue = value; while ( CAS(value, oldValue, oldValue+1) != true) { oldValue = value; } return oldValue; }}实现自旋锁
伪代码实现
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; }}CAS的ABA问题
ABA问题即：
假设有两个线程t1和t2，有一个共享变量num，初值为A，接下来t1想使用CAS把num改为Z，那么就需要先读取num的值，记录到oldNum变量中，然后使用CAS判断当前num的值是否为A，如果为A，则改为Z。
但是在t1执行上述操作之前，t2线程可能把num的值从A改为B，又从B改为A。
那么此时，线程t1无法区分当前这个变量始终是A，还是经历了一个变化过程。
ABA问题导致BUG的例子
假设你要去ATM取款机取钱，余额有1000，要取款500，但是取款的时候ATM机卡了一下，所以你按了两下，假设ATM取款机按CAS方式工作，虽然你按了两次，但是你取出的是500，不过，如果恰巧这个时候有人给你转了500，这个时候，你按的第2下取款，使用CAS方式会发现余额还是1000，那么此时就会余额没有改变，你最后会取出1000.
解决方法：引入版本号等方式
给要修改的值, 引入版本号. 在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期.
CAS 操作在读取旧值的同时, 也要读取版本号.
真正修改的时候,
如果当前版本号和读到的版本号相同, 则修改数据, 并把版本号 + 1.
如果当前版本号高于读到的版本号. 就操作失败(认为数据已经被修改过了).
相关面试题
1) 讲解下你自己理解的 CAS 机制 全称 Compare and swap, 即 "比较并交换". 相当于通过一个原子的操作, 同时完成 "读取内存, 比较是否相等, 修改内存" 这三个步骤. 本质上需要 CPU 指令的支撑2) ABA问题怎么解决？
给要修改的数据引入版本号. 在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期.
如果发现当前版本号和之前读到的版本号一致, 就真正执行修改操作, 并让版本号自增; 如果发现当前版本号比之前读到的版本号大, 就认为操作失败.
synchronized原理
synchronized特性
1. 开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁.
2. 开始是轻量级锁实现, 如果锁被持有的时间较长, 就转换成重量级锁.
3. 实现轻量级锁的时候大概率用到的自旋锁策略
4. 是一种不公平锁
5. 是一种可重入锁
6. 不是读写锁
加锁过程
JVM 将 synchronized 锁分为 无锁、偏向锁、轻量级锁、重量级锁 状态。会根据情况，进行依次升级。
1）偏向锁
第一个尝试加锁的线程, 优先进入偏向锁状态.
偏向锁不是真的 "加锁", 只是给对象头中做一个 "偏向锁的标记", 记录这个锁属于哪个线程.
如果后续没有其他线程来竞争该锁, 那么就不用进行其他同步操作了(避免了加锁解锁的开销)
如果后续有其他线程来竞争该锁(刚才已经在锁对象中记录了当前锁属于哪个线程了, 很容易识别当前申请锁的线程是不是之前记录的线程), 那就取消原来的偏向锁状态, 进入一般的轻量级锁状态.
偏向锁本质上相当于 "延迟加锁" . 能不加锁就不加锁, 尽量来避免不必要的加锁开销.
但是该做的标记还是得做的, 否则无法区分何时需要真正加锁.
2）轻量级锁
随着其他线程进入竞争, 偏向锁状态被消除, 进入轻量级锁状态(自适应的自旋锁).
此处的轻量级锁就是通过 CAS 来实现.
通过 CAS 检查并更新一块内存 (比如 null => 该线程引用)
如果更新成功, 则认为加锁成功
如果更新失败, 则认为锁被占用, 继续自旋式的等待(并不放弃 CPU).
3）重量级锁
如果竞争进一步激烈, 自旋不能快速获取到锁状态, 就会膨胀为重量级锁
此处的重量级锁就是指用到内核提供的 mutex .
执行加锁操作, 先进入内核态.
在内核态判定当前锁是否已经被占用
如果该锁没有占用, 则加锁成功, 并切换回用户态.
如果该锁被占用, 则加锁失败. 此时线程进入锁的等待队列, 挂起. 等待被操作系统唤醒.
经历了一系列的沧海桑田, 这个锁被其他线程释放了, 操作系统也想起了这个挂起的线程, 于是唤醒这个线程, 尝试重新获取锁.
锁消除
编译器+JVM 判断锁是否可消除. 如果可以, 就直接消除。
例如：单线程环境下。
锁粗化
一段逻辑中如果出现多次加锁解锁, 编译器 + JVM 会自动进行锁的粗化.
相关面试题
1）什么是偏向锁？
偏向锁不是真的加锁 , 而只是在锁的对象头中记录一个标记 ( 记录该锁所属的线程 ). 如果没有其他线程参与竞争锁, 那么就不会真正执行加锁操作 , 从而降低程序开销 . 一旦真的涉及到其他的线程竞争, 再取消偏向锁状态 , 进入轻量级锁状态 .Callable
Callable 和 Runnable 相对, 都是描述一个 "任务". Callable 描述的是带有返回值的任务,
Runnable 描述的是不带返回值的任务.
Callable 通常需要搭配 FutureTask 来使用. FutureTask 用来保存 Callable 的返回结果. 因为
Callable 往往是在另一个线程中执行的, 啥时候执行完并不确定.
FutureTask 就可以负责这个等待结果出来的工作
理解FutureTask
想象去吃麻辣烫 . 当餐点好后 , 后厨就开始做了 . 同时前台会给你一张 " 小票 " . 这个小票就是 FutureTask. 后面我们可以随时凭这张小票去查看自己的这份麻辣烫做出来了没 . 代码示例import java.util.concurrent.Callable;import java.util.concurrent.ExecutionException;import java.util.concurrent.FutureTask;public class Demo30 { public static void main(String[] args) throws ExecutionException, InterruptedException { // 定义了任务. Callable<Integer> callable = new Callable<Integer>() { @Override public Integer call() throws Exception { int sum = 0; for (int i = 0; i <= 1000; i++) { sum += i; } return sum; } }; // 把任务放到线程中进行执行. FutureTask<Integer> futureTask = new FutureTask<>(callable); Thread t = new Thread(futureTask); t.start(); // 此处的 get 就能获取到 callable 里面的返回结果. // 由于线程是并发执行的. 执行到主线程的 get 的时候, t 线程可能还没执行完. // 没执行完的话, get 就会阻塞. System.out.println(futureTask.get()); }}相关面试题
介绍一下Callable是什么
Callable 是一个 interface . 相当于把线程封装了一个 "返回值". 方便程序猿借助多线程的方式计算结果.
Callable 和 Runnable 相对, 都是描述一个 "任务". Callable 描述的是带有返回值的任务,
Runnable 描述的是不带返回值的任务.
Callable 通常需要搭配 FutureTask 来使用. FutureTask 用来保存 Callable 的返回结果. 因为
Callable 往往是在另一个线程中执行的, 啥时候执行完并不确定.
FutureTask 就可以负责这个等待结果出来的工作.
JUC的常见类
JUC，是java.util.concurrent的缩写。
ReentrantLock
可重入互斥锁. 和 synchronized 定位类似, 都是用来实现互斥效果, 保证线程安全.
ReentrantLock 也是可重入锁. "Reentrant" 这个单词的原意就是 "可重入".
ReentrantLock的用法
lock(): 加锁, 如果获取不到锁就死等.
trylock(超时时间): 加锁, 如果获取不到锁, 等待一定的时间之后就放弃加锁.
unlock(): 解锁
ReentrantLock 和 synchronized 的区别:
synchronized 是一个关键字, 是 JVM 内部实现的(大概率是基于 C++ 实现). ReentrantLock 是标准库的一个类, 在 JVM 外实现的(基于 Java 实现).
synchronized 使用时不需要手动释放锁. ReentrantLock 使用时需要手动释放. 使用起来更灵活, 但是也容易遗漏 unlock.
synchronized 在申请锁失败时, 会死等. ReentrantLock 可以通过 trylock 的方式等待一段时间就放弃.
synchronized 是非公平锁, ReentrantLock 默认是非公平锁. 可以通过构造方法传入一个 true 开启公平锁模式.
更强大的唤醒机制. synchronized 是通过 Object 的 wait / notify 实现等待-唤醒. 每次唤醒的是一个随机等待的线程. ReentrantLock 搭配 Condition 类实现等待-唤醒, 可以更精确控制唤醒某个指定的线程.
// ReentrantLock 的构造方法public ReentrantLock(boolean fair) { sync = fair ? new FairSync() : new NonfairSync();}如何选择使用哪个锁？
锁竞争不激烈的时候, 使用 synchronized, 效率更高, 自动释放更方便.
锁竞争激烈的时候, 使用 ReentrantLock, 搭配 trylock 更灵活控制加锁的行为, 而不是死等.
如果需要使用公平锁, 使用 ReentrantLock.
原子类
原子类内部用的是 CAS 实现，所以性能要比加锁实现 i++ 高很多。原子类有以下几个
AtomicBoolean
AtomicInteger
AtomicIntegerArray
AtomicLong
AtomicReference
AtomicStampedReference
ExecutorService和Executors
ExecutorService 表示一个线程池实例.
Executors 是一个工厂类, 能够创建出几种不同风格的线程池.
ExecutorService 的 submit 方法能够向线程池中提交若干个任务.
代码示例
ExecutorService pool = Executors.newFixedThreadPool(10);pool.submit(new Runnable() { @Override public void run() { System.out.println("hello"); }});Executors 创建线程池的几种方式：
newFixedThreadPool: 创建固定线程数的线程池
newCachedThreadPool: 创建线程数目动态增长的线程池.
newSingleThreadExecutor: 创建只包含单个线程的线程池.
newScheduledThreadPool: 设定 延迟时间后执行命令，或者定期执行命令. 是进阶版的 Timer.
Executors 本质上是 ThreadPoolExecutor 类的封装.
信号量
信号量（Semaphore）, 用来表示 "可用资源的个数". 本质上就是一个计数器.
Semaphore 的 PV 操作中的加减计数器操作都是原子的, 可以在多线程环境下直接使用.
代码示例
import java.util.concurrent.Semaphore;public class Demo24 { public static void main(String[] args) throws InterruptedException { Semaphore semaphore = new Semaphore(4); semaphore.acquire(); System.out.println("P 操作"); semaphore.acquire(); System.out.println("P 操作"); semaphore.acquire(); System.out.println("P 操作"); semaphore.acquire(); System.out.println("P 操作"); semaphore.acquire(); System.out.println("P 操作"); }}运行结果
相关面试题
1) 线程同步的方式有哪些？
synchronized, ReentrantLock, Semaphore 等都可以用于线程同步.
2) 为什么有了 synchronized 还需要 juc 下的 lock？
以 juc 的 ReentrantLock 为例,
synchronized 使用时不需要手动释放锁. ReentrantLock 使用时需要手动释放. 使用起来更
灵活,
synchronized 在申请锁失败时, 会死等. ReentrantLock 可以通过 trylock 的方式等待一段时
间就放弃.
synchronized 是非公平锁, ReentrantLock 默认是非公平锁. 可以通过构造方法传入一个
true 开启公平锁模式.
synchronized 是通过 Object 的 wait / notify 实现等待-唤醒. 每次唤醒的是一个随机等待的
线程. ReentrantLock 搭配 Condition 类实现等待-唤醒, 可以更精确控制唤醒某个指定的线
程.
3) AtomicInteger 的实现原理是什么？
基于 CAS 机制. 伪代码如下:
class AtomicInteger { private int value; public int getAndIncrement() { int oldValue = value; while ( CAS(value, oldValue, oldValue+1) != true) { oldValue = value; } return oldValue; }}