Docker Desktop 不提供进程数限制（--pids-limit）的图形界面选项，因其仅管理虚拟机级资源（CPU/内存/磁盘），而 PID 限制属容器级 cgroup v2 内核控制项，必须通过 docker run --pids-limit=N 或 docker-compose.yml 中 deploy.resources.limits.pids 显式配置，且宿主机需启用 cgroup v2。
不能直接在 Docker Desktop 图形界面里设容器的进程数上限——--pids-limit 是 Docker Engine 层的运行时参数，Desktop 本身不提供该选项的 UI 入口。你得在 docker run 或 docker-compose.yml 中显式传入，且宿主机必须启用 cgroup v2（现代 macOS/Linux 默认满足）。
为什么 Docker Desktop 没有“进程数限制”开关
Docker Desktop 只是把 Linux 虚拟机（macOS 上是 HyperKit，Windows 上是 WSL2）和 Docker CLI/Engine 封装起来，它控制的是虚拟机本身的 CPU、内存、磁盘等全局资源，不是单个容器的内核级限制。进程数（PID）属于 cgroup 的 pids.max 控制项，必须由 docker run 启动时通过 --pids-limit 注入，Desktop 不会自动帮你加这个参数。
常见误解是以为调大 Desktop 的 “Memory” 或 “CPUs” 就能“间接控进程”，其实完全无关：一个 Java 容器开 2000 个线程，哪怕只占 512MB 内存 + 0.2 核 CPU，照样可能触发 fork: Resource temporarily unavailable 错误。
用 --pids-limit 限制单个容器的进程/线程总数
这是最直接有效的方式，适用于 Docker 20.10+（Desktop 4.10+ 默认带此版本）：
-
docker run --pids-limit=384 -d nginx：启动 Nginx 容器，最多允许 384 个进程/线程（含 worker、cache manager、log writer 等） -
docker run --pids-limit=128 -e NODE_OPTIONS="--max-old-space-size=512" -d node:18-alpine：Node.js 应用通常不需要太多进程，128 足够防泄漏 - 设为
--pids-limit=-1表示不限制（Docker 默认行为），但生产环境不建议 - 设为
--pids-limit=0会报错：invalid pids limit: 0，不能用 0 关闭
验证是否生效：进入容器后执行 cat /sys/fs/cgroup/pids.max，输出应为 384（cgroup v2）或 cat /sys/fs/cgroup/pids/pids.max（cgroup v1，已少见）。
docker-compose.yml 中配置 PIDs 限制
适合本地开发多服务联调，避免每次敲长命令：
services:
api:
image: my-spring-boot-app
deploy:
resources:
limits:
pids: 512
ulimits:
nproc: 512
nofile:
soft: 65536
hard: 65536
注意两点：
-
deploy.resources.limits.pids是 Docker Compose v2.20+ 支持的字段，旧版 Compose（v1 或早期 v2）不识别，会静默忽略 -
ulimits.nproc控制的是单个进程可创建的子进程数（即 RLIMIT_NPROC），和pids不同：前者是 per-process 限制，后者是 per-container 总 PID 数，优先用pids - 如果用的是 Swarm 模式（
docker stack deploy），pids限制同样生效，但需确保 Docker daemon 配置了"features": {"buildkit": true}
Mac 上验证 cgroup v2 是否启用 & 常见失败原因
Docker Desktop for Mac 默认使用 cgroup v2，但如果你手动改过内核参数或用了老旧系统镜像，可能回退到 v1。确认方法：
- 在宿主机（Mac 终端）运行：
stat -f -c "%T" /sys/fs/cgroup，输出cgroup2fs表示 v2 已启用 - 若输出
cgroup（无 2），说明是 v1，此时--pids-limit不生效，需升级 Docker Desktop 或检查 WSL2/machine 配置 - 容器内
cat /sys/fs/cgroup/pids.max返回max（字符串）而非数字？说明 cgroup v2 未挂载到容器，常见于用--cgroup-parent手动指定路径但路径错误 - Mac 上无法用
--cgroup-parent，因为 Desktop 的 VM 是封闭的，你没法直接访问/sys/fs/cgroup目录
真正容易被忽略的一点：Java 应用默认线程数可能远超预期——Spring Boot + Netty + HikariCP + scheduled tasks，轻松突破 300。别只看 ps aux | wc -l，进容器后跑 cat /sys/fs/cgroup/pids.current 才知道实时 PID 占用。设限前务必压测，否则上线就 fork 失败。
