Почему 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
[...]

Я не смог найти четкого объяснения того, что такое анонимный инод, я посмотрел на fs/anon_inodes.c в дереве исходных кодов ядра Linux, и кажется, что, возможно, epoll использует его, но я не уверен, почему я было бы так много. У меня есть несколько «циклов epoll» и потоков таймера, но не так много, как мое число anon_inode.

Answer 1

Это действительно, скорее всего, epoll. Селекторы используют epoll по умолчанию, начиная с одного из ранних выпусков JDK 1.6.x, и этот селектор использует больше файловых дескрипторов, чем старый, в дополнение к дескрипторам, используемым самими сокетами. Вы также будете использовать больше файловых дескрипторов, если зарегистрируете несколько селекторов в одном SocketChannel, например, отдельные селекторы для чтения и записи. Если Netty использует NIO, он почти наверняка использует селекторы. В одном приложении соотношение файловых дескрипторов и сокетов составляло примерно 4: 1 из-за использования селекторов на основе epoll. Можно вернуться к старой реализации селектора, изменив свойство java.nio.channels.spi.SelectorProvider, и это уменьшит количество дескрипторов, но, вероятно, за счет производительности (YMMV).

Answer 2

Возможно, эти inode связаны с отображаемыми в памяти "файлами", которые будут преобразованы в Java Direct ByteBuffers. Системный вызов mmap(2) обычно работает с файлами (используя файловые дескрипторы). Но он также поддерживает опцию MAP_ANONYMOUS для управления отображением памяти без фактического дескриптора файла. Это звучит как что-то, что может нуждаться в «анонимном иноде» внутри.