docker守护进程（dockerd）决定并发能力，而非客户端；其上限由/etc/docker/daemon.json中max-concurrent-sched（容器调度）、max-concurrent-downloads（镜像拉取）等参数控制，并需配合systemd资源限制和系统级内核调优。
docker 客户端本身不控制并发数，真正影响“并发能力”的是守护进程（dockerd）的资源调度能力和系统级限制。所谓“守护进程并发数上限”，实际指两层含义：一是同时能调度/创建多少容器（即容器启停并发），二是它自身处理 api 请求或镜像拉取等操作时的并发上限。这两者都通过 /etc/docker/daemon.json 配置，而非客户端命令。
限制容器创建与调度并发
这是最贴近“并发数上限”的配置项，用于防止瞬间大量 docker run 请求压垮 dockerd：
-
max-concurrent-sched：控制调度器每秒可处理的容器创建/启动请求数，默认无限制。设为100表示最多同时处理 100 个新建容器任务 -
max-concurrent-downloads：限制并发镜像拉取数量，避免网络和磁盘 I/O 过载（如设为5） -
max-concurrent-uploads：限制并发镜像推送数量（如设为3）
示例 daemon.json 片段：
{
"max-concurrent-sched": 80,
"max-concurrent-downloads": 8,
"max-concurrent-uploads": 4
}
约束守护进程自身资源防过载
即使调度并发设得低，若 dockerd 自身吃光 CPU 或内存，照样会卡死或崩溃。必须用 systemd 和 daemon.json 双重设限：
- 在
/etc/docker/daemon.json中启用实验特性并预留资源："experimental": true,"memory-reservation": "1g","cpu-reservation": "0.5" - 在
/etc/systemd/system/docker.service.d/override.conf中硬性限制 dockerd 进程：[Service]MemoryLimit=2GCPUQuota=75%
注意：MemoryLimit 必须大于 memory-reservation，否则 systemd 启动失败。
配套系统级防护不可少
守护进程并发能力最终受限于宿主机内核和文件描述符：
- 检查并提升 dockerd 进程的
nofile上限（非容器）：
在 systemd override.conf 中加：LimitNOFILE=65536 - 确认内核参数足够支撑高并发：
sysctl -w net.core.somaxconn=65535sysctl -w fs.file-max=2097152 - 重启生效：
sudo systemctl daemon-reload && sudo systemctl restart docker
