多线程面试看这一篇就够了

1. AtomicLong底层实现原理

AtomicLong 是 Java 并发包中的一个类，它提供了一种线程安全的方式来进行长整型数据的原子操作。其底层实现依赖于底层硬件的
CAS（Compare and Swap）指令或者类似的原子性操作。

下面是 AtomicLong 的主要实现原理：

内部值：AtomicLong 内部使用一个 volatile 修饰的 long 型变量来存储数值。这个变量用于保存被操作的长整型值。

CAS 操作：AtomicLong 使用 CAS 操作来实现原子性。CAS
是一种基于硬件的原子操作，可以在多线程环境下实现对共享变量的原子访问。CAS
操作包括三个参数：内存地址、预期值和新值。如果当前内存地址上的值与预期值相等，则将新值写入该内存地址；否则，不做任何操作。CAS
操作是无锁的，因此可以避免传统锁机制带来的性能开销。

循环重试：由于 CAS 操作可能存在竞争条件，当多个线程同时尝试执行 CAS 操作时，只有一个线程能够成功。如果某个线程的 CAS
操作失败，它会通过循环重试的方式再次尝试，直到成功为止。

Unsafe 类：AtomicLong 使用 sun.misc.Unsafe 类来实现底层的 CAS 操作。 Unsafe
类提供了一些底层操作，如直接访问内存、修改对象字段等。这个类在 JDK 中并不是公共 API，因此使用时需要谨慎。

通过上述原理，AtomicLong
能够提供一个线程安全的长整型数据操作方式。它可以保证对变量的读写操作具有原子性，并且能够利用底层硬件的原子指令或者类似机制来达到高效的并发处理。这使得
AtomicLong 成为在多线程环境下进行原子操作的理想选择。

2. 高并发下 lock为何比synchronized性能好

在高并发场景下，Lock 比 synchronized 的性能好的原因主要包括以下几个方面：

粒度控制：synchronized 是使用 JVM 内置的锁机制，对整个对象进行加锁。而 Lock 接口的实现类（如
ReentrantLock）提供了更细粒度的控制，可以只对特定代码块进行加锁，从而减小了锁的粒度，提高了并发性能。

可中断性：Lock 接口提供了可中断的加锁操作。在某些场景下，如果一个线程在等待锁时需要被中断，使用 Lock 可以通过调用
lockInterruptibly() 方法来实现。而 synchronized 在等待锁时无法响应中断，只能一直等待或者抛出异常。

公平性选择：Lock
接口的实现类可以选择是公平锁还是非公平锁。公平锁会根据线程等待的时间先后顺序来分配锁资源，而非公平锁则不保证线程获取锁的顺序。这使得
Lock 在处理高并发场景下能够更灵活地选择适合的锁策略，从而提高了吞吐量。

条件变量支持：Lock 接口提供了条件变量的支持，通过使用 Condition
对象，可以实现更细粒度的线程等待和唤醒操作。这使得在复杂的线程协作场景中，使用 Lock 可以更加灵活地控制线程的执行顺序。

需要注意的是，尽管 Lock 在高并发场景下通常比 synchronized 更高效，但也并不意味着在所有情况下都一定优于
synchronized。实际性能还会受到具体实现、代码质量、竞争程度等因素的影响。在开发中，根据具体需求和场景选择合适的同步机制是很重要的。

补充：https://blog.csdn.net/Firstlucky77/article/details/125173318