最常用可靠方式是启动容器时用--ulimit nofile指定软硬限制，如docker run --ulimit nofile=65536:65536 nginx；需注意仅作用于PID 1及其直系子进程，宿主机limits亦须配置足够。
直接在启动容器时用 --ulimit nofile 指定软硬限制，是最常用、最可靠的方式。默认值（通常是 1024）远不够高并发服务使用，不配置容易触发 “too many open files” 错误。
用 docker run 设置 nofile 限制
命令行方式适合调试、CI/CD 或单次部署：
-
docker run --ulimit nofile=65536:65536 nginx：软限和硬限都设为 65536，应用启动即生效 -
docker run --ulimit nofile=32768:65536 redis：软限 32768（初始可用值），硬限 65536（允许运行时调高） - 可同时设置多个类型：
--ulimit nofile=65536:65536 --ulimit nproc=4096:4096
⚠️ 注意：该限制只作用于容器主进程（PID 1）及其直接子进程。如果容器内用 bash -c、su 或 supervisord 启动，需确保启动脚本开头显式执行 ulimit -n 65536，否则子进程可能回落到默认值。
用 docker-compose.yml 配置 ulimits
生产环境推荐，便于版本管理与协作：
- 完整写法（明确软硬限）：
services:
app:
image: my-java-app
ulimits:
nofile:
soft: 65536
hard: 65536
nproc:
soft: 4096
hard: 4096
- 简写形式（软硬限相同）：
nofile: "65536:65536"或nofile: 65536（此时硬限沿用 Docker 默认值） - Docker Compose v2.20+ 支持该语法；旧版本需升级或改用 entrypoint 脚本补 ulimit
验证容器内 nofile 是否生效
别只信配置，要进容器看真实值：
- 查当前软限制：
docker exec -it <container> sh -c 'ulimit -n'</container> - 查硬限制：
docker exec -it <container> sh -c 'ulimit -Hn'</container> - 最权威方式（读内核视图）：
docker exec -it <container> cat /proc/1/limits | grep "Max open files"</container>
输出应类似 Max open files 65536 65536 files，两个数字一致才表示软硬限都已正确加载。
宿主机层面不能忽略的准备
Docker 容器无法突破宿主机的用户级限制。若发现即使配置了 --ulimit，容器内仍卡在低值（如 1024），请检查：
- 运行
dockerd的用户（通常是root或docker用户）本身的ulimit -n和ulimit -Hn值是否足够 - 必要时修改
/etc/security/limits.conf，例如添加：
docker soft nofile 1048576<br> docker hard nofile 1048576
- 若 dockerd 由 systemd 管理，还需在
/usr/lib/systemd/system/docker.service中添加：
[Service]<br> LimitNOFILE=1048576
，然后systemctl daemon-reload && systemctl restart docker
