Linux怎么查看具体的描述符占用

更稳妥的做法，其实是直接去读 /proc/[pid]/fd/ 这个目录：先用 ls -l 把所有数字形式的 fd 项列出来，再通过 readlink 看它们各自指向哪里；接着把 stdin/stdout/stderr 这类伪路径过滤掉，同时结合 stat 或 readlink 失败的结果判断该 fd 是否已经关闭，这样就能尽量不依赖 lsof 之类的外部工具。

怎么查某个进程当前打开的 fd 列表

直接读 /proc/[pid]/fd/ 是最轻量、最可靠的方式，不需要额外工具，也不受权限限制（只要能访问该进程的 proc 目录）。每个数字子项就是一个打开的 fd，readlink 能看出它指向什么。

• 先拿到 PID，比如 pgrep nginx 或 pidof mysqld
• 执行 ls -l /proc/1234/fd/，输出类似：
  0 -> /dev/pts/0
3 -> socket:[123456]
4 -> /var/log/nginx/access.log
• 想只看真实文件（排除 stdin/stdout/stderr），加过滤：ls -l /proc/1234/fd/ | awk '$NF !~ /^/dev/pts/|^/proc/|^/sys// {print}'
• 注意：符号链接失效（如 readlink: No such file or directory）通常意味着 fd 已关闭但未被回收，属于内核延迟释放，不是泄漏

为什么 lsof -p PID 有时不准或报错

lsof 看起来全面，但实际容易出问题：权限不足时跳过部分条目；遇到已关闭但未清理的 fd 会显示 can't identify protocol 或直接漏掉；某些容器环境或 seccomp 限制下根本跑不起来。

• 常见错误：lsof: no pwd entry for UID xxx —— 不影响计数，但说明用户数据库缺失，lsof -n -p PID 可绕过 DNS/UID 解析
• 统计总数别用 lsof -p PID | wc -l，它包含表头和空行；稳妥写法：lsof -n -p PID 2>/dev/null | grep -v "COMMAND" | wc -l
• 真正要定位泄漏点，优先用 lsof -n -p PID | awk '{print $9}' | sort | uniq -c | sort -nr | head -5，看哪些路径重复最多

cat /proc/[pid]/status 里的 FDs 和 FDSize 是啥

这两个字段是内核快照值，非实时精确计数，但适合快速巡检。它们来自同一内存结构，比遍历 /proc/[pid]/fd/ 开销小得多。

• 执行 cat /proc/1234/status | grep -E 'FDs|FDSize'，输出形如：
  FDSize: 256
FDs: 42
• FDs 是当前已分配且活跃的 fd 数（≈ ls /proc/[pid]/fd/ | wc -w）
• FDSize 是内核为该进程预分配的 fd 槽位总数（通常是 256、1024、2048 等 2 的幂），不是限制值，只是内部哈希表大小
• 如果 FDs 接近 FDSize，说明进程频繁扩容 fd 表，可能有泄漏或设计缺陷

怎么确认某个 fd 是否真在用

光看 /proc/[pid]/fd/ 里有链接不够，得验证它是否还绑定有效资源。很多“僵尸 fd”其实是 close() 调用后未被内核立即回收的残留。

• 对 fd 3 执行：readlink /proc/1234/fd/3，若返回 No such file or directory，大概率已关闭
• 更准一点：用 stat /proc/1234/fd/3 2>/dev/null | grep -q "No such file" 判断是否存在
• 如果 readlink 成功但目标路径是 socket:[123456] 或 anon_inode:[eventpoll]，说明是网络连接或 epoll 实例，属正常活跃状态
• 真正可疑的是大量指向 pipe:[...] 或 inotify 却长期不读写的 fd，这类容易堆积