面试考点分析是否具备系统化的知识结构能否从多个维度如是否共享、是否可重入、是否公平等对 Java 锁进行分类与辨析。考察关键字synchronized的锁升级过程偏向锁→轻量级锁→重量级锁以及 JUC 包下 AQS 框架的工作原理。在特定业务场景下如读多写少、高并发计数等进行锁选型的能力能否区分ReentrantReadWriteLock和StampedLock的适用场景。是否遇到过死锁、锁粗化/消除、惊群效应等线上问题并有对应的排查与优化思路。在 Spring、MyBatis、Netty 等主流框架中锁的具体应用考察知识广度。1. 标准回答在 Java 并发编程中锁Lock是协调多线程访问共享资源的关键机制。Java 提供了丰富的锁实现我们可以从不同的维度进行划分分类维度锁名称核心特性核心接口/类是否共享互斥锁 / 独占锁同一时刻只允许一个线程持有锁。synchronizedReentrantLock共享锁允许多个线程同时持有锁如读锁。ReentrantReadWriteLock的读锁是否可重入可重入锁同一线程可再次获取已持有的锁避免死锁。synchronizedReentrantLock不可重入锁线程获取锁后再次尝试获取会被阻塞。StampedLock的写锁非典型可重入是否公平公平锁按线程等待时间顺序分配锁先到先得。ReentrantLock(true)非公平锁允许插队吞吐量通常更高。synchronizedReentrantLock(false)锁优化JDK 内部偏向锁 / 轻量级锁 / 重量级锁synchronized在 JVM 层面的锁升级路径旨在降低锁开销。JVM 自动优化是否可中断可中断锁等待锁时可响应Thread.interrupt()。ReentrantLock.lockInterruptibly()不可中断锁一旦开始等待锁必须获取到锁才能继续。synchronized乐观/悲观悲观锁假设并发冲突总会发生先获取锁再操作数据。synchronized,ReentrantLock乐观锁假设不加锁直接操作更新时校验数据是否被修改。CAS 算法AtomicInteger/StampedLock的乐观读一句话回答Java 的锁体系可以分为synchronized 关键字和JUC 锁框架两大流派。选择锁时需要权衡并发度、读写比例、持有锁时长和 API 灵活性读多写少场景优先选StampedLock或ReentrantReadWriteLock简单同步代码块用synchronized即可需要可中断、超时或尝试加锁等高级特性时选择ReentrantLock。2. 核心原理要深刻理解 Java 锁的选择必须先掌握其底层工作原理。核心分为两部分JVM 层面 synchronized 的锁升级机制和JDK 层面 AQS 框架的精妙设计。2.1 synchronized 的锁升级路径synchronized在 JDK 1.6 之后引入了革命性的优化锁升级。一个对象的 Mark Word 会经历从无锁 → 偏向锁 → 轻量级锁 → 重量级锁的不可逆升级过程。偏向锁JVM 认为大多数情况下锁不存在多线程竞争且总是由同一个线程多次获得。因此当线程首次获取锁时在对象头 Mark Word 中记录该线程 ID后续该线程进入同步块时无需任何同步操作直接进入。轻量级锁当另一个线程尝试获取偏向锁发现偏向线程 ID 不是自己时偏向锁升级为轻量级锁。竞争线程通过自旋CAS 循环方式尝试获取锁避免了线程阻塞/唤醒带来的系统调用开销。适用于线程持有锁时间短的场景。重量级锁如果自旋等待的线程数超过一个阈值默认自旋10次或CPU核数一半或者一个线程自旋时第三个线程又来了则膨胀为重量级锁。此锁依赖操作系统底层的Mutex Lock实现未获取锁的线程会进入阻塞状态不再消耗 CPU但线程状态的切换成本很高。2.2 AQS抽象队列同步器与 CLH 锁JUC 包下的大多数锁如ReentrantLock,ReentrantReadWriteLock都是基于AQS框架构建的。其核心思想是如果共享资源空闲则请求线程获取锁并执行如果被占用则将线程包装成节点Node放入一个虚拟的CLH 同步队列中进行排队。State 状态变量AQS 内部维护了一个volatile int state变量代表共享资源的状态。例如在ReentrantLock中state0表示未锁定state1表示已锁定state1表示重入的次数。同步队列基于节点的双向链表。当线程获取锁失败时被包装成独占模式Node.EXCLUSIVE或共享模式Node.SHARED的节点追加到队尾。LockSupport使用LockSupport.park()原生方法阻塞/唤醒线程比Object.wait()/notify()更精确、灵活支持超时和中断响应。3. 应用场景与主流技术落地3.1 日常开发选型指南synchronized— 简单互斥场景的首选最基础的互斥需求如计数器自增、懒加载单例模式、小型生产-消费模型等。优势使用简单JVM 自动优化锁释放由异常自动完成。ReentrantLock— 需要高级特性的复杂控制适用于需要公平锁机制如任务调度器避免线程饥饿、可中断等待防止死锁恢复或尝试加锁如超时放弃的场景。ReentrantReadWriteLock— 读多写少的集合守卫典型场景是保护一个过期缓存Cache。例如从 DB 加载配置项允许无限线程并发读但只允许一个线程在有修改时更新。StampedLock— 高性能读写操作JDK 8在读远大于写的场景如指标收集、数据报表使用StampedLock的乐观读替代全量读锁可避免写线程饥饿大幅提升吞吐量。原子类乐观锁 — 单个变量高并发更新如AtomicLong、LongAdder用于统计网站 QPS、接口调用次数。基于 CAS 实现是无锁化编程的最佳实践。3.2 主流技术框架中的锁应用LinkedIn Kafka高性能读写锁Kafka 的日志段LogSegment读取是典型的读多写少场景。为了在高并发消费时不阻塞其早期版本使用了ReentrantReadWriteLock保护索引文件的读写操作。Netflix Hystrix信号量与线程隔离Hystrix 的线程隔离模式本质上将不同服务的请求分配到不同的线程池但单个线程池内的任务协调依赖 JUC 的锁机制保证状态流转。Elasticsearch跨版本锁实现线程安全在 ES 的索引刷新refresh和段合并merge过程中大量使用了ReentrantLock来保证内部数据结构的安全访问同时结合 CAS 实现无锁的事务日志Translog写入。MyBatis 缓存模块MyBatis 的一二级缓存底层是基于ConcurrentHashMap的它在 JDK 1.8 中大量使用 CAS 和细粒度的 synchronized 块来实现高效并发。而BlockingCache的实现则直接继承自ReentrantLock以确保在有缓存 miss 时只有一个线程去查询数据库。4. 使用方式4.1 synchronized — 关键字加持的最简同步public class SyncExample { private final Object lock new Object(); // 同步代码块 - 使用显示锁对象避免外部侵入 public void doSomething() { synchronized (lock) { // 临界区代码 System.out.println(Current Thread: Thread.currentThread().getName()); } } // 同步实例方法 - 锁即为当前实例对象 this public synchronized void syncMethod() { // 业务逻辑等价于 synchronized(this){...} } // 同步静态方法 - 锁为当前类的 Class 对象全局锁 public static synchronized void syncStaticMethod() { // 会影响该类的所有实例方法 } }4.2 ReentrantLock — 高级锁特性的利器import java.util.concurrent.locks.ReentrantLock; public class ReentrantLockExample { // 默认非公平传 true 为公平锁 private final ReentrantLock lock new ReentrantLock(); public void performWithTimeout() { boolean isLocked false; try { // 尝试加锁等待 800 毫秒仍失败则放弃 isLocked lock.tryLock(800, java.util.concurrent.TimeUnit.MILLISECONDS); if (isLocked) { // 成功加锁后执行操作 processData(); } else { // 超时处理逻辑防止死等 handleFallback(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 恢复中断状态 // 处理中断逻辑 } finally { if (isLocked) { lock.unlock(); // 必须在 finally 块中释放 } } } private void processData() { /* 核心业务 */ } private void handleFallback() { /* 降级处理 */ } }4.3 StampedLock — 读写与乐观读的吞吐之王import java.util.concurrent.locks.StampedLock; public class StampedLockExample { private double x, y; private final StampedLock sl new StampedLock(); // 排他性写锁 - 必须等待所有读锁释放 public void move(double deltaX, double deltaY) { long stamp sl.writeLock(); // 获取写锁 try { x deltaX; y deltaY; } finally { sl.unlockWrite(stamp); } } // 乐观读 - 真正实现无锁读取大幅提升吞吐量 public double distanceFromOrigin() { long stamp sl.tryOptimisticRead(); // 1. 获取乐观读戳记 // 2. 无锁地读取变量到本地存储 double currentX x, currentY y; // 3. 校验戳记如果期间有写发生则回退为悲观读锁 if (!sl.validate(stamp)) { stamp sl.readLock(); // 升级为悲观读锁 try { currentX x; currentY y; } finally { sl.unlockRead(stamp); } } return java.lang.Math.sqrt(currentX * currentX currentY * currentY); } }4.4 LongAdder — 高并发计数的最优解import java.util.concurrent.atomic.LongAdder; public class CounterService { // 替代 AtomicLong 作为高并发场景下的实时计数器 private final LongAdder requestCount new LongAdder(); public void handleRequest(String request) { // 业务处理... // 统计请求量高并发下性能远优于 AtomicLong requestCount.increment(); } public long getTotalRequests() { // 求和操作通常用于低频的监控数据采集 return requestCount.sum(); } }5. 扩展延伸5.1 锁降级与锁升级锁降级Lock DowngradeReentrantReadWriteLock支持从写锁降级为读锁。即在持有写锁时直接获取读锁再释放写锁。这是防止数据可见性问题的关键手段保证了在修改后能平滑切换到只读状态而不丢失修改。锁升级Lock Upgrade不支持也不建议这样做。从读锁直接升级为写锁会造成死锁。5.2 读写锁中的饥饿与优化ReentrantReadWriteLock默认是非公平的如果读线程过多而写线程较少写线程可能永远获取不到锁即写线程饥饿。此时应使用StampedLock替代。StampedLock的读锁并非标准的重入锁它提供了一种“乐观读”模式对写线程更友好是ReentrantReadWriteLock的高性能替代品。5.3 原子变量与分段累加AtomicLong在多线程下通过不断 CAS 自旋尝试修改一个单一值竞争激烈时性能会下降。LongAdder内部维护了一个Cell[]动态分段的思想将并发更新的压力分散到不同槽位最终通过sum()汇总。这是典型的空间换时间策略。6. 面试追问与回答思路1. 说说 synchronized 和 ReentrantLock 的区别考点分析锁种类选择、语法差异、原理理解。优质回答思路维度对比法从原始/实现、灵活性、性能、条件变量四个维度展开。重点强调ReentrantLock的可中断、超时、公平锁等高级特性而synchronized异常自动释放锁的可靠性。在低竞争度JDK 1.8场景下两者性能几乎一致。2. 什么是死锁如何定位和避免考点分析死锁四大条件、线上实战排查、编码习惯。优质回答思路口述死锁的四个必要条件互斥、占有且等待、不可剥夺、环路等待及如何打破。然后给出线上排查的三板斧①jpsjstack分析线程 dump直接查看Found one Java-level deadlock② 严格约定资源申请顺序如银行家算法③ 使用ReentrantLock.tryLock(timeout)避免无限期等待。3. ReentrantReadWriteLock 的读锁是共享的吗有什么问题考点分析AQS 共享模式原理、并发坑点。优质回答思路先明确回答读锁是共享锁。然后点明其最大痛点是可能造成写线程饥饿并引出StampedLock。额外加分点提到锁降级的必要性并给出代码示例别把锁降级误说成锁升级。4. 请解释一下 CAS 的原理及 ABA 问题考点分析乐观锁实现、原子类底层、并发漏洞。优质回答思路CAS 三要素内存值 V、旧的预期值 A、准备设置的新值 B。当 VA 时更新为 B否则自旋。原理清晰后ABA 问题变量被 A→B→A 修改后 CAS 无法感知。可通过增加AtomicStampedReference携带版本号戳解决并简述其底层实现为版本 引用 Pair 的自旋。7. 总结与选型思维导图根据以上原理、场景和代码示例的剖析我们可以得出以下选型结论表建议收藏业务场景推荐锁机制理由简单互斥保护代码块synchronized语法简单性能足够JVM 层面最优化。需尝试/可中断/超时等待ReentrantLock提供tryLock,lockInterruptibly等灵活 API。读多写少的配置/缓存守卫ReentrantReadWriteLock读写分离允许高并发读只有写时互斥。JDK 8 极致吞吐读写分离StampedLock乐观读避免锁开销读写互斥更严格避免写饥饿。超高频的数值统计与监控打点LongAdder分段累加空间换时间QPS 统计远超AtomicLong。