linux下用getrlimit获取rlimit_nofile可得进程软硬限制，软限制（rlim_cur）为当前生效值，硬限制（rlim_max）为其上限；macos行为一致但默认值更保守；windows无等价机制。
Linux 下用 getrlimit 获取进程文件描述符软硬限制
在 Linux 系统中，单个进程能打开的最大文件句柄数由 RLIMIT_NOFILE 限制控制，分软限制（soft limit）和硬限制（hard limit）。软限制可被进程自行调低或在权限允许时调高；硬限制只能由 root 提升，普通进程只能降低它。
直接调用 getrlimit 即可读取当前值：
#include <sys>
#include <iostream>
struct rlimit rl;
if (getrlimit(RLIMIT_NOFILE, &rl) == 0) {
std::cout
<ul>
<li>
<code>rl.rlim_cur</code> 是当前生效的软限制，即 <code>open()</code> 等系统调用实际受阻的阈值</li>
<li>
<code>rl.rlim_max</code> 是该进程能设到的最高软限制（除非是 root，否则不能突破此值）</li>
<li>若程序由 systemd 启动，需检查 <code>LimitNOFILE=</code> 配置项，它会覆盖 shell 的 ulimit 设置</li>
<li>注意：该值反映的是「当前进程」的限制，不是系统全局最大值（如 <code>/proc/sys/fs/file-max</code>）</li>
</ul>
<h3>macOS 上 getrlimit 行为一致但默认值不同</h3>
<p>macOS 同样支持 <code>getrlimit(RLIMIT_NOFILE, ...)</code>，语义与 Linux 完全相同。但默认软限制通常更低（例如 256），硬限制可能高达 10240 或更高，具体取决于系统版本和启动方式。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2823" title="C++14"><img
src="https://img.php.cn/upload/manual/001/431/639/6ac8b33c327c4749.png" alt="C++14" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="overflowclass">C++14</a>
<p class="overflowclass">C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<ul>
<li>终端中启动的进程继承自 shell 的 ulimit，可通过 <code>ulimit -n</code> 查看</li>
<li>GUI 应用（如从 Finder 双击运行）可能继承自 launchd，其默认限制更保守，需在 <code>plist</code> 中显式配置 <code>SoftResourceLimits</code> / <code>HardResourceLimits</code>
</li>
<li>调用 <code>setrlimit</code> 尝试提限时，若超出硬限制会返回 <code>EPERM</code>，不是 <code>EAGAIN</code> 或 <code>EMFILE</code>
</li>
</ul>
<h3>Windows 没有等价的 per-process 文件句柄硬限额</h3>
<p>Windows 不提供类似 <code>RLIMIT_NOFILE</code> 的内核级 per-process 句柄总数限制。它的句柄数量受限于进程可用内存、系统 Paged Pool 大小，以及每个句柄对象的内核开销。</p>
<ul>
<li>可通过 <code>GetProcessHandleCount()</code> 获取当前已打开句柄数，但它不告诉你“上限”，只返回实时计数</li>
<li>没有标准 API 能查到“还能再开多少个”，因为这个“上限”是动态浮动的</li>
<li>实践中，当 <code>CreateFile</code>、<code>socket</code> 等返回 <code>INVALID_HANDLE_VALUE</code> 且 <code>GetLastError() == ERROR_TOO_MANY_OPEN_FILES</code> 时，才说明触达了某种资源瓶颈——但这更多是历史兼容层（如 C runtime 的 <code>_open</code>）模拟的限制，非内核强制</li>
<li>若依赖跨平台统一逻辑，建议在 Windows 上把软性上限设为一个保守值（如 8192），并配合 <code>GetProcessHandleCount()</code> 做运行时预警</li>
</ul>
<h3>为什么不能只看 /proc/<pid>/limits？</pid>
</h3>
<p>虽然 Linux 下 <code>/proc/<pid>/limits</pid></code> 可人工查看，但它本质是 <code>getrlimit</code> 的文本封装，且存在几个关键盲区：</p>
<ul>
<li>该文件只对本用户拥有读权限的进程可见；调试别人进程时往往打不开</li>
<li>它显示的是进程启动时的限制，若进程中途调用 <code>setrlimit</code> 修改过，<code>/proc/<pid>/limits</pid></code> 不会刷新（内核不会回写）</li>
<li>容器环境（如 Docker）中，cgroup v1 的 <code>tasks</code> 和 <code>cgroup.procs</code> 可能导致 <code>/proc/<pid>/limits</pid></code> 显示宿主机值，而实际生效的是 cgroup 的 <code>pids.max</code> 或 <code>io.max</code> 等间接约束</li>
<li>真正可靠的永远是进程内调用 <code>getrlimit</code> ——它读的是内核为该 task_struct 维护的实时字段</li>
</ul>
实际部署时最容易被忽略的是：systemd 服务的 <code>LimitNOFILE=</code> 必须在 service unit 文件中显式设置，且 reload 后需 restart 服务才能生效；仅 <code>systemctl daemon-reload</code> 不够。</iostream></sys>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
