Java岗大厂面试百日冲刺【Day22】—— 并发编程2

转载自: Java岗大厂面试百日冲刺【Day22】—— 并发编程2

本文已获得原作者 _陈哈哈 授权并经过重新整理规划后发布。

本栏目Java开发岗高频面试题主要出自以下各技术栈：Java基础知识、集合容器、并发编程、JVM、Spring全家桶、MyBatis等ORMapping框架、MySQL数据库、Redis缓存、RabbitMQ消息队列、Linux操作技巧等。

面试题1：说一下你对ReentrantLock的理解？

ReentrantLock是JDK1.5引入的，它拥有与synchronized相同的并发性和内存语义，并提供了超出synchonized的其他高级功能(例如，中断锁等候、条件变量等)，并且使用ReentrantLock比synchronized能获得更好的可伸缩性。

ReentrantLock主要利用： CAS(compare-and-swap) + AQS(AbstractQueuedSynchronizer)队列来实现。它支持公平锁和非公平锁，两者的实现类似。

CAS：

CAS（compare-and-swap），见名知意，比较并交换。CAS 加 volatile 关键字是实现并发包的基石。没有CAS就不会有并发包，synchronized是一种独占锁、悲观锁，java.util.concurrent中借助了CAS指令实现了一种区别于synchronized的一种乐观锁。

CAS引用了乐观锁思想，每次拿数据的时候都认为别的线程不会修改这个数据，所以不会上锁，但是在更新的时候会通过标记参数判断一下在此期间（更新期间）别的线程有没有已经修改过该标记数据，如果发现有其他线程在修改且未修改完成，并不会像悲观锁那样阻塞线程，而是直接返回，可以去选择再次重试获得锁，也可以直接退出。

举个流程示例

如CAS操作包括三个操作数：需要读写的内存位置(V)、预期原值(A)、新值(B)。如果内存位置与预期原值的A相匹配，说明在此期间（更新期间）别的线程未修改过该标记数据，那么将内存位置的值更新为新值B。如果内存位置与预期原值的值不匹配，那么处理器不会做任何操作。

无论哪种情况，它都会在 CAS 指令之前返回该位置的值。（在 CAS 的一些特殊情况下将仅返回 CAS 是否成功，而不提取当前值。）

AQS:

AQS主要利用硬件原语指令CAS，来实现轻量级多线程同步机制，并且不会引起CPU上文切换和调度，同时提供内存可见性和原子化更新保证(线程安全的三要素：原子性、可见性、顺序性)。

AQS的本质上是一个同步器/阻塞锁的基础框架，其作用主要是提供加锁、释放锁，并在内部维护一个FIFO等待队列，用于存储由于锁竞争而阻塞的线程。

追问1：你认为 ReentrantLock 相比 synchronized 都有哪些区别？

两者的共同点：

  1. 都是用来协调多线程对共享对象、变量的访问
  2. 都是可重入锁，同一线程可以多次获得同一个锁
  3. 都保证了可见性和互斥性

两者的不同点：

  1. ReentrantLock 显示的获得、释放锁，synchronized 隐式获得释放锁；
  2. ReentrantLock 可响应中断、可轮回，synchronized 是不可以响应中断的，为处理锁的不可用性提供了更高的灵活性；
  3. ReentrantLock 是API 级别的，synchronized 是 JVM 级别的；
  4. ReentrantLock 可以实现公平锁；
  5. ReentrantLock 通过 Condition 可以绑定多个条件；
  6. 底层实现不一样， synchronized 是同步阻塞，使用的是悲观并发策略，ReentrantLock 是同步非阻塞，采用的是乐观并发策略；
  7. Lock 是一个接口，而 synchronized 是 Java 中的关键字，synchronized 是内置的语言实现；
  8. synchronized 在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而 Lock 在发生异常时，如果没有主动通过 unLock()去释放锁，则很可能造成死锁现象，因此使用 Lock 时需要在 finally 块中释放锁。
  9. Lock 可以让等待锁的线程响应中断，而 synchronized 却不行，使用 synchronized 时，等待的线程会一直等待下去，不能够响应中断。
  10. 通过 Lock 可以知道有没有成功获取锁，而 synchronized 却无法办到。
  11. Lock 可以提高多个线程进行读操作的效率，就是实现读写锁等。
