Docker中需通过--ulimit或docker-compose.yml显式设置nofile软硬限制以防止文件描述符耗尽，默认继承宿主机1024值；软限可运行时调整但不可超硬限，硬限需root权限或sys_resource能力才能修改。
在 Docker 中通过 ulimit 限制容器内进程可打开的最大文件数（即 nofile），是防止程序因打开过多文件导致系统资源耗尽或崩溃的关键手段。默认情况下，Docker 容器继承宿主机的 ulimit 设置（通常是 1024），往往远低于高并发服务（如 Nginx、Redis、Java 应用）的实际需求，也容易成为性能瓶颈。
理解 ulimit nofile 的两个维度
nofile 包含软限制（soft limit）和硬限制（hard limit）：
- 软限制：进程实际生效的上限，可在运行时自行调低，但不能超过硬限制；应用启动时若未显式设置，就受此值约束
-
硬限制：软限制能提升的最高阈值，通常需 root 权限或容器具备
sys_resource能力才能突破
例如：ulimit -n 65536 只改软限；而 ulimit -Hn 65536 才设硬限。Docker 默认只设置软限，且硬限常被锁在 1048576（Linux 内核默认），但容器内未必能直接修改硬限——除非显式授权。
在 docker run 中设置 ulimit
使用 --ulimit 参数一次性指定软/硬限制，格式为 type=soft:hard：
-
docker run --ulimit nofile=65536:65536 nginx—— 同时设软硬限为 65536 -
docker run --ulimit nofile=32768:65536 nginx—— 软限 32768，硬限 65536，允许容器内进程后续调高软限 - 支持多个 ulimit 类型，如：
--ulimit nofile=65536:65536 --ulimit nproc=4096:4096
⚠️ 注意：该参数仅对容器主进程（PID 1）及其子进程生效；若容器内用 supervisord 或 bash -c 启动多进程，需确保启动脚本不重置 ulimit，否则子进程可能回落到默认值。
在 docker-compose.yml 中配置 ulimit
适用于编排场景，语法清晰且易复用：
services:
app:
image: my-java-app
ulimits:
nofile:
soft: 65536
hard: 65536
nproc: 4096
等效于命令行中的 --ulimit。若只需设软限，可简写为 nofile: 65536（此时硬限保持 Docker 默认值）。建议生产环境明确写出软硬限，避免隐式行为差异。
验证与调试容器内 ulimit 是否生效
进入运行中的容器检查实际值：
-
docker exec -it <container> sh -c 'ulimit -n'→ 查看当前软限制 -
docker exec -it <container> sh -c 'ulimit -Hn'→ 查看硬限制 -
docker exec -it <container> cat /proc/1/limits | grep "Max open files"→ 直接读取内核视图，最权威
常见陷阱：某些基础镜像（如 alpine:latest）默认未安装 procps，ulimit 命令可能不可用，此时优先用 /proc/1/limits 方式确认。
不复杂但容易忽略——ulimit 是容器级资源边界，不是镜像属性，必须在运行时声明；且需结合应用自身配置（如 Nginx 的 worker_rlimit_nofile、Java 的 -XX:MaxFDLimit）协同生效。
