活锁（Livelock）与饥饿：探讨线程在尝试获取变量锁时不断重复失败的尴尬

在并发编程的世界里，线程“干不了活”是开发者最头疼的问题之一。但同样是停滞，背后的原因却大相径庭。今天，我们就来深入聊聊两种容易被混淆的困境：活锁与饥饿。它们一个是在RUNNABLE状态下的无效忙碌，CPU忙得团团转却毫无进展；另一个则是长期卡在WAITING或TIMED_WAITING状态，因为调度不公而始终轮不到执行机会。理解这二者的本质区别，是精准定位和解决问题的第一步。

简单来说，活锁是线程在跑、CPU在忙，但就像推磨的驴，始终在原地打转；而饥饿则是线程想跑，却一直排不上队，只能长期在等待区干瞪眼。

活锁：RUNNABLE 状态下的无效忙碌

活锁的典型场景，是多个线程在尝试获取同一把锁（比如使用tryLock()方法）时，失败了就立刻重试，中间没有任何退让或等待策略。结果就是，所有线程的状态都显示为RUNNABLE，用jstack工具查看，能看到它们在不停地循环调用lock/unlock或者消息重入逻辑，但业务进度却纹丝不动。

• 经典案例：转账死循环。想象两个转账线程，一个执行A→B，另一个执行B→A。它们同时发现账户冲突，于是都选择回退并立即重试。这就导致了一场永无止境的“礼貌谦让”：你让一步，我也让一步，结果谁也没法完成转账。
• 另一个常见陷阱：失败消息的无限重试。消息处理失败后，被无条件地重新插回队列头部。下一轮调度时，它又被优先取出，再次失败，再次插回……如此循环，队列头部的消息永远无法被成功处理。
• 如何识别？系统CPU使用率不低，但业务日志里反复出现“获取锁失败”、“处理超时”、“正在进行第N次重试”等字样，这就是活锁的典型信号。

饥饿：WAITING/TIMED_WAITING 下的长期缺席

饥饿问题的根源，往往不在于锁本身抢不到，而在于调度机制“偏心眼”，把某个或某些线程彻底“晾在了一边”。比如，一个后台统计线程被设置为Thread.MIN_PRIORITY（最低优先级），而高优先级的前台请求线程持续占满CPU。由于JVM并不保证线程优先级在所有平台上都严格生效，这个后台线程可能数小时甚至更久都得不到一次执行机会。

• 常见发生地：线程可能卡在ReentrantLock.lock()（尤其是在非公平模式下）、LinkedBlockingQueue.take()、或者Object.wait()上。查看堆栈时，你不会看到死锁那种循环等待的依赖链，但线程就是一动不动。
• 根本原因：资源分配不公平。可能是高优先级线程垄断了CPU，可能是锁的获取没有遵循先来后到的排队顺序，也可能是notify()总是唤醒最新来的线程，而忽略了等待最久的那个。
• 与活锁的直观区别：在jstack的输出中，饥饿线程的状态多为WAITING或TIMED_WAITING，并且对应的业务日志长时间没有任何输出，仿佛这个线程“消失”了。

怎么破？关键在打破节奏与保障公平

解决思路很清晰：对付活锁，核心是打破那种同步共振的节奏；而解决饥饿，则需要修复调度机制的失衡，保障公平性。

• 针对活锁：
  • 引入随机延迟。在重试之前，加入一个随机的等待时间（例如使用ThreadLocalRandom.current().nextInt(10, 100)毫秒）。这能有效避免所有线程在毫秒级的时间窗口内整齐划一地再次撞车。
  • 确保可中断。在重试循环中，定期检查Thread.interrupted()状态。否则，即使调用shutdownNow()试图中断线程，也可能因为线程忙于无意义的循环而无法响应，使得优雅关闭机制失效。
• 针对饥饿：
  • 改用公平锁。将new ReentrantLock(true)（公平锁）作为首选，或者为关键的后台线程显式设置合理的优先级，并定期调用Thread.yield()主动让出CPU。
  • 优化通知机制。尽量避免使用单一的notify()，改用notifyAll()，或者使用更现代的Condition.await()机制，并结合awaitNanos()等方法，可以更精细地控制等待和唤醒的粒度。

总结一下，其实道理并不复杂：活锁靠“错峰”来化解，饥饿靠“排队”来保障。在实际排查时，抓住三个关键点：一看线程状态（RUNNABLE还是WAITING），二查堆栈调用（是循环重试还是单纯等待），三测重试逻辑（是否有退让策略）。遵循这个步骤，就能快速准确定位问题类型，从而对症下药。