直接从 cgroups 入手最有效：cgroups 是 Linux 内核自 2.6.24 起内置的资源管理框架，Docker 仅封装其接口；应先手动创建 cgroup、设置 cpu.shares 或 cpu.cfs_quota_us、验证进程归属，再对照 Docker 命令理解其底层映射与两类 CPU 控制机制（权重 vs 硬限）及内存限制行为。
直接从 cgroups 本身入手最有效，别绕开 Linux 内核机制去学 Docker 参数。
先搞懂 cgroups 的底层逻辑
cgroups 不是 Docker 发明的，它是 Linux 内核自 2.6.24 就内置的资源管理框架。Docker 只是封装了它的接口。建议按这个顺序理解：
- 在宿主机上手动创建一个 cgroup：比如
mkdir -p /sys/fs/cgroup/cpu/test-group - 写入一个进程 PID 到
tasks文件，把它“塞进”这个组 - 设置
cpu.shares或cpu.cfs_quota_us，观察该进程的 CPU 使用变化 - 用
cat /proc/<pid>/cgroup确认进程确实归属到对应控制组
对照 Docker 命令看 cgroups 文件映射
运行一个带限制的容器后，立刻去查它在 cgroups 中的真实配置：
docker run -d --cpus=0.3 --memory=256m nginx- 用
docker inspect <id> | grep Id获取容器 ID - 查看路径：
/sys/fs/cgroup/cpu/docker/<id>/cpu.cfs_quota_us和/sys/fs/cgroup/memory/docker/<id>/memory.limit_in_bytes - 你会发现
--cpus=0.3被自动转成period=100000, quota=30000；--memory=256m对应的是268435456字节
区分两类 CPU 控制方式
很多人混淆“权重”和“硬限”，其实它们解决不同问题：
- cpu.shares（权重）：只在多个容器争抢 CPU 时起作用。设为 512 vs 1024，意味着前者拿到约 1/3 时间，后者拿 2/3；空闲时都能跑满
-
cpu.cfs_quota_us + cpu.cfs_period_us（硬限）：不管有没有竞争，每 period 微秒内最多运行 quota 微秒。这是真正意义上的上限，比如
--cpus=1.5就是硬限
动手验证内存限制行为
内存比 CPU 更容易触发明确反馈，适合初学者建立直觉：
- 启动一个限制为 100MB 的容器：
docker run --memory=100m alpine sh -c 'dd if=/dev/zero of=/tmp/big bs=1M count=200 2>/dev/null' - 它会很快被 OOM Killer 杀掉，同时
dmesg | tail能看到内核日志记录 - 对比不加限制的情况，观察
cat /sys/fs/cgroup/memory/docker/<id>/memory.usage_in_bytes的增长趋势
不复杂但容易忽略：所有这些操作都不依赖 Docker，纯 Linux 就能完成。把 cgroups 当成独立技能练熟了，再去看 Docker 的 --cpus、--memory 参数，就只是语法糖而已。
