当年被面试官连环追问 Java 锁的那 15 分钟

2026 年金三银四又到了最近帮团队面了不少 Java 候选人发现一个老问题还是普遍存在 —— 大多人只停留在 API 层面稍微往深了挖就断片。这让我想起 10 年前我去广州 YY 面试的场景那天面试官上来连自我介绍都没让我做直接盯住 Java 锁这块一路追问那 15 分钟现在还记得清清楚楚。第一问就直接来synchronized 是干嘛用的我当时回答它能让没拿到锁的线程排队只有拿到锁的线程才能执行解决并发问题。现在看这个回答只能打 60 分说清楚了作用但没点出本质。面试官听完立刻追了第二问你说获取不到锁会排队这里排队是什么意思具体发生了什么我想了下回答获取不到锁的线程会被操作系统挂起等着拿到锁的线程释放后再唤醒。面试官继续第三问被挂起会很影响性能啊有没有办法让获取不到锁的线程先不要挂起我当时就愣了 —— 还有这种操作我盯着白板想了 30 秒老实说这个知识点我不清楚。出来之后我才反应过来这问的是自旋锁。思路其实很简单如果拿不到锁先不忙挂起让线程原地 自旋 几圈等等看 —— 因为很多时候持有锁的线程执行很快马上就释放锁了。要是这时候还走操作系统挂起再唤醒那上下文切换的代价反而不划算。特定场景下用自旋效率确实提升不少。这里我也停一下考一考正在准备面试的你纯自旋就一定好吗有没有更好的改进方式......思考几秒钟其实方案很 straightforward自适应自旋。让线程自旋但设置一个时间或次数阈值如果自旋到阈值还拿不到锁再退化成操作系统挂起。这样兼顾了性能和线程资源浪费问题JDK 后期的 synchronized 就是这么优化的。你以为这就完了关于 synchronized 的追问才到一半面试官根本没打算放过我。继续问synchronized 底层是怎么实现的还好这个知识点我之前啃过能接上就是通过对象头关联的 Monitor 监视器锁字节码里用 monitorenter 和 monitorexit 两个指令标记同步块拿到监视器锁才能进入执行执行完调用 monitorexit 释放锁再通知等待的线程唤醒。嗯这个回答过关了。那再来最后一问除了 synchronizedJava 还有什么方式加锁它们有什么区别这个问题我当时答得不好只说了 Lock 接口能手动加锁解锁但没答出核心区别。其实这个问题本质是问 Java 1.5 之后 concurrent 包下的 Lock 和 synchronized 的设计差异Lock 支持中断响应synchronized 不行Lock 支持超时获取锁死等不如超时放弃Lock 可以实现公平锁synchronized 只能是非公平Lock 需要手动释放synchronized 由 JVM 自动释放所以整体来说Lock 更灵活synchronized 更易用。问到这里面试官才终于放过我。现在一线互联网公司的面试就是这个路数 —— 同一个知识点层层往下挖一直挖到你说 我不知道 为止。这样才能真正看出来你对这个问题理解到什么程度。我做了十年技术面试官负责任地说一句如果你发现面试官每个问题只问一次就不再往下追了那这才是危险信号 —— 说明面试官已经判断你对这个问题也就了解这么多了再挖也挖不出东西没必要浪费时间。结合现在的面试趋势我整理了一套应对深度追问的准备方法上传到AI了学会利用 AI 工具刻意练习https://muyulab.com/?utm_sourcecsdn