为什么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 [...] 

我无法找到关于匿名inode是什么的明确解释，我查看了Linux内核源代码树中的fs/anon_inodes.c ，似乎epoll可能会使用它，但我不知道为什么我fs/anon_inodes.c许多。 我确实有多个“epoll循环”和计时器线程，但不像我的anon_inode数量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的Direct ByteBuffers。 系统调用mmap(2)通常对文件进行操作（使用文件句柄）。 但是它还支持MAP_ANONYMOUS选项来操作内存映射而不需要实际的文件句柄。 这听起来像内部可能需要“匿名inode”的东西。