juc包下你常用的类？ 线程池相关：
ThreadPoolExecutor ：最核心的线程池类，用于创建和管理线程池。通过它可以灵活地配置线程Executors ：线程池工厂类，提供了一系列静态方法来创建不同类型的线程池，如newFixedThreadPool （创建固定线程数的线程池）、newCachedThreadPool （创建可缓存线程池）、 newSingleThreadExecutor （创建单线程线程池）等，方便开发者快速创建线程池。
并发集合类：
ConcurrentHashMap ：线程安全的哈希映射表，用于在多线程环境下高效地存储和访问键值对。它采用了分段锁等技术，允许多个线程同时访问不同的段，提高了并发性能，在高并发场景下比传统的 Hashtable 性能更好。CopyOnWriteArrayList ：线程安全的列表，在对列表进行修改操作时，会创建一个新的底层数
同步工具类：
CountDownLatch ：允许一个或多个线程等待其他一组线程完成操作后再继续执行。它通过一个计数器来实现，计数器初始化为线程的数量，每个线程完成任务后调用 countDown 方法将计数器减一，当计数器为零时，等待的线程可以继续执行。常用于多个线程完成各自任务后，再进行汇总或下一步操作的场景。CyclicBarrier ：让一组线程互相等待，直到所有线程都到达某个屏障点后，再一起继续执行。与CountDownLatch 不同的是， CyclicBarrier 可以重复使用，当所有线程都通过屏障后，计数器会重置，可以再次用于下一轮的等待。适用于多个线程需要协同工作，在某个阶段完成后再一起进入下一个阶段的场景。Semaphore ：信号量，用于控制同时访问某个资源的线程数量。它维护了一个许可计数器，线程在访问资源前需要获取许可，如果有可用许可，则获取成功并将许可计数器减一，否则线程需要等待，直到有其他线程释放许可。常用于控制对有限资源的访问，如数据库连接池、线程池中的线程
原子类：
AtomicInteger ：原子整数类，提供了对整数类型的原子操作，如自增、自减、比较并交换等。通AtomicReference ：原子引用类，用于对对象引用进行原子操作。可以保证在多线程环境下，对对象的更新操作是原子性的，即要么全部成功，要么全部失败，不会出现数据不一致的情况。常用于实现无锁数据结构或需要对对象进行原子更新的场景。
怎么保证多线程安全？
synchronized关键字 :可以使用 synchronized 关键字来同步代码块或方法，确保同一时刻只有一个线程可以访问这些代码。对象锁是通过 synchronized 关键字锁定对象的监视器（monitor）来实现的。volatile关键字 : volatile 关键字用于变量，确保所有线程看到的是该变量的最新值，而不是可能存储在本地寄存器中的副本。Lock接口和ReentrantLock类 : java.util.concurrent.locks.Lock 接口提供了比synchronized 更强大的锁定机制， ReentrantLock 是一个实现该接口的例子，提供了更灵活的锁管理和更高的性能。原子类 ：Java并发库提供了原子类，如 AtomicInteger 、线程局部变量 : ThreadLocal 类可以为每个线程提供独立的变量副本，这样每个线程都拥有自己的变量，消除了竞争条件。并发集合 :使用 java.util.concurrent 包中的线程安全集合，如 ConcurrentHashMap 、ConcurrentLinkedQueue 等，这些集合内部已经实现了线程安全的逻辑。JUC工具类 : 使用 java.util.concurrent 包中的一些工具类可以用于控制线程间的同步和协作。例如： Semaphore 和 CyclicBarrier 等
Java中有哪些常用的锁，在什么场景下使用？ Java中的锁是用于管理多线程并发访问共享资源的关键机制。锁可以确保在任意给定时间内只有一个线程可以访问特定的资源，从而避免数据竞争和不一致性。Java提供了多种锁机制，可以分为以下几类：
内置锁 （synchronized）：Java中的 synchronized 关键字是内置锁机制的基础，可以用于方法或代码块。当一个线程进入 synchronized 代码块或方法时，它会获取关联对象的锁；当线程离开该代码块或方法时，锁会被释放。如果其他线程尝试获取同一个对象的锁，它们将被阻塞，直到锁被ReentrantLock ： java.util.concurrent.locks.ReentrantLock 是一个显式的锁类，提供了比 synchronized 更高级的功能，如可中断的锁等待、定时锁等待、公平锁选项等。ReentrantLock 使用 lock() 和 unlock() 方法来获取和释放锁。其中，公平锁按照线程请求锁的顺序来分配锁，保证了锁分配的公平性，但可能增加锁的等待时间。非公平锁不保证锁分配的顺序，可以减少锁的竞争，提高性能，但可能造成某些线程的饥饿。读写锁 （ReadWriteLock）： java.util.concurrent.locks.ReadWriteLock 接口定义了一种锁，允许多个读取者同时访问共享资源，但只允许一个写入者。读写锁通常用于读取远多于写入的乐观锁和悲观锁 ：
悲观锁通常指在访问数据前就锁定资源，假设最坏的情况，即数据很可能被其他线程修改。 synchronized 和 ReentrantLock 都是悲观锁的例子。
乐观锁通常不锁定资源，而是在更新数据时检查数据是否已被其他线程修改。乐观锁常使用版本号或时间戳来实现。
自旋锁 ：自旋锁是一种锁机制，线程在等待锁时会持续循环检查锁是否可用，而不是放弃CPU并阻塞。通常可以使用CAS来实现。这在锁等待时间很短的情况下可以提高性能，但过度自旋会浪费CPU资源。
CountDownLatch 是做什么的讲一讲？ CountDownLatch 是 Java 并发包中的一个同步工具类，用于让一个或多个线程等待其他线程完成操作后再继续执行。
初始化计数器 ：创建 CountDownLatch 时指定一个初始计数值（如 N ）。等待线程阻塞 ：调用 await() 的线程会被阻塞，直到计数器变为 0。任务完成通知 ：其他线程完成任务后调用 countDown() ，使计数器减 1。唤醒等待线程 ：当计数器减到 0 时，所有等待的线程会被唤醒。
synchronized和reentrantlock及其应用场景？ synchronized 工作原理 synchronized是Java提供的原子性内置锁，这种内置的并且使用者看不到的锁也被称为监视器锁，使用synchronized之后，会在编译之后在同步的代码块前后加上monitorenter和monitorexit字节码指令，他依赖操作系统底层互斥锁实现。他的作用主要就是实现原子性操作和解决共享变量的内存可见性问题。
执行monitorenter指令时会尝试获取对象锁，如果对象没有被锁定或者已经获得了锁，锁的计数器+1。
此时其他竞争锁的线程则会进入等待队列中。执行monitorexit指令时则会把计数器-1，当计数器值为0时，则锁释放，处于等待队列中的线程再继续竞争锁。
synchronized是排它锁，当一个线程获得锁之后，其他线程必须等待该线程释放锁后才能获得锁，而且由于Java中的线程和操作系统原生线程是一一对应的，线程被阻塞或者唤醒时时会从用户态切换到内核态，这种转换非常消耗性能。
从内存语义来说，加锁的过程会清除工作内存中的共享变量，再从主内存读取，而释放锁的过程则是将工作内存中的共享变量写回主内存。
如果再深入到源码来说，synchronized实际上有两个队列waitSet和entryList。
当多个线程进入同步代码块时，首先进入entryList
有一个线程获取到monitor锁后，就赋值给当前线程，并且计数器+1
如果线程调用wait方法，将释放锁，当前线程置为null，计数器-1，同时进入waitSet等待被唤醒，调用notify或者notifyAll之后又会进入entryList竞争锁
如果线程执行完毕，同样释放锁，计数器-1，当前线程置为null
reentrantlock工作原理 ReentrantLock 的底层实现主要依赖于 AbstractQueuedSynchronizer（AQS）这个抽象类。AQS 是一
ReentrantLock 在 AQS 的基础上通过内部类 Sync 来实现具体的锁操作。不同的 Sync 子类实现了公平锁和非公平锁的不同逻辑：
可中断性 ： ReentrantLock 实现了可中断性，这意味着线程在等待锁的过程中，可以被其他线程中断而提前结束等待。在底层，ReentrantLock 使用了与LockSupport.park() 和LockSupport.unpark() 相关的机制来实现可中断性。公平锁和非公平锁 ： 在直接创建 ReentrantLock 对象时，默认情况下是非公平锁。公平锁是按照线程等待的顺序来获取锁，而非公平锁则允许多个线程在同一时刻竞争锁，不考虑它们申请锁的顺序。公平锁可以通过在创建 ReentrantLock 时传入 true 来设置，多个条件变量 ： ReentrantLock 支持多个条件变量，每个条件变量可以与一个 ReentrantLock 关联。这使得线程可以更灵活地进行等待和唤醒操作，而不仅仅是基于对象监视器的 wait() 和notify()。多个条件变量的实现依赖于 Condition 接口可重入性 ： ReentrantLock 支持可重入性，即同一个线程可以多次获得同一把锁，而不会造成死锁。这是通过内部的 holdCount 计数来实现的。当一个线程多次获取锁时，holdCount 递增，释放锁时递减，只有当 holdCount 为零时，其他线程才有机会获取锁。
应用场景的区别 synchronized：
简单同步需求 ： 当你需要对代码块或方法进行简单的同步控制时，synchronized 是一个很好的选择。它使用起来简单，不需要额外的资源管理，因为锁会在方法退出或代码块执行完毕后自动释放。代码块同步 ： 如果你想对特定代码段进行同步，而不是整个方法，可以使用 synchronized 代码块。这可以让你更精细地控制同步的范围，从而减少锁的持有时间，提高并发性能。内置锁的使用 ： synchronized 关键字使用对象的内置锁（也称为监视器锁），这在需要使用对象作为锁对象的情况下很有用，尤其是在对象状态与锁保护的代码紧密相关时。
ReentrantLock：
高级锁功能需求 ： ReentrantLock 提供了 synchronized 所不具备的高级功能，如公平锁、响应中断、定时锁尝试、以及多个条件变量。当你需要这些功能时， ReentrantLock 是更好的选择。性能优化 ： 在高度竞争的环境中， ReentrantLock 可以提供比 synchronized 更好的性能，因为它提供了更细粒度的控制，如尝试锁定和定时锁定，可以减少线程阻塞的可能性。复杂同步结构 ： 当你需要更复杂的同步结构，如需要多个条件变量来协调线程之间的通信时，ReentrantLock 及其配套的 Condition 对象可以提供更灵活的解决方案。
综上， synchronized 适用于简单同步需求和不需要额外锁功能的场景，而 ReentrantLock 适用于需要更高级锁功能、性能优化或复杂同步逻辑的情况。选择哪种同步机制取决于具体的应用需求和性能考虑。
除了用synchronized，还有什么方法可以实现线程同步？
使用 ReentrantLock 类 ： ReentrantLock 是一个可重入的互斥锁，相比 synchronized 提供了更灵活的锁定和解锁操作。它还支持公平锁和非公平锁，以及可以响应中断的锁获取操作。使用 volatile 关键字 ：虽然 volatile 不是一种锁机制，但它可以确保变量的可见性。当一个变量被声明为 volatile 后，线程将直接从主内存中读取该变量的值，这样就能保证线程间变量的可见性。但它不具备原子性。使用 Atomic 类 ：Java提供了一系列的原子类，例如 AtomicInteger 、 AtomicLong 、AtomicReference 等，用于实现对单个变量的原子操作，这些类在实现细节上利用了CAS算法，可以用来实现无锁的线程安全
synchronized锁静态方法和普通方法区别？ 锁的对象不同 ：
普通方法 ：锁的是当前对象实例（ this ）。同一对象实例的 synchronized 普通方法，同一时间只能被一个线程访问；不同对象实例间互不影响，可被不同线程同时访问各自的同步普通方法。静态方法 ：锁的是当前类的 Class 对象。由于类的 Class 对象全局唯一，无论多少个对象实例，该静态同步方法同一时间只能被一个线程访问。
作用范围不同 ：
普通方法 ：仅对同一对象实例的同步方法调用互斥，不同对象实例的同步普通方法可并行执行。静态方法 ：对整个类的所有实例的该静态方法调用都互斥，一个线程进入静态同步方法，其他线程无法进入同一类任何实例的该方法。
多实例场景影响不同 ：
普通方法 ：多线程访问不同对象实例的同步普通方法时，可同时执行。静态方法 ：不管有多少对象实例，同一时间仅一个线程能执行该静态同步方法。
synchronized和reentrantlock区别？ synchronized 和 ReentrantLock 都是 Java 中提供的可重入锁：
用法不同 ：synchronized 可用来修饰普通方法、静态方法和代码块，而 ReentrantLock 只能用在代码块上。获取锁和释放锁方式不同 ：synchronized 会自动加锁和释放锁，当进入 synchronized 修饰的代码块之后会自动加锁，当离开synchronized 的代码段之后会自动释放锁。而 ReentrantLock 需要手动加锁和释放锁锁类型不同 ：synchronized 属于非公平锁，而 ReentrantLock 既可以是公平锁也可以是非公平锁。响应中断不同 ：ReentrantLock 可以响应中断，解决死锁的问题，而 synchronized 不能响应中底层实现不同 ：synchronized 是 JVM 层面通过监视器实现的，而 ReentrantLock 是基于 AQS 实现的。
怎么理解可重入锁？ 可重入锁是指同一个线程在获取了锁之后，可以再次重复获取该锁而不会造成死锁或其他问题。当一个线程持有锁时，如果再次尝试获取该锁，就会成功获取而不会被阻塞。
ReentrantLock实现可重入锁的机制是基于线程持有锁的计数器。
当线程释放锁时，计数器会相应地减1。只有当计数器减到0时，锁才会完全释放，其他线程才有机会获取锁。
这种计数器的设计使得同一个线程可以多次获取同一个锁，而不会造成死锁或其他问题。每次获取锁时，计数器加1；每次释放锁时，计数器减1。只有当计数器减到0时，锁才会完全释放。
ReentrantLock通过这种计数器的方式，实现了可重入锁的机制。它允许同一个线程多次获取同一个锁，并且能够正确地处理锁的获取和释放，避免了死锁和其他并发问题。
synchronized 支持重入吗？如何实现的? synchronized是基于原子性的内部锁机制，是可重入的，因此在一个线程调用synchronized方法的同时在其方法体内部调用该对象另一个synchronized方法，也就是说一个线程得到一个对象锁后再次请求该对象锁，是允许的，这就是synchronized的可重入性。
synchronized底层是利用计算机系统mutex Lock实现的。每一个可重入锁都会关联一个线程ID和一个锁状态status。
当一个线程请求方法时，会去检查锁状态。
如果锁状态是0，代表该锁没有被占用，使用CAS操作获取锁，将线程ID替换成自己的线程ID。
如果锁状态不是0，代表有线程在访问该方法。此时，如果线程ID是自己的线程ID，如果是可重入锁，会将status自增1，然后获取到该锁，进而执行相应的方法；如果是非重入锁，就会进入阻塞队列等待。在释放锁时，
如果是可重入锁的，每一次退出方法，就会将status减1，直至status的值为0，最后释放该锁。
如果非可重入锁的，线程退出方法，直接就会释放该锁
syncronized锁升级的过程讲一下 具体的锁升级的过程是：无锁->偏向锁->轻量级锁->重量级锁。
无锁 ：这是没有开启偏向锁的时候的状态，在JDK1.6之后偏向锁的默认开启的，但是有一个偏向延迟，需要在JVM启动之后的多少秒之后才能开启，这个可以通过JVM参数进行设置，同时是否开启偏向锁也可以通过JVM参数设置。偏向锁 ：这个是在偏向锁开启之后的锁的状态，如果还没有一个线程拿到这个锁的话，这个状态叫做匿名偏向，当一个线程拿到偏向锁的时候，下次想要竞争锁只需要拿线程ID跟MarkWord当中存储的线程ID进行比较，如果线程ID相同则直接获取锁（相当于锁偏向于这个线程），不需要进行CAS操作和将线程挂起的操作。轻量级锁 ：在这个状态下线程主要是通过CAS操作实现的。将对象的MarkWord存储到线程的虚拟机栈上，然后通过CAS将对象的MarkWord的内容设置为指向Displaced Mark Word的指针，如果设置成功则获取锁。在线程出临界区的时候，也需要使用CAS，如果使用CAS替换成功则同步成功，如果失败表示有其他线程在获取锁，那么就需要在释放锁之后将被挂起的线程唤醒。重量级锁 ：当有两个以上的线程获取锁的时候轻量级锁就会升级为重量级锁，因为CAS如果没有成功的话始终都在自旋，进行while循环操作，这是非常消耗CPU的，但是在升级为重量级锁之后，线程会被操作系统调度然后挂起，这可以节约CPU资源。
线程A进入 synchronized 开始抢锁，JVM 会判断当前是否是偏向锁的状态，如果是就会根据 Mark Word中存储的线程 ID 来判断，当前线程A是否就是持有偏向锁的线程。如果是，则忽略 check，线程A直接执行临界区内的代码。
但如果 Mark Word 里的线程不是线程 A，就会通过自旋尝试获取锁，如果获取到了，就将 Mark Word中的线程 ID 改为自己的;如果竞争失败，就会立马撤销偏向锁，膨胀为轻量级锁。
后续的竞争线程都会通过自旋来尝试获取锁，如果自旋成功那么锁的状态仍然是轻量级锁。然而如果竞争失败，锁会膨胀为重量级锁，后续等待的竞争的线程都会被阻塞。
JVM对Synchornized的优化？ synchronized 核心优化方案主要包含以下 4 个：
锁膨胀 ：synchronized 从无锁升级到偏向锁，再到轻量级锁，最后到重量级锁的过程，它叫做锁膨胀也叫做锁升级。JDK 1.6 之前，synchronized 是重量级锁，也就是说 synchronized 在释放和获取锁时都会从用户态转换成内核态，而转换的效率是比较低的。但有了锁膨胀机制之后，synchronized 的状态就多了无锁、偏向锁以及轻量级锁了，这时候在进行并发操作时，大部分的场景都不需要用户态到内核态的转换了，这样就大幅的提升了 synchronized 的性能。锁消除 锁粗化 ：将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁。自适应自旋锁 ：指通过自身循环，尝试获取锁的一种方式，优点在于它避免一些线程的挂起和恢复操作，因为挂起线程和恢复线程都需要从用户态转入内核态，这个过程是比较慢的，所以通过自旋的方式可以一定程度上避免线程挂起和恢复所造成的性能开销。
介绍一下AQS AQS全称为AbstractQueuedSynchronizer，是Java中的一个抽象类。 AQS是一个用于构建锁、同步器、协作工具类的工具类（框架）。
AQS核心思想是，如果被请求的共享资源空闲，那么就将当前请求资源的线程设置为有效的工作线程，将共享资源设置为锁定状态；如果共享资源被占用，就需要一定的阻塞等待唤醒机制来保证锁分配。这个机制主要用的是CLH队列的变体实现的，将暂时获取不到锁的线程加入到队列中。
CLH：Craig、Landin and Hagersten队列，是单向链表，AQS中的队列是CLH变体的虚拟双向队列（FIFO），AQS是通过将每条请求共享资源的线程封装成一个节点来实现锁的分配。
AQS使用一个Volatile的int类型的成员变量来表示同步状态，通过内置的FIFO队列来完成资源获取的排队工作，通过CAS完成对State值的修改。
可以看到： Sync 是 AQS 的实现。 AQS 主要完成的任务：
同步状态（比如说计数器）的原子性管理；
线程的阻塞和解除阻塞；
队列的管理。
AQS原理 AQS最核心的就是三大部分：
状态：state ；控制线程抢锁和配合的FIFO队列 （双向链表）；期望协作工具类去实现的获取/释放等重要方法 （重写）。
状态state :
这里state的具体含义，会根据具体实现类的不同而不同：比如在Semapore里，他表示剩余许可证的数量；在CountDownLatch里，它表示还需要倒数的数量；在ReentrantLock中，state用来表示“锁”的占有情况，包括可重入计数，当state的值为0的时候，标识该Lock不被任何线程所占有。
state是volatile修饰的，并被并发修改，所以修改state的方法都需要保证线程安全，比如getState、setState以及compareAndSetState操作来读取和更新这个状态。这些方法都依赖于unsafe类。
FIFO队列 :
这个队列用来存放“等待的线程，AQS就是“排队管理器”，当多个线程争用同一把锁时，必须有排队机制将那些没能拿到锁的线程串在一起。当锁释放时，锁管理器就会挑选一个合适的线程来占有这个刚刚释放的锁。
AQS会维护一个等待的线程队列，把线程都放到这个队列里，这个队列是双向链表形式。
实现获取/释放等方法 :
这里的获取和释放方法，是利用AQS的协作工具类里最重要的方法，是由协作类自己去实现的，并且含义各不相同；
获取方法 ：获取操作会以来state变量，经常会阻塞（比如获取不到锁的时候）。在Semaphore中，获取就是acquire方法，作用是获取一个许可证； 而在CountDownLatch里面，获取就是await方法，作用是等待，直到倒数结束；释放方法 ：在Semaphore中，释放就是release方法，作用是释放一个许可证； 在CountDownLatch里面，获取就是countDown方法，作用是将倒数的数减一；需要每个实现类重写tryAcquire和tryRelease等方法。
CAS 和 AQS 有什么关系？ CAS 和 AQS 两者的区别：
CAS 是一种乐观锁机制，它包含三个操作数：内存位置（V）、预期值（A）和新值（B）。CAS 操作的逻辑是，如果内存位置 V 的值等于预期值 A，则将其更新为新值 B，否则不做任何操作。整个过程是原子性的，通常由硬件指令支持，如在现代处理器上， cmpxchg 指令可以实现 CAS 操作。AQS 是一个用于构建锁和同步器的框架，许多同步器如 ReentrantLock 、 Semaphore 、CountDownLatch 等都是基于 AQS 构建的。AQS 使用一个 volatile 的整数变量 state 来表示同步状态，通过内置的 FIFO 队列来管理等待线程。它提供了一些基本的操作，如 acquire （获取资源）和 release （释放资源），这些操作会修改 state 的值，并根据 state 的值来判断线程是否可以获取或释放资源。AQS 的 acquire 操作通常会先尝试获取资源，如果失败，线程将被添加到等待队列中，并阻塞等待。 release 操作会释放资源，并唤醒等待队列中的线程。
CAS 和 AQS 两者的联系：
CAS 为 AQS 提供原子操作支持 ：AQS 内部使用 CAS 操作来更新 state 变量，以实现线程安全的状态修改。在 acquire 操作中，当线程尝试获取资源时，会使用 CAS 操作尝试将 state 从一个值更新为另一个值，如果更新失败，说明资源已被占用，线程会进入等待队列。在 release 操作中，当线程释放资源时，也会使用 CAS 操作将 state 恢复到相应的值，以保证状态更新的原子性。
如何用 AQS 实现一个可重入的公平锁？ AQS 实现一个可重入的公平锁的详细步骤：
继承 AbstractQueuedSynchronizer：创建一个内部类继承自AbstractQueuedSynchronizer ，重写 tryAcquire 、tryRelease 、 isHeldExclusively 等方法，这些方法将用于实现锁的获取、释放和判断锁是否被当前线程持有。
实现可重入逻辑：在 tryAcquire 方法中，检查当前线程是否已经持有锁，如果是，则增加锁的持有次数（通过 state 变量）；如果不是，尝试使用 CAS操作来获取锁。
实现公平性：在 tryAcquire 方法中，按照队列顺序来获取锁，即先检查等待队列中是否有线程在等待，如果有，当前线程必须进入队列等待，而不是直接竞争锁。
创建锁的外部类：创建一个外部类，内部持有AbstractQueuedSynchronizer 的子类对象，并提供 lock 和 unlock 方法，这些方法将调用AbstractQueuedSynchronizer 子类中的方法。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 import java.util.concurrent.locks.AbstractQueuedSynchronizer;import java.util.concurrent.locks.Condition;public class FairReentrantLock { private static class Sync extends AbstractQueuedSynchronizer { @Override protected boolean isHeldExclusively () { return getExclusiveOwnerThread() == Thread.currentThread(); } @Override protected boolean tryAcquire (int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0 ) { if (!hasQueuedPredecessors() && compareAndSetState(0 , acquires)) { setExclusiveOwnerThread(current); return true ; } } else if (current == getExclusiveOwnerThread()) { int nextc = c + acquires; if (nextc < 0 ) { throw new Error ("Maximum lock count exceeded" ); } setState(nextc); return true ; } return false ; } @Override protected boolean tryRelease (int releases) { int c = getState() - releases; if (Thread.currentThread() != getExclusiveOwnerThread()) { throw new IllegalMonitorStateException (); } boolean free = false ; if (c == 0 ) { free = true ; setExclusiveOwnerThread(null ); } setState(c); return free; } Condition newCondition () { return new ConditionObject (); } } private final Sync sync = new Sync (); public void lock () { sync.acquire(1 ); } public void unlock () { sync.release(1 ); } public boolean isLocked () { return sync.isHeldExclusively(); } public Condition newCondition () { return sync.newCondition(); } }
代码解释：
内部类 Sync：
isHeldExclusively ：使用 getExclusiveOwnerThread 方法检查当前锁是否被当前线程持有。
tryAcquire ：首先获取当前锁的状态 c 。
如果 c 为 0，表示锁未被持有，此时进行公平性检查，通过 hasQueuedPredecessors 检查是否有前驱节点在等待队列中。如果没有，使用 compareAndSetState 尝试将状态设置为acquires （通常为 1），并设置当前线程为锁的持有线程。
如果 c 不为 0，说明锁已被持有，检查是否为当前线程持有。如果是，增加锁的持有次数（可重入），但要防止溢出。
tryRelease ：先将状态减 releases （通常为 1）。检查当前线程是否为锁的持有线程，如果不是，抛出异常。如果状态减为 0，说明锁被完全释放，将持有线程设为 null 。
newCondition ：创建一个 ConditionObject 用于更复杂的同步操作，如等待 / 通知机制。
外部类 FairReentrantLock：
lock 方法：调用 sync.acquire(1) 尝试获取锁。
unlock 方法：调用 sync.release(1) 释放锁。
isLocked 方法：调用 sync.isHeldExclusively 判断锁是否被当前线程持有。
newCondition 方法：调用 sync.newCondition 提供条件变量
Threadlocal作用，原理，具体里面存的key value是啥，会有什么问题，如何解决? ThreadLocal 是Java中用于解决线程安全问题的一种机制，它允许创建线程局部变量，即每个线程都有自己独立的变量副本，从而避免了线程间的资源共享和同步问题。
从内存结构图，我们可以看到：
Thread类中，有个ThreadLocal.ThreadLocalMap 的成员变量。
ThreadLocal的作用
线程隔离 ： ThreadLocal 为每个线程提供了独立的变量副本，这意味着线程之间不会相互影响，可以安全地在多线程环境中使用这些变量而不必担心数据竞争或同步问题。降低耦合度 ：在同一个线程内的多个函数或组件之间，使用 ThreadLocal 可以减少参数的传递，降低代码之间的耦合度，使代码更加清晰和模块化。性能优势 ：由于 ThreadLocal 避免了线程间的同步开销，所以在大量线程并发执行时，相比传统的锁机制，它可以提供更好的性能。
ThreadLocal的原理 ThreadLocal 的实现依赖于 Thread 类中的一个ThreadLocalMap 字段，这是一个存储 ThreadLocal 变量本身和对应值的映射。每个线程都有自己的 ThreadLocalMap 实例，用于存储该线程所持有的所有ThreadLocal 变量的值。
当你创建一个 ThreadLocal 变量时，它实际上就是一ThreadLocal 对象的实例。每个 ThreadLocal对象都可以存储任意类型的值，这个值对每个线程来说是独立的。
如果有，返回该值；
如果没有，会调用 initialValue() 方法（如果重写了的话）来初始化该值，然后将其放入ThreadLocalMap 中并返回。
当调用 set() 方法时， ThreadLocal 会将给定的值与当前线程关联起来，即在当前线程的ThreadLocalMap 中存储一个键值对，键是 ThreadLocal 对象自身，值是传入的值。
当调用 remove() 方法时，会从当前线程的 ThreadLocalMap 中移除与该 ThreadLocal 对象关联的条目。
可能存在的问题 当一个线程结束时，其 ThreadLocalMap 也会随之销毁，但是 ThreadLocal 对象本身不会立即被垃圾回收，直到没有其他引用指向它为止。
因此，在使用 ThreadLocal 时需要注意，如果不显式调用 removE() 方法，或者线程结束时未正确清理ThreadLocal 变量，可能会导致内存泄漏，因为 ThreadLocalMap 会持续持有 ThreadLocal 变量的引用，即使这些变量不再被其他地方引用。
因此，实际应用中需要在使用完 ThreadLocal 变量后调用 removE() 方法释放资源。
悲观锁和乐观锁的区别？
乐观锁 ： 就像它的名字一样，对于并发间操作产生的线程安全问题持乐观状态，乐观锁认为竞争不总 是会发生，因此它不需要持有锁，将比较-替换这两个动作作为一个原子操作尝试去修改内存中的变量，如果失败则表示发生冲突，那么就应该有相应的重试逻辑。悲观锁 ： 还是像它的名字一样，对于并发间操作产生的线程安全问题持悲观状态，悲观锁认为竞争总是会发生，因此每次对某资源进行操作时，都会持有一个独占的锁，就像 synchronized，不管三七二十一，直接上了锁就操作资源了。
Java中想实现一个乐观锁，都有哪些方式？
CAS （Compare and Swap）操作： CAS 是乐观锁的基础。Java 提供了java.util.concurrent.atomic 包，包含各种原子变量类（如 AtomicInteger、AtomicLong），这些类使用 CAS 操作实现了线程安全的原子操作，可以用来实现乐观锁。版本号控 制：增加一个版本号字段记录数据更新时候的版本，每次更新时递增版本号。在更新数据时，同时比较版本号，若当前版本号和更新前获取的版本号一致，则更新成功，否则失败。时间戳 ：使用时间戳记录数据的更新时间，在更新数据时，在比较时间戳。如果当前时间戳大于数据的时间戳，则说明数据已经被其他线程更新，更新失败。
CAS 有什么缺点？ CAS的缺点主要有3点：
ABA问题 ：ABA的问题指的是在CAS更新的过程中，当读取到的值是A，然后准备赋值的时候仍然是A，但是实际上有可能A的值被改成了B，然后又被改回了A，这个CAS更新的漏洞就叫做ABA。只是ABA的问题大部分场景下都不影响并发的最终效果。Java中AtomicStampedReference来解决这个问题，他加入了预期标志和更新后标志两个字段，更新时不光检查值，还要检查当前的标志是否等于预期标志，全部相等的话才会更新。循环时间长开销大 ：自旋CAS的方式如果长时间不成功，会给CPU带来很大的开销。只能保证一个共享变量的原子操作 ：只对一个共享变量操作可以保证原子性，但是多个则不行，多个可以通过AtomicReference来处理或者使用锁synchronized实现。
为什么不能所有的锁都用CAS？ CAS操作是基于循环重试的机制，如果CAS操作一直未能成功，线程会一直自旋重试，占用CPU资源。在高并发情况下，大量线程自旋会导致CPU资源浪费。
CAS 有什么问题，Java是怎么解决的？ 会有 ABA 的问题，变量值在操作过程中先被其他线程从 A 修改为 B，又被改回 A，CAS 无法感知中途变化，导致操作误判为“未变更”。比如：
线程1读取变量为 A ，准备改为 C 。
此时线程2将变量 A → B → A 。
线程1的CAS执行时发现仍是 A ，但状态已丢失中间变化。
Java 提供的工具类会在 CAS 操作中增加版本号（Stamp）或标记，每次修改都更新版本号，使得即使值相同也能识别变更历史。比如，可以用 AtomicStampedReference 来解决 ABA 问题，通过比对值和版本号识别ABA问题。
voliatle关键字有什么作用？ volatite作用有 2 个：
保证变量对所有线程的可见性 。当一个变量被声明为volatile时，它会保证对这个变量的写操作会立即刷新到主存中，而对这个变量的读操作会直接从主存中读取，从而确保了多线程环境下对该变量访问的可见性。这意味着一个线程修改了volatile变量的值，其他线程能够立刻看到这个修改，不会受到各自线程工作内存的影响。
禁止指令重排序优化 。volatile关键字在Java中主要通过内存屏障来禁止特定类型的指令重排序。
写-写（Write-Write）屏障 ：在对volatile变量执行写操作之前，会插入一个写屏障。这确保了在该变量写操作之前的所有普通写操作都已完成，防止了这些写操作被移到volatile写操作之后。读-写（Read-Write）屏障 ：在对volatile变量执行读操作之后，会插入一个读屏障。它确保了对volatile变量的读操作之后的所有普通读操作都不会被提前到volatile读之前执行，保证了读取到的数据是最新的。写-读（Write-Read）屏障 ：这是最重要的一个屏障，它发生在volatile写之后和volatile读之前。这个屏障确保了volatile写操作之前的所有内存操作（包括写操作）都不会被重排序到volatile读之后，同时也确保了volatile读操作之后的所有内存操作（包括读操作）都不会被重排序到volatile写之前
指令重排序的原理是什么？ 在执行程序时，为了提高性能，处理器和编译器常常会对指令进行重排序，但是重排序要满足下面 2 个条件才能进行：
在单线程环境下不能改变程序运行的结果
存在数据依赖关系的不允许重排序。
所以重排序不会对单线程有影响，只会破坏多线程的执行语义。
我们看这个例子，A和C之间存在数据依赖关系，同时B和C之间也存在数据依赖关系。因此在最终执行的指令序列中，C不能被重排序到A和B的前面，如果C排到A和B的前面，那么程序的结果将会被改变。但A和B之间没有数据依赖关系，编译器和处理器可以重排序A和B之间的执行顺序
volatile可以保证线程安全吗？ volatile关键字可以保证可见性，但不能保证原子性，因此不能完全保证线程安全。volatile关键字用于修饰变量，当一个线程修改了volatile修饰的变量的值，其他线程能够立即看到最新的值，从而避免了线程之间的数据不一致。
但是，volatile并不能解决多线程并发下的复合操作问题，比如i++这种操作不是原子操作，如果多个线程同时对i进行自增操作，volatile不能保证线程安全。对于复合操作，需要使用synchronized关键字或者Lock来保证原子性和线程安全。
volatile和sychronized比较？ Synchronized解决了多线程访问共享资源时可能出现的竞态条件和数据不一致的问题，保证了线程安全性。Volatile解决了变量在多线程环境下的可见性和有序性问题，确保了变量的修改对其他线程是可见
Synchronized : Synchronized是一种排他性的同步机制，保证了多个线程访问共享资源时的互斥性，即同一时刻只允许一个线程访问共享资源。通过对代码块或方法添加Synchronized关键字来实现同步。Volatile : Volatile是一种轻量级的同步机制，用来保证变量的可见性和禁止指令重排序。当一个变量被声明为Volatile时，线程在读取该变量时会直接从内存中读取，而不会使用缓存，同时对该变量的写操作会立即刷回主内存，而不是缓存在本地内存中。
什么是公平锁和非公平锁？
公平锁 ： 指多个线程按照申请锁的顺序来获取锁，线程直接进入队列中排队，队列中的第一个线程才能获得锁。公平锁的优点在于各个线程公平平等，每个线程等待一段时间后，都有执行的机会，而它的缺点就在于整体执行速度更慢，吞吐量更小。非公平锁 ： 多个线程加锁时直接尝试获取锁，能抢到锁到直接占有锁，抢不到才会到等待队列的队尾等待。非公平锁的优势就在于整体执行速度更快，吞吐量更大，但同时也可能产生线程饥饿问题，也就是说如果一直有线程插队，那么在等待队列中的线程可能长时间得不到运行
非公平锁吞吐量为什么比公平锁大？
公平锁执行流程 ：获取锁时，先将线程自己添加到等待队列的队尾并休眠，当某线程用完锁之后，会去唤醒等待队列中队首的线程尝试去获取锁，锁的使用顺序也就是队列中的先后顺序，在整个过程中，线程会从运行状态切换到休眠状态，再从休眠状态恢复成运行状态，但线程每次休眠和恢复都需要从用户态转换成内核态，而这个状态的转换是比较慢的，所以公平锁的执行速度会比较慢。非公平锁执行流程 ：当线程获取锁时，会先通过 CAS 尝试获取锁，如果获取成功就直接拥有锁，如果获取锁失败才会进入等待队列，等待下次尝试获取锁。这样做的好处是，获取锁不用遵循先到先得的规则，从而避免了线程休眠和恢复的操作，这样就加速了程序的执行效率。
Synchronized是公平锁吗？ Synchronized不属于公平锁，ReentrantLock是公平锁。
ReentrantLock是怎么实现公平锁的？ 公平锁与非公平锁的 lock() 方法唯一的区别就在于公平锁在获取锁时多了一个限制条件：hasQueuedPredecessors() 为 false，这个方法就是判断在等待队列中是否已经有线程在排队了。
这也就是公平锁和非公平锁的核心区别，如果是公平锁，那么一旦已经有线程在排队了，当前线程就不再尝试获取锁；对于非公平锁而言，无论是否已经有线程在排队，都会尝试获取一下锁，获取不到的话，再去排队。这里有一个特例需要我们注意，针对 tryLock() 方法，它不遵守设定的公平原则。
例如，当有线程执行 tryLock() 方法的时候，一旦有线程释放了锁，那么这个正在 tryLock 的线程就能获取到锁，即使设置的是公平锁模式，即使在它之前已经有其他正在等待队列中等待的线程，简单地说就是 tryLock 可以插队。
看它的源码就会发现：
1 2 3 public boolean tryLock () { return sync.nonfairTryAcquire(1 ); }
这里调用的就是 nonfairTryAcquire()，表明了是不公平的，和锁本身是否是公平锁无关。综上所述，公平锁就是会按照多个线程申请锁的顺序来获取锁，从而实现公平的特性。
非公平锁加锁时不考虑排队等待情况，直接尝试获取锁，所以存在后申请却先获得锁的情况，但由此也提高了整体的效率。
什么情况会产生死锁问题？如何解决？ 死锁只有同时满足以下四个条件才会发生：
互斥条件 ：互斥条件是指多个线程不能同时使用同一个资源。持有并等待条件 ：持有并等待条件是指，当线程 A 已经持有了资源 1，又想申请资源 2，而资源 2已经被线程 C 持有了，所以线程 A 就会处于等待状态，但是线程 A 在等待资源 2 的同时并不会释放自己已经持有的资源 1。不可剥夺条件 ：不可剥夺条件是指，当线程已经持有了资源 ，在自己使用完之前不能被其他线程获取，线程 B 如果也想使用此资源，则只能在线程 A 使用完并释放后才能获取。环路等待条件 ：环路等待条件指的是，在死锁发生的时候，两个线程获取资源的顺序构成了环形链
例如，线程 A 持有资源 R1 并试图获取资源 R2，而线程 B 持有资源 R2 并试图获取资源 R1，此时两个线程相互等待对方释放资源，从而导致死锁。
避免死锁问题就只需要破环其中一个条件就可以，最常见的并且可行的就是使用资源有序分配法，来破环环路等待条件。
那什么是资源有序分配法呢？
线程 A 和 线程 B 获取资源的顺序要一样，当线程 A 是先尝试获取资源 A，然后尝试获取资源 B 的时候，线程 B 同样也是先尝试获取资源 A，然后尝试获取资源 B。也就是说，线程 A 和 线程 B 总是以相同的顺序申请自己想要的资源。