最准确、最直接的方法是统计/proc/[pid]/fd/目录下的符号链接数量，因每个打开句柄对应一个编号链接，数量即真实占用数；查用量用ls -1 /proc/[PID]/fd/ 2>/dev/null | wc -l，查上限用cat /proc/[PID]/limits | grep "Max open files"，系统级监控应盯cat /proc/sys/fs/file-nr第二列。
最准确、最直接的方法是统计 /proc/[pid]/fd/ 目录下的符号链接数量，因为每个打开的句柄在该目录下对应一个编号链接（如 0、1、123），数量即真实占用数。
查单个进程当前用了多少句柄
执行命令：
-
ls -1 /proc/[PID]/fd/ 2>/dev/null | wc -l—— 替换[PID]为实际进程号，例如ls -1 /proc/1234/fd/ 2>/dev/null | wc -l - 普通用户只能查自己启动的进程，查当前 shell 可用：
ls -1 /proc/$$/fd/ 2>/dev/null | wc -l - 必须加
2>/dev/null，否则权限不足时错误信息会混入输出，导致计数偏高
查该进程允许打开的最大句柄数
不要依赖 ulimit -n，它只反映当前 shell 的限制，不等于子进程实际值。应读取：
cat /proc/[PID]/limits | grep "Max open files"- 输出形如
Max open files 1024 4096 files，左边是 soft limit（运行时可调，但不能超右边），右边是 hard limit（仅 root 可提） - Java、Node.js 或 systemd 服务的实际限制以该路径为准，
/etc/security/limits.conf对它们通常无效
为什么不用 lsof -p [PID] 统计
lsof 是调试工具，不是精确计数工具，容易出错：
- 默认跳过
eventpoll、inotify等内核 fd，在高并发 I/O 场景中占比很高 - 输出含表头（第一行是列名），
wc -l会多算 1 行 - 对已删除但仍被引用的文件（
deleted状态），显示不稳定，结果波动 - 当 fd 数过万时可能卡顿、超时甚至丢数
系统级句柄使用情况怎么看
单个进程句柄高 ≠ 系统瓶颈。更早发现问题的指标是全局活跃用量：
-
cat /proc/sys/fs/file-nr | awk '{print $2}'—— 第二列是当前「活跃占用」的真实值 - 输出如
12480 3210 2097152，表示已有 3210 个句柄正在被使用，第三列是系统上限fs.file-max - 该值不依赖权限、不受
lsof自身开销干扰，是监控告警的核心指标
