单核温度飙升本质是线程死循环导致满频运行；须立即用top-jstack定位肇事线程并终止，再以BlockingQueue.take()、wait/notify或sleep(10)替代忙等，辅以volatile变量、计数器超时保护及压测验证。
单核物理温度瞬间飙高，本质是该核心被某个线程持续独占、满频运行，没有停顿——这正是无 sleep()、无阻塞、无中断检查的死循环最直接的硬件表现。解决不能只靠“降温”，得从线程行为本身切断 CPU 持续燃烧的源头。
立即止血：快速定位并终止肇事线程
先别改代码，先保服务：
- 用 top -H -p <pid> 找出占用率接近 100% 的线程 ID（显示为 LWP），记下十进制 tid
- 将 tid 转为十六进制（如 12345 → 3039），再用 jstack <pid> | grep -A 20 "0x3039" 定位到具体 Java 线程栈
- 确认栈顶是 RUNNABLE 状态且停留在某段 while 循环内（比如
while (flag)或while (true)） - 若确认无误且影响严重，可用 kill -3 <pid> 输出全栈供事后分析，或在确保业务可接受的前提下 kill -9 <pid> 重启进程
代码层修复：用阻塞代替空转，用信号代替硬等
死循环空转的本质是“轮询 + 忙等”。正确做法是让线程在无事可做时交出 CPU，而不是反复问“好了没？好了没？”
- 队列类场景（如消费消息）：用 BlockingQueue.take() 替代
queue.poll() != null的 while 循环；它会在为空时自动挂起线程，有数据时由 JVM 唤醒 - 条件等待场景（如等待标志位）：用 Object.wait() + notifyAll() 或 Lock + Condition，而非 while(!ready) {}
- 需要定期检查但又不想耗尽 CPU：用 Thread.sleep(10)（单位毫秒），10ms 是平衡响应与开销的经验值；避免
sleep(0)或sleep(1)，后者在某些系统上精度不足反而更耗电 - 所有循环必须有明确退出路径，并用 volatile 修饰控制变量（如
volatile boolean running = true），否则其他线程修改了 flag，当前线程可能永远看不到
防御性加固：加计数器 + 超时双保险
即使逻辑看似安全，也要防意外——比如外部依赖卡住、条件判断恒真、或并发修改绕过预期流程。
- 在 while 循环体内加入迭代计数器，例如：
int attempts = 0; while (running && attempts++ ；上限值按业务单次最大合理处理量 × 1.5 向上取整 - 循环结束后检查是否因超限退出：
if (attempts >= 10000) { log.error("Loop exited by max attempts, possible logic defect"); throw new RuntimeException("Loop guard triggered"); } - 对关键任务调用设置 JVM 层面的执行时限，如使用 CompletableFuture.orTimeout(30, TimeUnit.SECONDS) 包裹逻辑
上线前必做：压测中观察单核负载形态
CPU 温度飙升往往在低并发、单线程异常时最先暴露。光看整体 CPU 使用率没用，要盯住单核峰值：
- 用 mpstat -P ALL 1 观察每秒各核心的 %usr 占用，确认是否存在某一核长期 >95%
- 结合 pidstat -t -p <pid> 1 查看线程级 CPU 分布，确认高负载线程是否稳定复现
- 模拟空队列、异常返回、慢依赖等边界场景，验证线程是否会进入无休止空转
