容器 Paused 时进程被 cgroup freezer 内核级冻结，不参与 CPU 调度、不耗 CPU、内存保留、I/O 和网络停滞，但 CPU 配额仍占用，恢复时原子唤醒。
容器处于 Paused 状态时，其所有进程会被冻结（freeze），不再参与 Linux 的 CPU 调度，也不消耗 CPU 时间片，但进程内存仍保留在物理内存中，不被交换或释放。
Paused 状态的本质是 cgroup freezer 控制
Docker pause 命令底层调用的是 cgroup v1 的 freezer 子系统（在 cgroup v2 中对应 freezer.state），将容器所属的所有进程（包括 init 进程及其子进程）写入 FROZEN 状态。此时内核调度器会跳过这些进程——它们不会被放入运行队列（runqueue），也不会被唤醒执行。
- 进程状态在
ps或top中显示为T（stopped）或 - 即使容器内有高优先级实时进程（SCHED_FIFO/SCHED_RR），也会被强制冻结，不抢占 CPU
- pause 操作几乎是瞬时的，无调度延迟，也不触发上下文切换开销
CPU 使用率与调度器视角的变化
从宿主机角度观察：
– top、htop、/proc/stat 中看不到该容器进程的 CPU 时间累加
– docker stats 显示 CPU % 持续为 0.00%
– 宿主机整体 CPU 利用率下降（若原容器有活跃负载）
- 已分配的 CPU 配额（如
--cpus=0.5）仍被保留，未归还给共享池；cgroup 的 cpu.max/cfs_quota_us 不受影响，只是当前未使用 - 其他容器或宿主机进程可自由使用空闲 CPU 资源，不受 paused 容器干扰
- 不存在“CPU 抢占失败”或“调度抖动”，因为被冻结进程完全退出调度视野
与其它暂停机制的关键区别
不同于 kill -STOP 或 gdb attach + signal 等用户态暂停方式：
- freezer 是内核同步冻结，保证所有线程原子性进入静止状态（避免部分线程仍在执行）
- 不依赖进程是否响应信号，即使容器内进程屏蔽了 SIGSTOP 也能生效
- 支持嵌套 cgroup 场景，冻结粒度精确到整个容器 cgroup 树
- 恢复（unpause）时，所有线程在同一调度周期内被统一唤醒，保持相对执行顺序
实际运维中的注意事项
Paused 容器虽不耗 CPU，但仍有可观资源占用：
- 内存不释放：RSS 和 cache 内存持续占用，可能影响 OOM 触发阈值
- I/O 请求被挂起：若容器正执行写操作，pause 后 write 系统调用会阻塞，直到 unpause；可能导致上层应用超时或重试
- 网络连接不中断但无法收发：TCP 连接保持 ESTABLISHED，但 socket 接收/发送缓冲区停滞，对端可能触发重传或 RST
- 监控指标失真：如 Prometheus 抓取容器内指标失败，因 agent 进程也被冻结
