容器重启次数限制本身不直接防止CPU过热，但能阻断崩溃-重启循环，避免高频fork、调度和上下文切换；真正有效的是重启策略配合CPU/内存硬限制（如--cpus=1.2、--memory=512m）及systemd启动限流。
容器重启次数限制本身不直接防止 cpu 过热，但它能阻断反复崩溃→重启→再崩溃的恶性循环，从而避免短时间内高频 fork 进程、频繁调度、内核上下文切换激增——这些才是导致宿主机 cpu 温度异常升高的真实诱因。
真正起作用的是：用重启策略 + 资源限制双管齐下。只设重启次数却不控资源，容器仍可能每次启动就吃满 CPU；只限资源但不限重启，容器持续抖动照样拉高系统负载。
✅ 正确做法：重启策略必须配合硬性 CPU 限制
Docker 的 --restart 参数控制“是否重启”和“最多重几次”，但它不干预容器内部行为。若一个未设 CPU 上限的容器因逻辑缺陷每秒崩溃 10 次，每次启动都瞬间打满 4 核，systemd 会拦截（触发 StartLimitBurst），但在这之前，CPU 已经被反复冲击数秒甚至数十秒。
所以必须同步配置：
docker run -d \ --name api-service \ --restart=on-failure:5 \ # 最多重启 5 次，之后停住不再试 --cpus=1.2 \ # 硬性限制：最多用 1.2 个逻辑核，超了就节流 --memory=512m \ # 同时限制内存，防 OOM 触发内核调度风暴 my-api:latest
⚠️ 注意：
on-failure:5是指非零退出码时才计数。如果容器因 OOM 被杀（退出码 137），它算作一次on-failure；但如果容器自己 panic 退出码是 2，也会计入。只要不是exit 0，基本都算。
? 为什么 --cpus 比 --cpu-shares 更关键？
-
--cpu-shares=1024是相对权重，空闲时容器可跑满所有核 → 完全无法抑制单次启动的 CPU 冲击； -
--cpus=1.2是绝对上限，内核 cgroups 会在调度层强制截断 → 即使应用疯狂 busy-loop，宿主机 CPU 使用率也不会突破该配额对应的实际时间片。
这意味着：哪怕容器每 2 秒崩溃一次、重启 5 次，它的 CPU 占用始终被钉死在 ≤1.2 核水平，宿主机温度不会因此飙升。
? 补充防护：用 systemd 防止 Docker daemon 自身被拖垮
如果大量容器同时陷入重启风暴，Docker daemon 进程自身也会被高频 API 请求压垮，进一步加剧系统负载。此时需检查 /usr/lib/systemd/system/docker.service 中的启动限制：
[Unit] StartLimitBurst=3 StartLimitIntervalSec=60
建议调为更保守值（尤其在边缘或低配机器上）：
StartLimitBurst=2 StartLimitIntervalSec=120
这样即使有多个容器故障，Docker 服务也不会因自身频繁重启而雪上加霜。
? 小结：三步封堵 CPU 过热链路
- 设置
--restart=on-failure:N（N 通常取 3–5），让失控容器主动“熄火”； - 强制绑定
--cpus=X.X和--memory=Ym，从根源压制单次运行的资源破坏力； - 检查并收紧 systemd 的
StartLimitBurst，保护 Docker 守护进程不被连带拖垮。
这三者缺一不可。单靠重启次数，只是给问题按暂停键；加上资源硬限，才是真正掐住发热源头。
