c++如何获取当前打开的文件描述符上限【技巧】

在Linux下开发，文件描述符上限是个绕不开的话题。进程能打开多少文件、多少socket，都由这个上限决定。如果搞不清它到底是多少，程序可能莫名其妙地挂掉。先明确一个核心结论：直接调用 getrlimit(RLIMIT_NOFILE, &rlim) 就能拿到软限和硬限，分别对应 rlim.rlim_cur 和 rlim.rlim_max。软限是当前生效的，硬限是你能通过 setrlimit 提升的天花板——普通进程通常无权突破硬限。

不少人习惯用 cat /proc/self/limits 来查看，这虽然可行，但开销大、需要解析文本，还依赖 procfs 挂载。其实 getrlimit 是纯系统调用，零解析、无IO，所有 Linux 发行版都支持，效率高得多。

使用时需要注意几个细节：必须包含 和 ；rlimit 结构体中的 rlim_cur 可能为 RLIM_INFINITY（值为 -1），打印前最好判断一下；这个值是针对当前进程的，fork 后子进程会继承该限制，但父进程后续调用 setrlimit 与子进程无关。

为什么 ulimit -n 显示的值和 getrlimit 返回不一致？

终端里执行 ulimit -n 看到的是 shell 启动时继承的软限，而你的 C++ 程序运行后可能已经被其他代码（比如某些框架或初始化逻辑）调用过 setrlimit 修改过。更关键的是：ulimit 显示的是当前 shell 的限制，不是你程序的运行时限制。

实操建议：在程序入口（如 main() 开头）立刻调用 getrlimit 并打印，才能反映真实值。别依赖外部命令，也别假设它和 shell 一致。

几个容易踩的坑：shell 的 ulimit -n 只影响它 fork 出的子进程的初始值，不锁定已运行进程；systemd 服务可能被 LimitNOFILE= 覆盖，此时 getrlimit 返回的就是 systemd 设置后的值；容器环境（如 Docker）中，--ulimit nofile=... 会作用于 init 进程，你的程序只是继承它。

修改上限要用 setrlimit，但注意权限和顺序

想临时提上限，得先用 setrlimit(RLIMIT_NOFILE, &new_rlim)。但有两个硬约束：软限不能超过硬限；非 root 进程只能把软限提到硬限，不能提高硬限本身。

典型的失败场景：程序启动后先打开了大量 fd，再试图调高软限——会失败，因为内核要求新软限 ≤ 当前已用 fd 数（防止“假提升”）。所以必须在打开任何文件前尽早设置。推荐在 main() 最开头，甚至 __attribute__((constructor)) 函数里调用。

如果确实需要突破系统硬限（比如从 1024 提到 65536），必须提前用 sudo ulimit -Hn 65536 或配置 /etc/security/limits.conf。setrlimit 失败时 errno 会是 EPERM（权限不足）或 EINVAL（数值非法），务必检查返回值。

跨平台？Windows 没有等价机制

Windows 不使用“文件描述符”抽象，而是 HANDLE，且没有全局统一的 per-process 上限概念。C runtime 层面有 _setmaxstdio() 控制 stdio 流数量（默认 512），但这和内核句柄数无关；真正瓶颈是 GetProcessHandleCount() 返回的句柄总数，上限由系统内存和对象管理器决定，无法用类似 getrlimit 的接口查询。

如果你写的是跨平台代码，别试图封装一个通用函数——Linux 用 getrlimit，Windows 直接跳过或记录为“不可查”。强行抽象只会掩盖差异，导致线上 Linux 机器 fd 耗尽时 Windows 侧毫无预警。实际部署时，Linux 服务必须监控 /proc/PID/fd/ 目录项数量，这是唯一可靠的方式；而 Windows 更应关注 PerfMon 中 “Process\Handle Count” 计数器。