Буферы сокетов Java-сервера не собираются на Mac

Question

Я выискиваю ошибку памяти в приложении, и она, кажется, связана с буферами byte [], сгенерированными ServerSocketChannel.accept (). Согласно jvisualvm, из 505 мегабайт, используемых приложением, более 90% памяти используется байтовыми [] массивами. Отслеживая это далее, есть 68k + экземпляров байта [], и безусловно самый распространенный размер - 16681.

Я сделал случайную выборку этих байтовых массивов, и все они без исключения были связаны либо с InputRecord, либо с OutputRecord. Если я буду следовать всем ссылкам, я не смогу найти ни одной, которая не приведет к финализатору, что, по моему ограниченному пониманию, означает, что объект готов к сборке мусора, но по какой-то причине он не .

Хотелось бы прикрепить снимок экрана с выводом jvisualvm. В любом случае, референтные объекты включают в себя:

• InputRecord
• AppInputStream
• SSLSocketImpl
• SocketInputStream
• SocksSocketImpl
• SocketOutputStream
• AppOutputStream
• DelegateHttpsURLConnection
• HttpsURLConnectionImpl

Это, похоже, происходит только с клиентами, использующими виртуальную машину Apple. У кого-нибудь есть идеи, почему эти буферы не собирают мусор? Я неправильно читаю профиль кучи? Взломы или обходные пути?

Answer 1

finalize вызывается через некоторое время после того, как объект был обнаружен сборщиком мусора. Реализация Sun перепутана с java.lang.ref. Правильное закрытие ресурсов должно освободить их память. Если объекты с finalize не могут обнулить ссылки на буферы, когда они закрыты, то эти буферы будут зависать до тех пор, пока соответствующий GC не будет выполнен после завершения финализатора.

Обычно существует только один поток финализатора, хотя спецификация допускает много. Если это заблокировано из-за операции блокировки, неправильной удерживаемой блокировки или по другой причине, то сборщик завершенных объектов будет задержан. Я предлагаю проверить поток финализатора в visualvm, чтобы убедиться, что он заблокирован.