linux下用getrlimit读取rlimit_nofile可获取当前进程文件描述符软硬限制，软限制（rlim_cur）为实际生效值，硬限制（rlim_max）为其上限；需包含、检查返回值、注意容器和systemd等环境覆盖。
Linux下用 getrlimit 读取 RLIMIT_NOFILE
在 Linux 系统上，当前进程能打开的最大文件描述符数由资源限制 RLIMIT_NOFILE 控制，getrlimit 是标准且可靠的方式。它返回软限制（当前生效值）和硬限制（上限，通常需 root 修改），多数场景关心软限制。
常见错误是只调用一次却不检查返回值，或误把硬限制当实际可用值。软限制可能远低于硬限制，且受 systemd、shell ulimit 或容器限制影响。
- 必须包含
<sys></sys>头文件 -
struct rlimit rl;需初始化，否则rlim_cur可能为随机值 - 调用后务必检查返回值：
if (getrlimit(RLIMIT_NOFILE, &rl) == -1)表示失败（如权限不足或内核不支持） - 软限制存于
rl.rlim_cur，单位是个数（不是字节），典型值如 1024、65536
#include <sys>
struct rlimit rl;
if (getrlimit(RLIMIT_NOFILE, &rl) == 0) {
printf("soft limit: %ld\n", rl.rlim_cur);
}</sys>
macOS 上 getrlimit 同样适用但默认值不同
macOS 也支持 getrlimit 和 RLIMIT_NOFILE，行为一致，但默认软限制通常是 256，硬限制为 10240 —— 这比很多 Linux 发行版更保守，容易在启动高并发服务时触发 Too many open files 错误。
注意：macOS 不支持通过 setrlimit 将软限制提至超过硬限制，且非 root 用户无法提升硬限制。若程序需要更高上限，必须提前在 shell 中运行 ulimit -n 8192，或修改 /etc/launchd.conf（已弃用）或使用 launchctl limit maxfiles。
- 不要假设 Linux 的默认值在 macOS 上成立
- 测试时建议显式调用
ulimit -Sn查看当前 shell 限制，再对比程序内读到的值 - 某些 macOS 版本对
RLIMIT_NOFILE的硬限制有额外内核级封顶（如 10240），即使launchctl设置更高也可能被截断
跨平台可移植性问题：Windows 没有等价机制
Windows 没有文件描述符（file descriptor）概念，而是使用句柄（handle），且没有统一的“最大句柄数”全局限制 —— 它取决于进程可用内存、系统句柄表大小及每个句柄类型的具体开销。因此，getrlimit 在 Windows 上不可用，RLIMIT_NOFILE 未定义。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
如果代码需跨平台，不能简单 #ifdef 报错，而应提供降级路径：例如记录日志说明 “Windows 不适用”，或改用 _getmaxstdio()（仅反映 C 运行时 stdio 流上限，非系统级）或查询 GetHandleInformation 辅助判断，但这些都无法替代 RLIMIT_NOFILE 的语义。
- 避免在 Windows 上 #include
，会编译失败 - 不要试图用
_setmaxstdio推断系统能力 —— 它只控制 fopen/fdopen 能创建的 FILE* 数量，与 socket、pipe 等无关 - 真正需要句柄压力测试时，Windows 应直接尝试分配并捕获
INVALID_HANDLE_VALUE+GetLastError() == ERROR_TOO_MANY_OPEN_FILES
容器环境里读到的值可能被 cgroup 二次限制
在 Docker 或 Kubernetes 中，即使 getrlimit 返回 65536，实际能打开的 fd 数仍可能被 cgroup v1 的 tasks 或 v2 的 io.max、pids.max 间接压制。更关键的是，docker run --ulimit nofile=1024:2048 会覆盖宿主机设置，此时 getrlimit 读到的就是该限制值，而非宿主机原值。
容易忽略的一点：某些容器运行时（如 containerd）在启动时会重置 rlimit，导致子进程继承的值与父容器配置不一致；若用 exec 进入容器再运行程序，看到的可能是 shell 的 ulimit，而非容器 runtime 设置的原始值。
- 验证时应在容器内直接运行你的二进制，而非先
sh再执行 - 检查
/proc/self/status中的Threads:和FDSize:字段，后者是内核为该进程预分配的 fd 表大小，不一定等于 rlimit - systemd 服务中若设了
LimitNOFILE=，它最终也会映射为setrlimit，优先级高于用户 shell ulimit
实际获取时，getrlimit 是唯一通用、轻量、无需特权的手段，但它的返回值只是“允许你尝试的上限”，不代表内存或内核资源真够用 —— 真正瓶颈常出现在 epoll 或 select 的 FD_SETSIZE、或 per-process 内存占用上。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
