getrlimit是内核级系统调用，用于读取进程资源软/硬限制；prlimit和/proc/pid/limits可直接查看java进程实际生效的rlimit值，而ulimit仅作用于shell上下文，无法反映已运行java进程的真实限制。
getrlimit 系统调用是内核层面的资源限制来源，OpenJDK 进程本身不提供直接查看自身 rlimit 的命令，但你可以通过 Linux 工具链准确读取它的限制值——关键在于：必须查 *进程运行时实际生效的值*，而不是 Java 启动脚本里写的或 ulimit 命令在父 shell 里显示的。
用 prlimit 查指定 Java 进程的实时限制
这是最直接、最可靠的方式。Java 进程一旦启动，其 rlimit 就已固定（除非它自己调用 setrlimit），prlimit 能绕过 shell 层级，直读内核中该 PID 对应的 tsk->signal->rlim 数组。
- 先找 Java 进程 PID：
pgrep -f "java.*Application"或ps aux | grep java - 查所有限制：
prlimit -p <code>PID（注意是-p，不是-n） - 只查文件描述符：
prlimit -p <code>PID--nofile - 只查虚拟内存：
prlimit -p <code>PID--as
输出中 SOFT 列即当前生效值（软限制），HARD 是上限。如果看到 unlimited，说明对应项硬限制为 RLIM_INFINITY，软限制也同步为该值。
/proc/<code>PID/limits 文件比 prlimit 更底层
这个伪文件本质就是 prlimit 的数据源，但更透明，适合脚本解析或确认细节：
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
-
cat /proc/<code>PID/limits 会列出全部 25 项资源限制，含注释说明单位和含义 - 每行格式为：
Limit Soft Limit Hard Limit Units - 例如
Max open files行对应RLIMIT_NOFILE，单位是“files”，不是 KB 或 blocks - 注意：
Max processes对应RLIMIT_NPROC，不是/proc/sys/kernel/pid_max—— 后者是全系统 PID 编号上限，前者才是该用户能起多少进程
为什么 ulimit -a 在 Java 进程里执行无效
因为 ulimit 是 shell 内建命令，它只作用于当前 shell 及其子进程的 *启动上下文*。Java 进程已脱离原始 shell，且 JVM 通常以 fork+exec 方式启动，不会继承父 shell 的 ulimit 设置（除非显式用 exec -c 或类似方式）。
- 在 Java 进程里执行
bash -c "ulimit -n"得到的是新 bash 的限制，跟 Java 无关 - 即使你在启动 Java 前设置了
ulimit -n 65536，也要确认该设置是否真正传递给了 JVM 进程 —— 最稳妥办法仍是查/proc/<code>PID/limits - systemd 服务启动的 Java 进程，
/etc/security/limits.conf默认不生效，得在 service 文件里加LimitNOFILE=65536才行
Java 应用自身能否读取这些限制
标准 JDK API 不暴露 getrlimit，但可通过 JNA 或 JNI 调用原生接口。不过绝大多数场景没必要——运维排查时直接用 prlimit 或 /proc/<code>PID/limits 更快；应用内部真需要感知（比如预估最大连接数），应以配置驱动，而非动态读取内核限制。
容易被忽略的一点：Java NIO 的 FileChannel.map() 受 RLIMIT_AS（地址空间）限制，不是 RLIMIT_DATA；而大量 new Thread() 失败时，错误日志里报 java.lang.OutOfMemoryError: unable to create native thread，根源往往是 RLIMIT_NPROC 或 /proc/sys/vm/max_map_count，不是堆内存不足。
