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

我正在使用 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
[...]

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

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