查找哪个线程导致过多的打开文件问题，以及为什么lsof输出中重复的节点in。

Question

我们的java应用程序在长时间运行后抛出了“太多打开的文件”问题。在调试该问题时，可以看到，有那么多fds处于打开状态，就像按照lsof输出一样。

# lsof -p pid | grep "pipe" | wc -l

698962

# lsof -p pid | grep "anon_inode" | wc -l

349481

COMMAND   PID  USER   FD  TYPE             DEVICE SIZE/OFF       NODE NAME
java    23994  app 464u  0000                0,9        0       3042 anon_inode
java    23994  app 465u  0000                0,9        0       3042 anon_inode
java    23994  app 466r  FIFO                0,8      0t0  962495977 pipe
java    23994  app 467w  FIFO                0,8      0t0  962495977 pipe
java    23994  app 468r  FIFO                0,8      0t0  963589016 pipe
java    23994  app 469w  FIFO                0,8      0t0  963589016 pipe
java    23994  app 470u  0000                0,9        0       3042 anon_inode
java    23994  app 471u  0000                0,9        0       3042 anon_inode

如何找出产生FIFO和0000等多个开放式FDs的根本原因。在我们的应用程序中没有太多的文件读/写。有这么多TCP消息使用apache框架从流中读取，该框架内部使用Nio。

这些是我的问题

1. 我们检查了/proc/pid/任务/文件夹。有很多文件夹。它是否对应于线程ids？但是根据j堆栈，有141个线程，因为这个文件夹有209个子文件夹。
2. 如何查找哪个线程导致fd泄漏？在本例中，任务文件夹中的大多数文件夹对应于许多fds。即。/proc/pid/task/threadid/fd文件夹有许多fd记录
3. lsof中产生管道和anon_inodes的可能原因是什么？
4. FD类型0000的含义是什么？
5. 所有anon_inode都具有相同的节点id 3042。这是什么意思？

Answer 1

最有可能的情况是，您正在打开资源，但没有正确地关闭它们。确保您使用了适当的方法，例如，尝试-使用-资源或尝试-最后块来清理。

要找到问题，您应该通过一个类路由所有IO，然后跟踪打开和关闭，甚至可能记住堆栈跟踪。然后，您可以查询这个问题，并查看您在哪里泄漏资源。

Answer 2

我们发现了问题。有一个创建org.apache.mina.transport.socket.nio.NioSocketConnector的代码流，但在某些条件下不关闭。为了找到这个问题，我们做了以下工作

1. 我们在linux服务器中启用了strace。
2. 我们为这个过程做了几分钟
3. 我们可以识别导致问题的线程id。
4. 在j堆栈中，我们找到了线程类。