应设迭代上限、用阻塞等待替代空转、加运行时超时限制、确保控制变量可见可变：如MySQL设max_execution_time、Java用volatile和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; END IF;
- 循环结束后补一句日志或断言，确认是否真因业务条件退出，还是被计数器踢出——后者说明逻辑有缺陷，必须修复
用阻塞代替空转：让线程主动交出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;（单位毫秒，MySQL 5.7.8+ 支持）
- Java 应用可对关键任务使用 CompletableFuture.orTimeout(30, TimeUnit.SECONDS)
- Linux 下可通过 cgroups 限制进程整体 CPU 使用率，作为兜底压制手段
控制变量必须可见且可变
很多“看似退出了却没退出”的问题，根源是控制变量失效：
- Java 中用于退出循环的布尔标志，必须用 volatile 修饰，否则其他线程修改后当前线程可能永远看不到
- 避免依赖外部表状态、全局缓存值、或未同步的共享变量作为唯一退出依据
- 赋值语句别被 if 分支挡住——比如
IF success THEN SET done = 1; END IF;，若 success 永不为真，done 就永远不会变
