活锁是线程持续响应冲突、反复退让却无法推进；饥饿是线程可运行但因调度或资源分配不公平而长期得不到执行；死锁是线程互相等待对方释放锁而永久阻塞。
活锁：线程没卡住，但一直在“礼貌让路”
活锁不是阻塞，而是线程持续响应对方、反复退让却始终无法推进。典型场景是两个线程都试图获取同一组资源（比如 Lock），发现冲突后主动释放已持锁、再重试——结果双方永远在“你让我、我让你”的循环里空转。
- 常见错误现象：
tryLock()失败后立即unlock()+sleep(0)重试，所有线程几乎同步重试，冲突反复发生 - 真实使用场景：分布式任务队列中失败消息回滚后插回队首，若处理逻辑有缺陷，该消息会被无限重试
- 关键解决点：引入随机性打破同步节奏。例如重试前调用
Thread.sleep(ThreadLocalRandom.current().nextInt(10, 100)) - 注意坑：别用固定
sleep(10)，否则多线程仍会高度趋同；也别在重试逻辑里漏掉中断检查（Thread.interrupted()），否则无法优雅退出
饥饿：线程能跑，但永远轮不到它
饥饿不是死锁或活锁，是调度或资源分配不公平导致的“长期缺席”。最典型的是低优先级线程被高优先级线程持续压制，或者公平锁未启用时，新线程总比等待久的线程先抢到 ReentrantLock。
- 常见错误现象：用
Thread.setPriority(Thread.MIN_PRIORITY)后，该线程日志几乎不输出；或wait()线程从不被notify()，而其他线程总被唤醒 - 真实使用场景：Web 应用中后台统计线程优先级设为
MIN_PRIORITY，而请求处理线程占满 CPU，统计任务永远延迟 - 关键解决点：禁用线程优先级（JVM 规范不保证跨平台效果）；对锁使用
new ReentrantLock(true)启用公平模式；对共享资源用java.util.concurrent包中的公平类（如LinkedBlockingQueue） - 注意坑：公平锁会降低吞吐量，别在高频短临界区盲目开启；
wait()/notify()不是公平机制，应改用Condition配合公平锁
怎么快速区分这三者？看线程状态和日志
遇到线程“不动了”，先别急着查死锁——用 jstack <pid></pid> 或 JConsole 的“检测死锁”按钮，结果会直接告诉你有没有死锁线程。没有死锁？再观察：
- 如果线程状态是
RUNNABLE却无实质进展（比如 CPU 占用高但业务指标不涨），大概率是活锁 - 如果线程状态是
WAITING或TIMED_WAITING，且长时间停留（比如parking to wait for），结合代码看是否在等不公平的锁或 notify，就是饥饿 - 如果线程状态是
BLOCKED，且堆栈显示在等另一个线程持有的锁，而对方也在等它——死锁确认
活锁和饥饿都不留明显阻塞痕迹，必须靠日志打点（比如每次重试/每次 wait 前打印时间戳）或监控线程活跃度来定位。
立即学习“Java免费学习笔记（深入）”；
