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

Question

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

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

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

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

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

Answer 1

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

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