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

Question

我正在使用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是什么的明确解释,我fs/anon_inodes.c在Linux内核的源代码树中看到它似乎可能epoll使用它,但我不知道为什么我会有这么多.我有多个"epoll循环"和计时器线程,但不像我的数量那么多anon_inode.

Answer 1

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

Answer 2

也许这些 inode 与内存映射“文件”相关，这些文件将转换为 Java 的直接字节缓冲区。系统调用mmap(2)通常对文件进行操作（使用文件句柄）。但它还支持MAP_ANONYMOUS在没有实际文件句柄的情况下操作内存映射的选项。这听起来像是内部可能需要“匿名索引节点”的东西。