核心是让循环该停时能停、该等时会等、该退时有兜底：设迭代上限、用阻塞等待替代空转、加运行时超时限制、确保控制变量可见可变，如MySQL设max_execution_time、Java用orTimeout、队列用take()而非poll()。
核心不是让循环“慢下来”，而是让它该停时能停、该等时会等、该退时有兜底。单核CPU被吃满，往往是因为线程陷入纯计算+无等待的空转状态，调度器持续分配时间片，却始终得不到释放。
加硬性退出守门员：计数器上限
无论业务逻辑看起来多可靠，都必须在 while 循环里设一个明确的迭代次数上限：
- 声明两个变量：DECLARE i INT DEFAULT 0; 和 DECLARE max_iter INT DEFAULT 5000;（数值按预期最大处理量 ×1.5 向上取整到千位）
- 每次循环末尾强制执行 SET i = i + 1;
- 循环开头第一句就检查：IF i >= max_iter THEN LEAVE my_loop;
- 循环结束后补一句日志或 SELECT 语句，确认是否真因业务条件退出——若 i 等于 max_iter，说明逻辑存在缺陷，必须修复
用阻塞代替空转：让线程主动交出 CPU
轮询式死循环（如 while (!ready) { } 或 while (queue.poll() == null)）本质是浪费算力。应替换为真正挂起等待的方式：
- 消息消费场景 → 改用 BlockingQueue.take()，队列空时线程自动休眠，有数据才唤醒
- 状态等待场景 → 改用 Object.wait() 配合 notifyAll()，或 Lock + Condition
- 需定期检查但又不能太密 → 用 Thread.sleep(10)（Java）或 time.sleep(0.01)（Python），避免
sleep(0)或sleep(1)这类低效写法 - Go 中绝不用
for {}，改用select {}或带<-done的阻塞接收
从运行环境加第二道保险
单靠代码层防护还不够。万一计数逻辑被跳过、变量未更新、或线程卡在锁/IO 上没机会执行计数，风险仍在：
- MySQL 存储过程中，调用前临时设置会话级超时：SET SESSION max_execution_time = 30000;（单位毫秒，即 30 秒）
- Java 应用中，对关键异步任务使用 CompletableFuture.orTimeout(30, TimeUnit.SECONDS)
- Spring Boot 项目可配置 Actuator 的 /actuator/threaddump 接口，便于紧急时快速抓取线程快照
- 所有长时循环外层建议包一层 try-catch(Throwable)，捕获后打 ERROR 日志并主动终止（注意避开 OOM 等致命异常）
上线前必须做的三件事
防范死循环不能只靠临场补救，得把防御嵌入开发流程：
- CI 阶段接入静态扫描工具（如 SonarQube），规则覆盖 “无退出条件的 while 循环”、“空 catch 块”、“浮点比较用于循环条件” 等高危模式
- 单元测试必须覆盖边界情况：分页越界、查询为空、外部依赖返回异常值、并发修改标志位等
- JVM 启动参数中加入 -XX:+PrintGCDetails -XX:+PrintGCDateStamps，配合监控观察是否伴随 GC 抖动，交叉验证是否真为纯死循环
