20240116面试练习题6

1. 什么是乐观锁？乐观锁底层是如何实现的？

在多线程编程中，为了保证数据的一致性和线程安全，锁是必不可少的工具。锁可以分为两大类：乐观锁和悲观锁。乐观锁假设多个线程之间很少会发生冲突，因此在读取数据时不会加锁，而在更新数据时会检查是否有其他线程修改了数据。如果没有冲突，就执行更新操作；如果有冲突，则进行相应的处理。悲观锁则相反，它假设多个线程之间经常会发生冲突，因此在读取数据时会加锁，防止其他线程修改数据，直到操作完成后才释放锁。

乐观锁的实现方式有很多种，其中比较常见的有版本号和CAS（比较并交换）机制。
版本号方式：在数据库表中添加一个版本号字段，每次更新操作时都会将版本号加一。当线程要更新数据时，会先读取数据的版本号，然后进行更新操作，并将版本号加一。如果在更新过程中，有其他线程已经修改了数据，版本号就会不一致，此时更新操作会失败，需要进行重试。
CAS（比较并交换）机制：CAS是一种原子操作，它通过比较内存中的值和预期值是否相等来判断是否发生了其他线程的修改。如果相等，则将新值写入内存，否则重新读取数据进行重试。Java中的Atomic类就是基于CAS机制实现的乐观锁，比如AtomicInteger、AtomicLong等。

---

2. 什么是ABA问题？如何解决ABA问题？

乐观锁用到的机制就是CAS，Compare and Swap。
CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。

在运用CAS做Lock-Free操作中有一个经典的ABA问题：

线程1准备用CAS将变量的值由A替换为B，在此之前，线程2将变量的值由A替换为C，又由C替换为A，然后线程1执行CAS时发现变量的值仍然为A，所以CAS成功。但实际上这时的现场已经和最初不同了，尽管CAS成功，但可能存在潜藏的问题。

由于ABA问题带来的隐患，各种乐观锁的实现中通常都会用版本戳version来对记录或对象标记，避免并发操作带来的问题，在Java中，AtomicStampedReference也实现了这个作用，它通过包装[E,Integer]的元组来对对象标记版本戳stamp，从而避免ABA问题。

JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。如果当前引用 == 预期引用，并且当前标志等于预期标志，则以原子方式将该引用和该标志的值设置为给定的更新值。

---

3. ReentrantLock底层是如何实现的？

ReentrantLock的实现基于队列同步器（AbstractQueuedSynchronizer，后面简称AQS）
ReentrantLock的可重入功能基于AQS的同步状态：state。其原理大致为：当某一线程获取锁后，将state值+1，并记录下当前持有锁的线程，再有线程来获取锁时，判断这个线程与持有锁的线程是否是同一个线程，如果是，将state值再+1，如果不是，阻塞线程。 当线程释放锁时，将state值-1，当state值减为0时，表示当前线程彻底释放了锁，然后将记录当前持有锁的线程的那个字段设置为null，并唤醒其他线程，使其重新竞争锁。

---

4. 手写一个死锁代码？产生死锁的因素有哪些？