Lock lock = new ReentrantLock();
Condition condition = lock.newCondition();
lock.lock();
try {
  while(条件判断表达式) {
      condition.wait();
  }
 // 处理逻辑
} finally {
    lock.unlock();
}

面试题2：解释一下公平锁和非公平锁？

ReenTrantLock可以指定是公平锁还是非公平锁，而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获锁。

我们刚才提及到AQS中，如果线程A正处于lock状态，线程B进来时发现线程A处于lock状态，会自动进入阻塞队列，等待取锁；这时候当线程C也进来了也发现线程A处于lock状态，也会自动进入阻塞队列。那么等A释放锁后，下次加锁到底是线程B先拿到还是线程C先拿到呢？

ReentrantLock有个构造方法用于设置锁的公平性，如果我们仅仅是new了一个ReentrantLock的话，那么就是非公平锁（默认），就是靠自己去争取，完全的随机性。如果我们在new ReentrantLock(true) 加入 true参数时，公平锁，就会遵循先入先出的原则，保证了锁的公平性。

面试题3：能详细说一下CAS具体实现原理么？

首先，CAS的英文单词是Compare and Swap，即是比较并替换。CAS机制中使用了3个基本操作数：内存地址V，旧的预期值A，待替换的新值B。

CAS规则是：当需要更新一个变量的值的时候，只有当变量的预期值A和内存地址V中的实际值相同的时候，才会把内存地址V对应的值替换成B。

下面我们通过一个例子来讲解：

1.在内存地址V中存储的值是陈哈哈

InterviewForJavaByThreeQuestionsADay22-01.webp

2.线程01想要把变量的值改成侨总，对于线程01而言，内存地址 V=‘陈哈哈’，旧的预期值 A=‘陈哈哈’，需要替换的新值 B=‘侨总’。

InterviewForJavaByThreeQuestionsADay22-02.webp

3.在线程01要提交更新之前，另外一个线程02抢先一步，将内存地址V中的值更新成了V='比特币'。

InterviewForJavaByThreeQuestionsADay22-03.webp

4.线程01开始提交更新的时候，按照CAS机制，首先进行A的值与内存地址V中的值进行比较（ A=‘陈哈哈’ V=‘比特币’），发现 A != V 中的实际值，提交失败。

InterviewForJavaByThreeQuestionsADay22-04.webp

5.线程01未获取锁后进行重试，重新获取内存地址V的当前值（V=‘比特币’），并重新赋值想要修改的值（B=‘侨总’）。截至目前，线程01旧的预期值为A='比特币'，B='侨总'，这个重新尝试的过程被称为自旋。

InterviewForJavaByThreeQuestionsADay22-05.webp

6.这一次就比较顺利了，没有其他线程改变该变量的值，所以线程01通过CAS机制，比较旧的预期值A与内存地址V的值，相同（V == A），可以替换。

InterviewForJavaByThreeQuestionsADay22-06.webp

7.线程01进行替换，把地址V（V=‘比特币’）的值替换成B（B=‘侨总’）。

InterviewForJavaByThreeQuestionsADay22-07.webp

以上就是一个比较完整的CAS锁冲突的处理方式。

从思想上来看，synchronized属于悲观锁，悲观的认为程序中的并发问题十分严重，所以严防死守，只让一个线程操作该代码块。而CAS属于乐观锁，乐观地认为程序中的并发问题并不那么严重，所以让线程不断的去尝试更新，在并发问题不严重的时候性能要比synchronized快。

