你知道锁的实现方式么

首次来源：京东 2021 一面整理

原题

你知道锁的实现方式么

完整讲解（权威版）

最后更新：2026-10-30 · 基于第 1 次作答

L1 · 30 秒速记

结论：锁分两层——JVM 级（synchronized / AQS）与分布式（Redis / ZooKeeper），面试先分清层级再讲实现。 关键词：synchronized · AQS · 锁升级 · Redisson · 看门狗 边界：JVM 锁只能管单机；跨进程必须分布式锁。

L2 · 核心讲解

核心考点定位：面试官想听的是"你分的清单机锁和分布式锁 + 每种锁的底层机制"，重点是锁升级链路与分布式锁的可靠性。

机制链（≥3 环）：

1. 分层 → 单机锁管进程内线程（synchronized、ReentrantLock/AQS）；分布式锁管跨进程/跨服务（Redis、ZK）。
2. synchronized → 基于对象头 Mark Word + monitor；从偏向锁 → 轻量级锁（CAS）→ 重量级锁（内核互斥）升级。
3. AQS → ReentrantLock 基于 state + CLH 队列 + CAS；公平/非公平由队列判据区分。
4. 分布式 → Redisson tryLock（SETNX + 过期 + watchdog 续期）或 ZooKeeper 临时节点 + 监听。
5. 锁升级 → 无锁→偏向（记录线程ID）→轻量（CAS 自旋）→重量（互斥量），单向不可逆，竞争加剧才升级。

证据锚点：

• Mark Word：锁状态记录在对象头，无锁/偏向/轻量/重量由最后两位标志。
• 偏向锁：只有一个线程访问，记录线程 ID，CAS 加锁；竞争时升级。
• CLH 队列：AQS 的等待队列，线程挂起排队，前驱释放后唤醒后继。
• state：AQS 同步状态，0 无锁，>0 有锁（可重入计数）。
• Redisson watchdog：锁默认 30s 过期，看门狗每 1/3 时间续期，防业务超时锁自动释放。
• hasQueuedPredecessors：公平锁先判断队列是否已有等待线程，有则排队。
• SETNX：Redis 分布式锁原子占位命令，需配过期时间防死锁。
• 临时顺序节点：ZK 锁用临时节点 + 序号，客户端断开自动删除，天然可重入公平。
• monitor：synchronized 底层的管程对象，进入/退出成对，可重入。

对比与权衡：

锁	层级	公平	底层	适用
synchronized	JVM	否	Mark Word + monitor + 升级	同步块/方法，简单
ReentrantLock	JVM	可配	AQS state + CLH	可中断/超时/条件
Redisson 锁	分布式	否	SETNX + 过期 + watchdog	跨进程互斥
ZooKeeper 锁	分布式	是	临时顺序节点	强一致、高可靠

常见误区：

1. 错误：把 synchronized 说成"一直重量级锁" → 正确：偏向→轻量→重量升级 → 为什么：无竞争时是偏向/轻量，很轻。
2. 错误：分布式锁只用 SETNX 不加过期 → 正确：必须过期时间 + 看门狗续期 → 为什么：防宕机死锁。
3. 错误：把 JVM 锁当分布式锁 → 正确：跨进程必须分布式锁 → 为什么：JVM 锁管不了别的进程。
4. 错误：非公平锁一定比公平锁差 → 正确：非公平锁吞吐更高，公平锁更少饥饿 → 为什么：非公平直接 CAS 抢，少挂起唤醒。
5. 错误：锁升级可以降级 → 正确：升级单向不可逆 → 为什么：撤销偏向锁成本高，不轻易回退。

适用边界：分布式锁在业务超时 > 锁过期时需看门狗续期；ZK 锁性能低于 Redis 但更可靠；锁粒度要尽量小。

延伸追问（≥3）

1. synchronized 锁升级过程？

• 要点：无锁 → 偏向（记录线程ID）→ 轻量级（CAS 自旋）→ 重量级（互斥量），单向不可逆。
• 追问落点：什么情况触发偏向锁撤销、轻量级自旋失败升级。

1. AQS 的公平锁与非公平锁区别？

• 要点：公平锁先查 hasQueuedPredecessors 是否有人排队；非公平锁直接 CAS 抢。
• 追问落点：非公平锁为什么吞吐更高（减少线程挂起）。

1. Redisson 锁的看门狗机制？

• 要点：默认 30s 过期，watchdog 定时续期；业务未完成锁自动续，防中途释放。
• 追问落点：为什么不设过期会死锁、设置太短业务没完成。

