5

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

4

2 回答 2

6

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

于 2012-02-21T18:13:57.970 回答
1

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

于 2011-11-17T19:08:42.997 回答