为什么 JDK NIO 使用了这么多 anon_inode 文件描述符？答案

【问题标题】：Why is the JDK NIO using so many anon_inode file descriptors?为什么 JDK NIO 使用了这么多 anon_inode 文件描述符？
【发布时间】：2011-12-31 12:53:28
【问题描述】：

我正在使用 Sun 的 JDK 1.6.0_26 和 NIO（带有 Netty），在 lsof 中我看到数百个文件描述符是 anon_inode：

$ lsof -np 11225 | fgrep -w anon_inode
java    11225 nobody   57u     0000                0,9         0     1386 anon_inode
java    11225 nobody   61u     0000                0,9         0     1386 anon_inode
java    11225 nobody   65u     0000                0,9         0     1386 anon_inode
java    11225 nobody   69u     0000                0,9         0     1386 anon_inode
java    11225 nobody   73u     0000                0,9         0     1386 anon_inode
java    11225 nobody   77u     0000                0,9         0     1386 anon_inode
java    11225 nobody   81u     0000                0,9         0     1386 anon_inode
java    11225 nobody   86u     0000                0,9         0     1386 anon_inode
java    11225 nobody   89u     0000                0,9         0     1386 anon_inode
java    11225 nobody   93u     0000                0,9         0     1386 anon_inode
java    11225 nobody   97u     0000                0,9         0     1386 anon_inode
[...]

我找不到关于什么是匿名 inode 的明确解释，我在 Linux 内核的源代码树中查看了 fs/anon_inodes.c，似乎 epoll 使用它，但我不知道为什么我会有这么多。我确实有多个“epoll 循环”和计时器线程，但没有我的 anon_inode 数量那么多。

【问题讨论】：

很难说没有看到更多信息，比如一些代码。
套接字每个使用两个文件描述符，我假设这些匿名 inode 是文件描述符，因为它们不在文件系统上。

标签： java linux-kernel nio inode netty

【解决方案1】：

确实很可能是epoll。从早期的 JDK 1.6.x 版本之一开始，选择器默认使用 epoll，除了套接字本身使用的描述符之外，此选择器 impl 使用比旧版本更多的文件描述符。如果您使用单个 SocketChannel 注册多个选择器，您还将使用更多文件描述符，例如用于读取和写入的单独选择器。如果 Netty 使用 NIO，它几乎肯定会使用选择器。在一个应用程序中，由于使用了基于 epoll 的选择器，我的文件描述符与套接字的比率约为 4 比 1。可以通过更改 java.nio.channels.spi.SelectorProvider 属性恢复到旧的选择器实现，这将减少描述符的数量，但可能会以性能为代价（YMMV）。

【讨论】：

【解决方案2】：

也许这些 inode 与内存映射的“文件”有关，这些文件将转换为 Java 的 Direct ByteBuffer。系统调用mmap(2) 通常对文件进行操作（使用文件句柄）。但它也支持选项MAP_ANONYMOUS 来操作内存映射，而无需实际的文件句柄。这听起来像是在内部可能需要一个“匿名 inode”。

【讨论】：