面试者参考回答（400–700 字）

【结论】 面试官您好，锁要分清两层——JVM 级锁管进程内线程，分布式锁管跨进程，这是回答的起点。

【三点】 第一，Java 锁主要是 synchronized 和 ReentrantLock（AQS）。synchronized 基于对象头 Mark Word 和 monitor，并且会升级：无竞争时是偏向锁（记录线程 ID），有竞争变轻量级锁（CAS 自旋），自旋失败才升级重量级锁（内核互斥量），所以无竞争时很轻。ReentrantLock 基于 AQS，用 state 记录持有次数、CAS 更新状态、CLH 队列挂起等待线程，支持公平/非公平、可中断、超时、条件变量，比 synchronized 更灵活但代码更繁琐。第二，这两者都只控制单机内线程，分布式部署后其他进程的线程控制不了，所以要分布式锁。第三，常见的分布式锁用 Redis：Redisson 的 tryLock 用 SETNX 加过期时间保证原子，业务没完成靠看门狗每三分之一过期时间续期，防止业务超时锁被误释放；也可以选 ZooKeeper 临时顺序节点，性能稍低但更可靠、可公平。锁的核心都是让并发操作共享资源的线程互斥，保证原子性。

【边界】 当然，分布式锁要设过期时间防宕机死锁，但过期时间不能短于业务执行时间，否则业务没跑完锁就释放了——所以 Redisson 用看门狗续期。另外锁粒度要尽量小（锁 key 细化）、持有时间要短，避免成为性能瓶颈；如果对一致性要求极高（如金融扣款），ZK 锁或数据库唯一约束兜底比 Redis 更稳妥。

面试记录 2026-10-30（第 1 次）

题目：你知道锁的实现方式么

难度：medium

标签：real-interview, java/lock, company/京东

评分：⭐⭐⭐☆☆（3/5）

我的回答

锁的实现方式指的是 Java 中的锁还是分布式的锁？这两个锁完全是两个概念的东西。Java 中的锁主要是 synchronized 和它自身的 JDK 提供的，在游戏包中的 ReentrantLock 锁、 AQS 相关的锁了;锁的核心其实就是保证多个请求操作共享数据共享数据的时候，不让它进行同时操纵，相互之间做个隔离，保证整个操作的原子性。synchronized的使用的是 CPU 内核提供的能力，去进行锁的并发控制。将所有的其他的竞争线程先阻塞，让当前线程执行完成之后，再去执行下一个线程的事情。它通过的能力是 CPU 的核心指令去进行控制的。ReentrantLock 实现的锁是基于 AQS 去实现的。核心是状态的更新，CAS 状态更新以及阻塞队列。它将任务放入阻塞队列中，然后基于状态去判定当前对象是否持有锁。持有了就去执行，线程持有了锁就执行，没持有锁就进入阻塞队列，等待被唤醒。也是实现了一个 JVM 级的线程管控吧，比内核管控其实是要更轻一些的。但是他们都只是单机上的锁，控制单机内的并发。如果是分布式性质的，他们就没有办法了，毕竟其他服务的线程访问他们是控制不了的。所以这时候就需要分布式的锁。常见的分布式锁，常规我们都使用 Redis 去实现，因为现在主要的服务都离不开服务都离不开 Redis。然后如果使用的 Redis 的客户端是 Reidsion，直接就 Reidsion 指自己的tyrlock 去获取锁。然后记得自己 unlock 释放锁。Redis 的分布式锁的核心其实也是主色，主色队列相关的。然后它实现的时候是判定你这个对象持有的锁是否，你当前访问的这个锁是否已经被其他的线程持有了，也不是线程，是否当前这个锁已经在 Redis 中存在了？如果存在了，就证明这个锁被持有了。当有人释放的时候才去删这个锁。这样下个人才能再去获取这个数。

点评

优点：区分了 Java 锁 vs 分布式锁（层次清晰，这是本题得分点）；synchronized（内核/monitor）+ ReentrantLock（AQS CAS + 阻塞队列）+ Redisson tryLock 三层都提到。

不足：synchronized 漏对象头 Mark Word 与锁升级（偏向→轻量→重量）；AQS 漏 CLH 队列细节与公平/非公平；分布式锁漏看门狗续期与过期时间权衡。

补充：锁升级链路 + Redisson watchdog 是 high 追问高频点，需补。

完整讲解见上方「完整讲解（权威版）」