可直接执行cat /proc/[pid]/limits查看单个进程的FD限制，关键行是“Max open files”，第三列为软限制、第四列为硬限制，需按字段名匹配而非行号，且调用方须有读取权限。
如何用 /proc/[pid]/limits 查看单个进程的 FD 限制
Linux 每个进程的文件描述符（FD）限制是独立设置的，/proc/[pid]/limits 是最直接、最权威的来源。它不依赖系统全局配置，也不受 shell ulimit 当前会话影响，反映的是该进程实际生效的软/硬限制。
实操时注意：[pid] 必须是目标进程的真实 PID，且调用方需有读取权限（通常要求同用户或 root）。非特权用户无法读取其他用户的 /proc/[pid]/limits。
- 用
std::ifstream打开/proc/1234/limits，逐行解析；关键字段是Max open files行，其第 3 列为软限制（Soft limit），第 4 列为硬限制（Hard limit） - 不要依赖固定行号——不同内核版本字段顺序一致，但空行或注释可能变化；必须按字段名匹配
- 示例关键片段：
Max open files 1024 4096 files
→ 软限 1024，硬限 4096
为什么不能只读 /proc/sys/fs/file-max
/proc/sys/fs/file-max 是整个系统的最大可分配 FD 总数，不是单个进程的限制。它和进程级限制无直接换算关系，混淆会导致误判——比如系统设为 100 万，但某进程仍可能被 ulimit -n 1024 卡死。
常见错误：在监控程序中只查 file-max 就断言“FD 不够用”，结果发现瓶颈其实在某个服务进程自己的软限上。
立即学习“C++免费学习笔记（深入）”；
-
file-max影响的是内核能维护的总 file struct 数量，属于资源池上限 - 进程实际能用多少，取决于
setrlimit(RLIMIT_NOFILE, ...)的调用历史，最终固化在/proc/[pid]/limits中 - 若需评估系统整体 FD 压力，应同时采集
/proc/sys/fs/file-nr（已分配/未使用/最大）
用 getrlimit 在运行时获取当前进程限制
如果 C++ 程序需要知道自己当前的 FD 限制（比如做自适应连接池大小），应直接调用 getrlimit(RLIMIT_NOFILE, &rlim)，而非去读 /proc/self/limits。前者更快、更可靠，且不依赖 procfs 挂载状态。
注意结构体字段：rlim.rlim_cur 是软限制（可被进程自身提升，直到硬限），rlim.rlim_max 是硬限制（仅 root 可提高）。
- 软限为 0 表示“不限制”？错——Linux 中软限为 0 是合法值，代表禁止打开任何新文件（极少见，但可能由恶意配置或容器限制触发）
- 调用
getrlimit后务必检查返回值，失败时errno可能是EPERM（如在某些容器安全策略下） - 不要在信号处理函数中调用
getrlimit——它不是 async-signal-safe 函数
容器环境下的特殊表现与绕过方式
Docker、Podman 等容器运行时常通过 --ulimit 或 cgroup v1/v2 限制 FD，此时 /proc/[pid]/limits 显示的硬限可能远低于宿主机 file-max，且 getrlimit 返回值与之严格一致。这是预期行为，不是 bug。
真正容易踩坑的是：在容器里用 fork() + exec() 启动子进程时，子进程继承父进程的 rlimit，但若父进程曾调用 setrlimit 降低硬限，则子进程无法再提回——cgroup 的硬限是不可逆的。
- 检查是否在容器中：读
/proc/1/cgroup，若含docker/、kubepods/或podman/路径，就按容器逻辑处理 - 若需调试，可用
cat /sys/fs/cgroup/pids/$(cat /proc/1/cgroup | head -1 | cut -d: -f3)/pids.max（cgroup v2）辅助验证进程数限制是否联动影响 FD 分配 - 避免在容器启动后动态调用
setrlimit提升硬限——大概率失败并返回EPERM
/proc/[pid]/limits 的字段名匹配逻辑，也别假设 getrlimit 总是成功——尤其在强化安全策略的生产环境里，失败才是常态。 
