死循环会彻底冻结事件循环，导致宏任务、微任务、渲染和用户交互全部中断；排查需先验证事件循环是否失能，再从高危代码结构入手定位，并通过运行时监控主动捕获阻塞。
死循环会直接冻结事件循环——不是让它变慢，而是彻底停摆。此时主线程被同步代码锁死，宏任务、微任务、渲染、用户交互全部中断。排查关键不在于“找循环语句”，而在于确认事件循环是否已失能，并定位阻塞源头。
第一步：快速验证事件循环是否真正卡死
页面卡顿时，先区分是“长任务”还是“真死循环”：
- 如果右键菜单弹不出、开发者工具打不开、刷新按钮无反应、强制关闭标签页才恢复 → 极大概率是死循环
- 如果还能切换标签页、偶尔响应点击、控制台可输入命令 → 更可能是耗时过长的同步任务（如大数据遍历），尚未完全阻塞事件循环
- 打开 Chrome DevTools → Performance 面板 → 点击录制 → 复现操作 → 停止后观察主线程火焰图：若出现持续超过1秒的红色长条且无间隙，说明有长任务；若整段录制中主线程全程满载、无任何渲染帧（绿色块）、无任何事件处理标记 → 高度怀疑死循环
第二步：从代码结构入手锁定高危循环
死循环几乎都集中在以下几类写法中，应优先检查：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- while(true) 或 for(;;) —— 没有显式退出条件，依赖外部变量或 break，但 break 路径未覆盖所有分支
-
浮点数严格相等判断：例如
while (x !== 1.0)，因精度丢失导致条件永远为真 -
赋值误作比较：如
for (let i = 0; i = 10; i++)，第二个表达式恒为真 -
变量未在循环体内更新：外部修改变量（如
i = 2）发生在循环之后，而循环内又不改变判断依据 -
Promise 构造器内嵌死循环：如
new Promise(resolve => { while(condition) {...} })，构造器同步执行阶段就卡死，后续所有代码（包括 resolve 调用、setTimeout 回调）全部无法进入队列
第三步：用运行时监控主动捕获异常延迟
在开发或测试环境注入轻量级探测逻辑，提前预警：
- 在入口处插入：
const start = performance.now(); process.nextTick(() => { if (performance.now() - start > 50) console.warn('Event loop blocked for', Math.round(performance.now() - start), 'ms'); }); - 对可疑循环加防护：设置迭代上限（
count++ ）或时间上限（<code>performance.now() - start ） - Node.js 环境下可用：
require('perf_hooks').performance.eventLoopUtilization()，若active值长期趋近于 0，说明事件循环几乎无活跃任务，处于空转或停滞状态
第四步：避免调试器失效带来的盲区
死循环发生时，VSCode 或 Chrome DevTools 的断点常无法命中，因为调试协议本身依赖事件循环通信：
- 不要依赖断点单步——它可能永远等不到下一行
- 改用
console.log插桩，在循环起始、关键判断前后输出标记（如console.log('loop step:', i)），观察最后输出哪一行 - Node.js 中启用 trace 事件：
node --trace-event-categories v8,disabled-by-default-node app.js，生成 trace 文件后在 chrome://tracing 中查看 poll 阶段是否长时间空白 - 若已卡死，尝试发送
SIGUSR1（Linux/macOS）触发 V8 堆快照，但前提是进程尚未完全冻结；更可靠的是提前部署process.on('beforeExit')或定时心跳日志
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
