明明给 Docker 分配了 4 个 CPU 核心，Java 应用却只跑出单核的性能？
Ollama 加载的 LLM 在容器里推理忽快忽慢，换到宿主机就丝般顺滑？
这不是玄学，而是你踩中了 容器虚拟化 + 操作系统调度 的经典陷阱。

        在智答知识库系统和知识汇教育平台里，我用 Docker Compose 同时跑 SpringBoot、FastAPI、Ollama 和 Redis。刚开始一切美好，直到压测时发现：明明宿主机 CPU 还有余量，容器里的 AI 服务却像被掐住脖子。排查了两天，我才搞懂 —— 原来容器并没有真正的“独立 CPU”，它只是一个被 cgroups 和 namespace 包装起来的进程。
        今天，我就从一次真实的“限速”经历出发，带你彻底搞懂 容器与虚拟化、CPU 时间片、cgroups 限制，以及 Java 应用在容器里该怎么配。

一、容器不是虚拟机：它只是一个“高级囚笼”

1.1 虚拟机 vs 容器：本质区别

• 虚拟机：模拟完整硬件（CPU、内存、磁盘），运行独立内核，资源开销大。

• 容器：共享宿主机内核，通过 namespace 隔离资源视图，通过 cgroups 限制资源使用。容器本质上就是宿主机上的一个（或一组）进程。

一句话：容器是“轻量级囚笼”，不是“小电脑”。

1.2 为什么容器里的性能难以预测？

因为所有容器共享宿主机的 CPU 时间片。
操作系统调度器看到的不是“容器”，而是 一个个进程。
即使你给容器分配了 --cpus=4，也只是设置了一个 CPU 带宽上限，而不是独占 4 个核心。

二、cgroups 的“三把锁”：CPU 限制的真实面目

Docker 的 --cpus、--cpu-shares、--cpuset-cpus 底层都是 cgroups 的配置。

2.1 --cpus：硬上限（最容易踩坑）

docker run --cpus=2 -it openjdk:17 java -jar myapp.jar

这表示：在每 100ms 周期内，该容器的所有进程最多能使用 200ms 的 CPU 时间。
后果：如果 Java 应用启动了 4 个并行线程，它们会被 CFS 调度器强制限流，导致线程频繁等待，吞吐量不增反降。

真实案例：在知识汇秒杀系统中，我用 --cpus=4 运行 SpringBoot，压测 QPS 只有 500。去掉限制后，直接飙到 2000。后来我改用 --cpuset-cpus=0-3 绑定核心，性能才稳定下来。

2.2 --cpu-shares：软权重（非精确保障）

docker run --cpu-shares=2048 -it ...   # 权重是默认的两倍

当宿主机 CPU 空闲时，--cpu-shares 几乎不起作用；只有争抢时，高权重的容器会分到更多时间片。不适合做精确的资源隔离。

2.3 --cpuset-cpus：绑定核心（最稳定）

docker run --cpuset-cpus=0,2 -it ...

将容器进程绑定到物理核心 0 和 2。这样避免了线程在不同核心间迁移的开销，性能最可预测。
缺点：核心独占，其他容器无法使用这些核心，降低了利用率。

三、Java 在容器里的“盲点”：JVM 不知道自己被限流

3.1 经典问题：Java 并行流 / ForkJoinPool 的线程数

Java 8/9/10 的 JVM 默认根据 宿主机 CPU 核心数 来设置 Runtime.getRuntime().availableProcessors()。
如果你在 32 核的宿主机上启动一个 --cpus=2 的容器，availableProcessors() 依然返回 32。
后果：ForkJoinPool 会创建 32 个并行线程，而这些线程共享容器可怜的 2 核配额，导致严重的上下文切换和限流。

解决方案：从 Java 10 开始，JVM 能感知 cgroup 限制；Java 8 需要升级到 8u191+ 并添加 JVM 参数：

java -XX:+UseContainerSupport -XX:ActiveProcessorCount=2 -jar myapp.jar

3.2 我的踩坑记录

在智荟知识库项目中，Python 的 FastAPI 服务（用 --cpus=2）内使用 multiprocessing.Pool(4)，结果推理延迟飙升。
查看容器 CPU 统计：

docker stats --no-stream

发现 CPU 使用率被卡在 200% 附近波动（2 核上限），但进程数显示有 4 个 worker 在抢时间片。改为 --cpuset-cpus=0,1 并绑定 worker 数量为 2 后，延迟恢复正常。

四、AI 模型服务为什么特别容易触发限速？

4.1 推理任务的特点

• CPU 密集型：矩阵乘法、向量检索会持续占满 CPU。

• 线程数多：PyTorch/TensorFlow 默认开启多线程并行。

• 对延迟敏感：限流导致的调度延迟会直接拉长 P99 响应时间。

4.2 实战建议

1. 用 --cpuset-cpus 代替 --cpus
对于 AI 推理服务，最好绑定固定核心，避免 CFS 配额限流。

2. 手动控制并行线程数
在 Python 中设置：

import os
os.environ["OMP_NUM_THREADS"] = "2"
os.environ["MKL_NUM_THREADS"] = "2"

在 Java 中设置：

System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism", "2");

3. 监控容器真实 CPU 限流情况

cat /sys/fs/cgroup/cpu/cpu.stat
# 查看 nr_throttled 和 throttled_time

五、一张图总结：容器 CPU 限制的完整逻辑

• 容器A 使用配额限流，可能被 throttle

• 容器B 绑定核心，性能稳定

• 容器C 靠权重，空闲时无限制，争抢时让步

🤔 思考题：
        你在一个 32 核的物理机上用 docker run --cpus=2 启动了一个 Java 应用，应用内使用 Executors.newFixedThreadPool(8) 处理任务。在 CPU 密集型计算场景下，这 8 个线程会如何被操作系统调度？为什么实际吞吐量可能远低于预期？应该如何修改 Docker 参数或 JVM 配置来解决？

        欢迎在评论区留下你的分析和方案 —— 下一篇我会专门聊聊 “Java 线程池 + 容器 CPU 限制 = 性能大坑” 的完整排错过程。