死锁是线程互相等待对方释放锁导致的假死现象，表现为cpu低但任务停滞；活锁是线程持续让步无法进展，cpu高且日志反复重试；饥饿是线程长期得不到调度，处于runnable却无实际执行。
死锁：线程互相等待对方释放锁，谁也不动
死锁是最典型的活性失败——所有相关线程卡在 wait()、join() 或同步块里，彼此持有对方需要的资源，又不释放。现象是程序“假死”，CPU 占用低，但任务永远不推进。
常见场景：synchronized 嵌套调用顺序不一致、数据库事务中多表更新顺序错乱、线程池中 submit() 后又调用 get() 等待自身队列中的任务。
- 避免嵌套锁：用
ReentrantLock.tryLock(long, TimeUnit)设超时，失败就回退 - 锁顺序全局约定：比如按
Math.min(objA.hashCode(), objB.hashCode())决定加锁先后 - JDK 自带检测：启动时加
-Dcom.sun.management.jmxremote，用jstack查java.lang.Thread.State: BLOCKED循环链
活锁：线程没阻塞，却因反复让步而无法前进
活锁不是挂起，而是线程持续响应干扰、主动放弃重试，结果像“两个迎面走路的人不断侧身避让却始终撞上”。现象是 CPU 占用高，日志里反复出现重试/回滚/补偿动作，但业务状态毫无进展。
典型例子：消息队列消费者处理失败后立即重发，触发下游同样逻辑，形成震荡；或 AtomicInteger.compareAndSet() 在高竞争下反复失败重试，但其他线程总“恰好”改写值。
- 引入随机退避：重试前
Thread.sleep((long)(Math.random() * 100))，打破同步节奏 - 限制重试次数：超过
MAX_RETRY = 3就走异步补偿或丢入死信队列 - 避免无条件让步：比如
LockSupport.park()前必须检查明确条件，而非“只要别人在动就躲”
饥饿：线程有资格运行，但永远轮不到它
饥饿不是 bug，而是调度不公平导致的活性失败。线程一直处在 Runnable 状态，但操作系统或 JVM 线程调度器长期不给它 CPU 时间片。现象是某类任务（如低优先级日志线程、IO 密集型回调）延迟飙升，监控显示线程数稳定但吞吐掉底。
常见诱因：Thread.setPriority() 滥用（尤其在 Linux 上几乎无效）、ExecutorService 使用无界队列 + 固定线程数，导致新提交的短任务被积压在长任务之后；或公平锁未开启（new ReentrantLock(true)）。
- 别信
setPriority()：JVM 不保证映射到 OS 优先级，Linux 默认所有 Java 线程同级，靠 CFS 调度 - 用有界队列 + 拒绝策略：比如
new ThreadPoolExecutor(4, 4, 0L, TimeUnit.MILLISECONDS, new ArrayBlockingQueue(100), new ThreadPoolExecutor.CallerRunsPolicy()) - 公平锁仅在低并发且需强顺序时启用：它带来显著性能开销（每次进队都要 CAS 更新 tail），高并发下反而加剧争抢
怎么确认是哪种活性失败？看线程栈和指标组合
单靠现象容易误判：CPU 高可能是活锁也可能是密集计算；线程数暴涨可能是饥饿也可能是泄漏。关键要交叉验证。
- 抓全量线程栈：
jstack -l <pid> > threaddump.txt</pid>，搜索java.lang.Thread.State:后的关键词（BLOCKED→死锁倾向，WAITING/TIMED_WAITING→看堆栈是否循环调用，Runnable但无实际进展→饥饿嫌疑） - 配合同步指标：Prometheus 拉取
jvm_thread_deadlocked_threads（JMX 暴露）、executor_pool_active_threads长期满+队列堆积→饥饿 - 最易忽略的一点：JVM 参数影响判断。比如默认
-XX:+UseParallelGC下 GC 停顿可能伪装成线程阻塞，先关掉 GC 日志干扰再分析
活锁和饥饿没有栈上明显标记，得靠行为模式和外部指标反推——这点比死锁难抓得多。