追问1：那CAS的缺陷有哪些呢？

当然，CAS也有缺点，如ABA问题，自旋锁消耗问题、多变量共享一致性问题等。

ABA：

问题描述：

线程t1将它的值从A变为B，再从B变为A。同时有线程t2要将值从A变为C。但CAS检查的时候会发现没有改变，但是实质上它已经发生了改变 。可能会造成数据的缺失。

解决方法：

CAS还是类似于乐观锁，同数据乐观锁的方式给它加一个版本号或者时间戳，如AtomicStampedReference

自旋消耗资源：

问题描述：

多个线程争夺同一个资源时，如果自旋一直不成功，将会一直占用CPU。

解决方法：

破坏掉for死循环，当超过一定时间或者一定次数时，return退出。JDK8新增的LongAddr,和ConcurrentHashMap类似的方法。当多个线程竞争时，将粒度变小，将一个变量拆分为多个变量，达到多个线程访问多个资源的效果，最后再调用sum把它合起来。

虽然base和cells都是volatile修饰的，但感觉这个sum操作没有加锁，可能sum的结果不是那么精确。

多变量共享一致性问题：

解决方法:

CAS操作是针对一个变量的，如果对多个变量操作，

可以加锁来解决。

封装成对象类解决。

追问2：讲一下什么是ABA问题？怎么解决？

ABA：如果另一个线程修改V值假设原来是A，先修改成B，再修改回成A。当前线程的CAS操作无法分辨当前V值是否发生过变化。

举个例子1：

例一：你和女神一起喝茶，女神喝了一半去厕所了，你猥琐的喝了她剩下的半杯，然后又从你杯子里倒了半杯给她，女神回来后也不知道是否被人喝过。

如果觉得例子1太猥琐的话，请看例子2：

例二：

今天上午10:30:00：我银行卡有一万块钱，今天我来ATM机取5000块出来买比特币，但由于ATM机硬件问题，导致取款操作同时提交了两遍，后台开启了两个线程（线程1、线程2），两个线程都是获取当前值10000元，要更新成5000元；理想情况下，应该一个线程更新成功，一个线程更新失败，我的存款只扣除一次，也就是余额应为5000元 。

好巧不巧，也是今天上午10:30:00：侨总上次买币欠我5000块，经过我再三催债，表示再不还钱就把你买币的事儿告诉你媳妇！也正巧这个点儿，侨总给我转了5000元到卡里（线程3）。没想到这再正常不过的事儿，缺被ABA问题坑了！我可忍不了！

事情是这样的：

  1. 线程1首先执行成功，把余额10000更新为5000（取钱线程）。
  2. 同时线程2由于某种原因陷入了阻塞状态（取钱线程）。
  3. 这时候，（线程3）侨总汇款给了我5000元，执行成功，我的账户5000更新为10000元。
  4. 过一会儿，线程2恢复运行，由于之前阻塞的时候获得了当前值为：10000，并且经过compare检测，此时存款也的确是10000元，所以又成功把变量值从10000更新成了5000。
  5. 侨总：哈哥，5000给你打过去了！
  6. 我：查到账户只有5000，你他娘的糊弄老子呢？？
  7. 侨总：？？？我好几十个比特币的人，还在乎你这5000块钱了。。。

这就是经典的 A → B → A 问题，通过上面的例子，相信同学们也基本了解它的原理了。其实解决方式也很简单，比如例一，我们将每一次倒水假设有一个自动记录仪记录下，这样主人回来就可以分辨在她离开后是否发生过重新倒满的情况。这也是解决ABA问题目前采用的策略。

使用版本号，通过比较值 + 版本号才判断是否可以替换。这么看来如果要解决ABA问题，就需要在CAS基础上在增加一个版本号的校验，当值 + 版本号都相等时，才进行替换，其他部分均不变。

而在Java中，AtomicStampedReference类就实现了用版本号做比较的CAS机制。