第二列才是当前系统已分配但未释放的文件描述符总数，即真实已用总量；第一列为已分配总数（含已关闭未回收），第三列为系统上限file-max。
cat /proc/sys/fs/file-nr 显示三列数字，第二列才是已分配总数
执行 cat /proc/sys/fs/file-nr 会输出类似 12345 67890 1048576 的三列数值，其中：
- 第一列：已分配并正在使用的句柄数（含已关闭但未回收的）
- 第二列：已分配但尚未释放的句柄总数 —— 这才是你真正要关注的“已用总量”
- 第三列：系统级最大允许值（即
fs.file-max）
注意：第二列数值持续增长但不回落，往往意味着存在句柄泄漏；如果它逼近第三列，说明全局资源快耗尽了。
lsof | wc -l 是误导性统计，慎用
很多人习惯跑 lsof | wc -l 来估算总量，但这会严重高估：
- 每条 socket 连接、每个打开的管道、每个 /proc/ 下的虚拟文件都会被单独计为一行
- 同一文件被多个进程打开，会被重复计算
- 容器环境里，
lsof默认扫描所有命名空间，结果包含大量不可见或已失效的条目
它适合排查“哪个进程开得最多”，但不能替代 /proc/sys/fs/file-nr 的权威性。
为什么 ps aux | grep xxx 看不到句柄数？
因为句柄数不是进程的标准字段，ps 不提供该信息。正确做法是：
- 查指定进程 PID 后，进
/proc/<pid>/fd/</pid>目录统计：ls -l /proc/1234/fd/ 2>/dev/null | wc -l - 用
lsof -p 1234 | wc -l辅助验证，但注意加2>/dev/null忽略权限错误 - 若进程已退出但残留 fd 目录（极少见），
/proc/<pid>/fd/</pid>仍存在，需结合ps -p 1234确认存活状态
file-nr 第二列突然跳变，大概率是内核回收延迟
Linux 内核对已关闭的 fd 并非立即释放，而是延迟归还到空闲池。表现为：
- 短时并发激增后，第二列数值居高不下，但服务无异常
- 过几十秒到几分钟后缓慢回落
- 这不是 bug，是设计使然；除非长期卡在高位且持续上涨，否则无需干预
真正危险的信号是：第二列稳定在接近第三列（fs.file-max）的 90% 以上，且不再回落。
