本质是任务窃取线程失控导致单核满频过热，需立即刹住线程并堵逻辑漏洞：先用top-jstack定位死循环栈，再通过sysrq抓内核快照，聚焦窃取后任务体的空转、无限拆分、竞态自旋及终止信号忽略问题，代码中强制加入计数器上限、yield退让与温控降频机制。
这种情况本质是线程在任务窃取（work-stealing）机制下失控运行，没有节制、没有退出条件、也没有任何等待或让出 cpu 的行为，导致单核持续满频运行，热量积聚过快，触发硬件温控保护甚至直接宕机。解决重点不在“降温”，而在“刹住线程”和“堵住逻辑漏洞”。
立即止损：强制中断并保留现场
不要直接 reboot 或 kill -9 主进程——这会丢失关键线索。应分三步操作：
- 用 top -H -p [PID] 找出占用该核心最高的线程 TID（注意是线程 ID，不是进程 ID）
- 将该 TID 转为十六进制：printf "%x\n" [TID]，例如 123456 → 1e240
- 对 Java 进程执行：jstack [PID] | grep -A 20 "nid=0x1e240"，定位到具体方法栈和循环入口行号
- 同时执行 echo 1 > /proc/sys/kernel/sysrq 并 echo t > /proc/sysrq-trigger，生成内核线程状态快照（/var/log/messages 中可查）
定位死循环根源：聚焦窃取逻辑与边界条件
任务窃取框架（如 ForkJoinPool、自研 work-stealing 队列）本身不危险，危险的是窃取后执行的任务体未做防御。常见破绽包括：
- 窃取到空任务但未校验，反复调用
run()或compute()导致空转 - 任务拆分策略缺陷：子任务划分后仍满足继续拆分条件（如
if (end - start > 1)但数据已耗尽），形成无限递归式窃取 - 共享任务队列的 peek/poll 竞态：多个线程同时看到“有任务”，但实际只有一份，其余线程进入 while(!done) 自旋等待，且无 yield 或 sleep
- 终止信号被忽略：如 volatile boolean stopRequested = false; 但循环体内未轮询该变量
代码级修复：加守门、设上限、留退路
不能依赖“程序员自觉”，必须靠机制兜底：
- 所有窃取循环必须带计数器和硬上限，例如：
int stealAttempts = 0; while (!taskQueue.isEmpty() && stealAttempts++ - 每次窃取失败后插入 Thread.onSpinWait()（Java 9+）或 Thread.yield()，降低自旋强度
- 对 compute() 或 run() 方法增加执行时间采样：用
System.nanoTime()包裹核心逻辑，超时（如 50ms）则主动抛异常或返回 null，由上层决定是否放弃该任务分支 - 使用 ForkJoinPool.ManagedBlocker 封装可能长耗时的操作，避免线程池误判为活跃线程而持续派发新任务
系统层防护：物理温度不可绕过，需双保险
即使代码修复了，也要防止同类问题再次击穿硬件极限：
- 配置内核级温控响应：echo 75000 > /sys/class/thermal/thermal_zone0/trip_point_0_temp（单位 m°C），在 75℃ 触发降频而非等 95℃ 硬关机
- 用 cpupower frequency-set --governor powersave 替换 performance 模式，让单核在高负载时自动小幅降频控温
- 部署轻量级守护脚本，每 5 秒检查 cat /sys/class/thermal/thermal_zone0/temp，连续 3 次 > 85℃ 则自动执行 kill -SIGSTOP [TID] 暂停可疑线程（非终止），并告警
