查单个进程实际句柄用量最准方法是统计/proc/[pid]/fd/目录下符号链接数，即ls -1 /proc/[pid]/fd/ 2>/dev/null | wc -l；其上限应查/proc/[pid]/limits中“max open files”软硬限，而非ulimit -n。
查单个进程实际用了多少句柄，用 ls -1 /proc/[pid]/fd/
最准、最快、最稳定的方法就是直接数 /proc/[pid]/fd/ 目录下的符号链接数量。Linux 内核为每个打开的句柄在这个目录下建一个编号链接（比如 0、1、123），所以数量即真实用量。
-
ls -1 /proc/1234/fd/ 2>/dev/null | wc -l是标准写法：2>/dev/null必须加，否则权限不足时会输出错误信息混入计数 - 普通用户只能查自己进程，比如查当前 shell：
ls -1 /proc/$$/fd/ 2>/dev/null | wc -l - 别用
lsof -p 1234 | wc -l：它要扫描所有 fd 类型并格式化输出，慢、易卡顿、在 fd 数过万时可能丢数或超时 - 注意：这个值是“当前正在使用的句柄数”，不含已关闭但尚未被内核回收的残留（那种情况极少，且
file-nr第二列已覆盖）
查进程允许打开的最大句柄数，看 /proc/[pid]/limits
进程的真实上限不是 ulimit -n 当前 shell 的值，而是它启动时继承或设置的 RLIMIT_NOFILE —— 这个记录在 /proc/[pid]/limits 里。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 运行
cat /proc/1234/limits | grep "Max open files"，输出类似：Max open files 1024 4096 files - 左边是 soft limit（运行时可调，但不能超右边），右边是 hard limit（只有 root 能提）
- 如果程序启动后改过 ulimit，这个值可能和父进程不同；systemd 服务默认不读
/etc/security/limits.conf，得单独配LimitNOFILE= - Java 应用常因 JVM 启动参数或容器环境覆盖该限制，此时
/proc/[pid]/limits才是唯一可信来源
为什么 lsof -p [pid] 统计不准
lsof 不是“数句柄”的工具，它是“列出打开文件信息”的调试工具 —— 它的输出设计就不是为精确计数服务的。
- 默认会跳过部分内核 fd（如
eventpoll、inotify实例），这些在高并发 I/O 场景中占比很高 - 输出含表头（第一行是列名），
wc -l会多算 1 行；若加-n或-P还可能因 DNS/端口解析失败中断 - 对已删除但仍被引用的文件（
deleted状态），lsof有时显示有时不显示，导致结果波动 - 真正需要定位“哪个 fd 是什么类型”时再用
lsof -p [pid]，别拿它当计数器
监控告警该盯哪个指标
单个进程句柄数只是局部信号；系统级瓶颈往往先体现在全局统计上 —— 尤其当大量短连接服务（如 HTTP 网关）同时上线时。
- 核心指标是
/proc/sys/fs/file-nr的第二列：cat /proc/sys/fs/file-nr | awk '{print $2}' - 它代表“当前真正被占用的句柄总数”，不依赖权限、不漏类型、不因 lsof 自身开销失真
- 别用
lsof | wc -l替代：权限失败会中断，还混入空行和表头；lsof -i更糟，只扫 socket，漏掉 timerfd/eventfd/普通文件等 - 预警阈值建议设为
file-max的 80%，而不是等报Too many open files才行动
ulimit 不等于改了 systemd 服务的限制，改了 fs.file-max 不等于单个 Java 进程就能用到那么多。查句柄必须分清“谁在用”“谁允许用”“系统总共能给多少”，三者缺一不可。
