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

Question

我正在使用Sun(带有Netty)和1.6.0_26，在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数量那么多。

Answer 1

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

Answer 2

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