Linux下用getrlimit(RLIMIT_NOFILE,&rl)获取进程文件描述符上限，rl.rlim_cur为软限制（当前生效值），rl.rlim_max为硬限制（需root提升）；macOS语义相同但默认值更低；Windows无统一句柄总数上限，依赖资源而非计数器。
Linux 下用 getrlimit 获取进程文件描述符上限
Linux 进程的“句柄数”实际对应文件描述符（file descriptor）数量限制，由内核资源限制（rlimit）控制，不是硬编码在 C++ 标准库里的值。必须调用系统接口获取。
关键函数是 getrlimit，传入 RLIMIT_NOFILE 类型即可读取当前进程允许打开的最大文件描述符数（即通常说的“最大句柄数”）：
#include <sys/resource.h>
#include <iostream>
struct rlimit rl;
if (getrlimit(RLIMIT_NOFILE, &rl) == 0) {
std::cout << "soft limit: " << rl.rlim_cur << "\n";
std::cout << "hard limit: " << rl.rlim_max << "\n";
}
-
rl.rlim_cur是当前生效的软限制，open()、socket()等调用受它约束 -
rl.rlim_max是硬限制，普通进程无法自行提升，需 root 权限或setrlimit配合 - 该值是 per-process 的，不等于系统全局最大（如
/proc/sys/fs/file-max） - 注意：
getrlimit返回 0 表示成功，-1 表示失败（查errno）
macOS 同样支持 getrlimit，但默认值和行为略有差异
macOS 也提供 getrlimit 和 RLIMIT_NOFILE，语义一致，但默认软限制通常更低（如 256），且硬限制可能被 launchd 或用户 shell 配置覆盖（如 launchctl limit maxfiles）。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 运行时结果可能和 Linux 不同，不能假设
rl.rlim_cur == 1024 - 若程序需要大量 socket 或文件，应在启动早期调用
setrlimit尝试提软限（前提是没超硬限） - macOS Catalina 及之后版本对后台进程有额外限制，即使设了高限也可能被系统干预
Windows 没有直接等价的“单进程句柄总数上限”API
Windows 不以统一“句柄数限制”管理资源，而是按对象类型（event、mutex、file、socket）分别计数，且没有全局 per-process 句柄总数硬上限。真正起作用的是可用内核内存（NonPagedPool）和会话句柄表大小。
立即学习“C++免费学习笔记（深入）”；
- 无法用一个 API 获得“当前进程最多还能创建多少句柄”
-
GetCurrentProcessHandleCount并不存在 —— Windows SDK 中无此函数 - 可间接估算：
GetProcessHandleCount(GetCurrentProcess(), &count)是无效写法；正确做法是用NtQueryInformationProcess+ProcessHandleCount（需ntdll.h，未公开文档，易失效） - 更实用的做法是捕获
CreateFile、CreateEvent等返回INVALID_HANDLE_VALUE且GetLastError() == ERROR_TOO_MANY_OPEN_FILES或ERROR_NO_SYSTEM_RESOURCES
跨平台封装要注意的兼容性陷阱
如果封装一个 get_max_handles() 函数供多平台使用，不能简单返回 rl.rlim_cur 或硬编码值。不同系统语义差异太大，强行统一反而误导。
- Linux/macOS：返回
rl.rlim_cur是合理且有意义的 - Windows：应返回一个保守估计值（如 16384），或直接返回 -1 表示“无明确定义的上限”，并文档注明依赖资源而非计数器
- 不要把
/proc/sys/fs/file-max当作进程上限 —— 它是全系统文件句柄总量上限，和单进程无关 - 某些容器环境（如 Docker）会重设
RLIMIT_NOFILE，务必在容器内实测，别信宿主机的值
rlimit 值在 fork 子进程时会被继承，但 systemd 服务或容器 init 进程可能已悄悄改过它 —— 别只在本地终端跑测试就认为没问题。 