import java.util.concurrent.TimeUnit;
public class DeadLockTest {
    public static void main(String[] args) {
        Object lockA = new Object();
        Object lockB = new Object();
        // 创建线程 1
        Thread t1 = new Thread(() -> {
            // 1.占有锁 A
            synchronized (lockA) {
                System.out.println("线程1：获得锁A。");
                // 休眠 1s（让线程 2 有时间先占有锁 B）
                try {
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                // 2.获取线程 2 的锁 B
                synchronized (lockB) {
                    System.out.println("线程1：获得锁B。");
                }
            }
        });
        t1.start();
        // 创建线程 2
        Thread t2 = new Thread(() -> {
            // 1.占有锁 B
            synchronized (lockB) {
                System.out.println("线程2：获得锁B。");
                // 休眠 1s（保证线程 1 能有充足的时间得到锁 A）
                try {
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                // 2.获取线程 1 的锁 A
                synchronized (lockA) {
                    System.out.println("线程2：获得锁A。");
                }
            }
        });
        t2.start();
    }
}

死锁的产生需要满足以下 4 个条件：

互斥条件：指运算单元（进程、线程或协程）对所分配到的资源具有排它性，也就是说在一段时间内某个锁资源只能被一个运算单元所占用。
请求和保持条件：指运算单元已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它运算单元占有，此时请求运算单元阻塞，但又对自己已获得的其它资源保持不放。
不可剥夺条件：指运算单元已获得的资源，在未使用完之前，不能被剥夺。
环路等待条件：指在发生死锁时，必然存在运算单元和资源的环形链，即运算单元正在等待另一个运算单元占用的资源，而对方又在等待自己占用的资源，从而造成环路等待的情况。

---

5. 如何排查死锁？如何解决死锁？

Jstack命令
jstack是java虚拟机自带的一种堆栈跟踪工具。jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息。 Jstack工具可以用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。 线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。

JConsole工具
Jconsole是JDK自带的监控工具，在JDK/bin目录下可以找到。它用于连接正在运行的本地或者远程的JVM，对运行在Java应用程序的资源消耗和性能进行监控，并画出大量的图表，提供强大的可视化界面。而且本身占用的服务器内存很小，甚至可以说几乎不消耗。

破坏互斥条件：使得多个进程可以同时访问同一个资源。例如，在内存中缓存某些资源，从而避免频繁的磁盘读写。
破坏不可抢占条件：当一个进程所持有的资源被其它进程请求时，可以强制该进程放弃资源，或者等待它所持有的资源被释放后才能再次获取。
破坏请求与保持条件：进程在申请新资源之前先释放它所拥有的所有资源，等待新资源的分配，再重新申请先前持有的资源。
破坏循环等待条件：通过给资源编号，规定每个进程按编号的顺序请求资源，释放资源的顺序与请求的顺序相反，从而避免循环等待。
合理地设置超时时间：如果一个进程不能在一定时间内获得所需的所有资源，就应该释放已经获取的资源，以免造成系统资源的浪费。

---

6. Java 中乐观锁的实现类有哪些？悲观锁的实现类有哪些？

乐观锁的实现类：
CAS（比较并交换）机制：CAS是一种原子操作，它通过比较内存中的值和预期值是否相等来判断是否发生了其他线程的修改。如果相等，则将新值写入内存，否则重新读取数据进行重试。Java中的Atomic类就是基于CAS机制实现的乐观锁，比如AtomicInteger、AtomicLong等。

悲观锁的实现方式
悲观锁的实现方式相对简单粗暴，就是在读取数据时直接加锁，防止其他线程修改数据。常见的悲观锁实现方式包括使用synchronized关键字、ReentrantLock类等。

synchronized关键字：synchronized关键字是Java中最基本的锁机制，它可以用来修饰方法或代码块，保证同一时间只有一个线程可以执行被锁定的代码。
ReentrantLock类：ReentrantLock是Java中高级的锁机制，它提供了更灵活的锁定方式，可以实现公平锁和非公平锁，支持可重入特性，同时还可以配合条件变量等功能进行更复杂的线程同步操作。

---

7. Java 中除了乐观锁和悲观锁外还有哪些锁？

自旋锁
为了让线程等待，我们只须让线程执行一个忙循环（自旋）。
避免了线程切换的开销。挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给Java虚拟机的并发性能带来了很大的压力。

可重入锁（递归锁）
任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞。
通过组合自定义同步器来实现锁的获取与释放。识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取。获取锁后，进行计数自增，释放锁时，进行计数自减，避免死锁。
Java中的可重入锁： ReentrantLock、synchronized修饰的方法或代码段。

读写锁
通过ReentrantReadWriteLock类来实现。为了提高性能， Java 提供了读写锁，在读的地方使用读锁，在写的地方使用写锁，灵活控制，如果没有写锁的情况下，读是无阻塞的，在一定程度上提高了程序的执行效率。读写锁分为读锁和写锁，多个读锁不互斥，读锁与写锁互斥，这是由 jvm 自己控制的。

---

8. AtomicInteger 是线程安全的吗？它属于哪种锁类型？它存在 ABA 问题吗？如何解决这些问题？

是线程安全，AtomicInteger 保证线程安全使用乐观锁，所以相对于悲观锁，效率更高。
在有多个线程同时使用CAS操作一个变量时，只有一个会胜出并成功更新，其余均会失败。失败的线程不会被挂起，仅被告知失败，并且允许再次尝试，当然，也允许失败的线程放弃操作。
也存在ABA问题，解决：

AtomicStampedReference
1、创建 AtomicStampedReference, 并设置初始值100, 以及版本号0
2、为了模拟多线程并发抢占, 让线程二先获取到版本号。线程一睡眠50ms, 然后对value做出操作100->101, 101->100, 版本+1
3、线程二睡眠500ms, 等待线程一执行完毕, 开始将100->101, 版本号+1
不出意外, 线程二一定会修改失败, 虽然值相对应, 但是预期的版本号与 Pair 中的已不一致

AtomicMarkableReference
上面的版本号两次操作必须保持不一致, 得自增或、自减或者别的操作, 相对而言也比较繁琐。AtomicMarkableReference的API 接口以及实现思路与上述的基本一致, 只不过把版本号 int 类型替换为了 boolean 类型, 其它无区别

---

9. 什么是Semaphore？它有什么用？它的底层是如何实现的？

Semaphore 通常我们叫它信号量， 可以用来控制同时访问特定资源的线程数量，通过协调各个线程，以保证合理的使用资源。

可以把它简单的理解成我们停车场入口立着的那个显示屏，每有一辆车进入停车场显示屏就会显示剩余车位减1，每有一辆车从停车场出去，显示屏上显示的剩余车辆就会加1，当显示屏上的剩余车位为0时，停车场入口的栏杆就不会再打开，车辆就无法进入停车场了，直到有一辆车从停车场出去为止。

作用：
在 java 中，使用了 synchronized 关键字和 Lock 锁实现了资源的并发访问控制，在同一时间只允许唯一了线程进入临界区访问资源 (读锁除外)，这样子控制的主要目的是为了解决多个线程并发同一资源造成的数据不一致的问题。
在另外一种场景下，一个资源有多个副本可供同时使用，比如打印机房有多个打印机、厕所有多个坑可供同时使用，这种情况下，Java 提供了另外的并发访问控制 – 资源的多副本的并发访问控制，信号量 Semaphore 即是其中的一种。

底层实现：
semaphore 内部维护了一个计数器，其值为可以访问的共享资源的个数。一个线程要访问共享资源，先获得信号量，如果信号量的计数器值大于 1，意味着有共享资源可以访问，则使其计数器值减去 1，再访问共享资源。

如果计数器值为 0, 线程进入休眠。当某个线程使用完共享资源后，释放信号量，并将信号量内部的计数器加 1，之前进入休眠的线程将被唤醒并再次试图获得信号量。

就好比一个厕所管理员，站在门口，只有厕所有空位，就开门允许与空侧数量等量的人进入厕所。多个人进入厕所后，相当于 N 个人来分配使用 N 个空位。为避免多个人来同时竞争同一个侧卫，在内部仍然使用锁来控制资源的同步访问。

---

10. CountDownLatch 和 CyclicBarrier 有什么区别？

CountDownLatch 是不可以重置的，所以无法重用；而 CyclicBarrier 则没有这个限制，可以重用；
CountDownLatch 的基本操作组合是 countDown/await。调用 await 的线程阻塞等待 countDown 足够多的次数，不管你是在一个线程还是多个线程里 countDown，只要次数足够即可。
CyclicBarrier 的基本操作组合，则就是 await，当所有伙伴 （parties）都调用了 await，才会继续进行任务，并自动进行重置。
正常情况下，CyclicBarrier 的重置都是自动发生的，如果我们调用 reset 方法，但还有线程在等待，就会导致等待线程被打扰，抛出 BrokenBarrierException 异常。
CyclicBarrier 侧重点是线程，而不是调用事件，它的典型应用场景是用来等待并发线程结束。

---