在并发编程实践中，线程“停滞不前”是开发者常遇的棘手难题。然而，同为停滞，其内在机理却截然不同。本文将深入解析两种易被混淆的线程困境：活锁与饥饿。前者表现为线程处于RUNNABLE状态下的无效空转，CPU资源被持续消耗却无实际进展；后者则是线程长期滞留于WAITING或TIMED_WAITING状态，因资源调度失衡而始终无法获得执行机会。清晰辨析二者的本质差异，是高效诊断与解决并发问题的关键前提。
通俗地讲，活锁如同线程在跑步机上全力奔跑，看似忙碌实则原地踏步；而饥饿则好比线程在检票口外长久等候，却始终无法获得入场许可。
活锁：RUNNABLE 状态下的无效循环
活锁的典型成因，是多个线程在竞争同一资源（如使用tryLock()尝试获取锁）时，一旦失败便立即无间隔重试，缺乏有效的退避或等待机制。其结果是，所有相关线程状态均显示为RUNNABLE，通过jstack等工具可观察到它们持续进行着lock/unlock调用或消息重入循环，但核心业务流程却毫无推进。
- 典型案例：双向转账死循环。设想两个并发转账线程，一个执行从账户A到B的转账，另一个执行从B到A的转账。当它们同时检测到账户余额冲突时，若均采用“回滚并立即重试”的策略，便会陷入无止境的相互礼让：线程A让出资源后线程B立即跟进，反之亦然，导致转账操作永远无法完成。
- 常见陷阱：失败消息的无限重试队列。消息处理失败后，若被无条件重新插入队列头部，则在下一次调度时仍会被优先取出。该消息反复失败、反复重入队首，形成阻塞队列头部的“毒丸”，使得后续消息无法得到处理。
- 识别方法：系统监控显示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()/signal()方法，配合awaitNanos()等方法实现对等待唤醒过程的更精细控制。
总结而言，活锁的解决之道在于“错峰执行”，而饥饿的应对之策在于“公平调度”。在实际问题排查中，可遵循以下三步：首先，观察线程状态（是RUNNABLE还是WAITING）；其次，分析线程堆栈（是处于活跃循环还是静默等待）；最后，审查重试与调度逻辑（是否存在退让机制与公平性保障）。掌握这一诊断流程，便能快速定位问题根源，实施精准优化。
