История: До Java 9 управление нативными ресурсами в таких классах, как Inflater и Deflater, основывалось на Object.finalize(). Этот механизм был устаревшим из-за непредсказуемости, серьезных накладных расходов на производительность и риска воскрешения объекта, задерживающего сборку мусора. Java 9 представила API Cleaner как современную альтернативу, использующую PhantomReference и ReferenceQueue, чтобы отделить логику очистки от жизненного цикла объекта, обеспечивая при этом, чтобы объект оставался недоступным во время очистки.
Проблема: В реализации Inflater нижняя структура нативного z_stream должна быть явно освобождена через метод end(), чтобы предотвратить утечки нативной памяти. Когда поток приложения явно вызывает end(), в то время как поток Cleaner одновременно пытается выполнить зарегистрированное действие очистки, возникает состояние гонки. Без надлежащей синхронизации оба потока могут попытаться освободить один и тот же нативный указатель, что приведет к ошибке двойного освобождения, или один поток может получить доступ к ресурсу после того, как другой его освободил (использование после освобождения), что приводит к сбоям JVM (SIGSEGV) в библиотеке нативного zlib.
Решение: Решение использует флаг состояния AtomicBoolean, чтобы гарантировать, что нативная очистка выполняется ровно один раз независимо от того, какой поток инициирует ее. Как явный метод end(), так и действие очистки Cleaner выполняют операцию сравнения и установки (CAS) на этом флаге. Только поток, который успешно переводит флаг из false в true, продолжает вызывать рутинное освобождение памяти. Этот безблокировочный подход гарантирует безопасность потоков, сохраняя высокую производительность, необходимую для операций сжатия.
Служба сжатия логов с высокой пропускной способностью обрабатывает миллионы записей логов ежедневно, используя экземпляры Deflater из пула, чтобы минимизировать накладные расходы на выделение. Чтобы оптимизировать использование ресурсов, разработчики реализовали шаблон возврата в пул, который явно вызывает end() на экземплярах Deflater перед тем, как вернуть их обратно в пул, также полагаясь на сборку мусора для восстановления экземпляров, которые утекли из-за необработанных исключений в конвейере обработки.
Система время от времени сталкивалась с критическими сбоями JVM (SIGSEGV) под пиковыми нагрузками, и дампы памяти указывали на повреждение памяти в нативной библиотеке zlib. Расследование показало, что когда экземпляр Deflater возвращался в пул, поток приложения вызывал end(), но если экземпляр одновременно становился пригодным для сборки мусора, поток Cleaner также будет пытаться очистить тот же нативный дескриптор z_stream. Этот несинхронизованный доступ к нативному ресурсу вызвал непредсказуемые сбои процесса.
Первое решение, рассмотренное командой, заключалось в синхронизации каждого доступа к экземпляру Deflater с использованием блоков или методов synchronized. Этот подход эффективно предотвратил бы состояние гонки, обеспечивая взаимное исключение. Однако он вносил значительные накладные расходы на конкуренцию в высокочастотном конвейере сжатия и создавал риск взаимных блокировок, если объект неправильно использовался из нескольких потоков одновременно, нарушая контракт безопасности потоков класса.
Второй подход заключался в использовании AtomicBoolean для отслеживания состояния очистки. Как явный метод end(), так и действие Cleaner атомарно проверяли и устанавливали этот флаг перед обращением к нативному ресурсу. Это обеспечивало безопасность без блокировок с минимальным влиянием на производительность, хотя это требовало тщательной реализации, чтобы гарантировать, что к нативному дескриптору не обращались после атомарной проверки, но до нативного вызова.
Третий вариант заключался в том, чтобы полностью отказаться от явных вызовов end() и полагаться исключительно на Cleaner для управления ресурсами. Это полностью устраняло состояние гонки, но вводило непредсказуемость в момент освобождения нативной памяти, потенциально вызывая сильное давление на память во время пауз сборки мусора, если циклы сборки мусора отставали от скорости выделения нативных структур.
Команда выбрала подход AtomicBoolean (Решение 2), поскольку он обеспечивал детерминированную немедленную очистку, когда это возможно (явный вызов), в то время как гарантировал безопасность, если очистка происходила позже. Они модифицировали обертку класса, чтобы реализовать AutoCloseable, обеспечивая защиту состояния атомарной проверки во время нативного освобождения. Это полностью устранило сбои, сохранив необходимую пропускную способность и устранив сбои, связанные с нативной памятью, в производстве.
Как API Cleaner предотвращает проблему воскрешения объекта, присущую Object.finalize()?
В Object.finalize() объект все еще доступен, когда выполняется метод finalize(), поскольку ссылка this остается действительной, что позволяет объекту воскреснуть, сохранив ссылку на себя в статическом поле. Это воскрешение задерживает сборку мусора на неопределенный срок, если объект многократно воскресает. API Cleaner предотвращает это, используя PhantomReference. Когда действие очистки Cleaner выполняется, ссылочное (очищаемое) действие уже находится в состоянии фантомного доступа, что означает, что его нельзя воскресить, поскольку не существует сильных, мягких или слабых ссылок на него. Действие очистки — это отдельный Runnable, а не метод самого объекта, гарантируя, что объект остается недоступным на протяжении всего процесса очистки.
Почему Thread.interrupt() неэффективен для остановки потока Cleaner во время завершения JVM, и какие последствия это имеет?
Поток Cleaner — это поток-демон, который постоянно блокируется на ReferenceQueue.remove(), ожидая, когда фантомные ссылки станут доступными. Хотя ReferenceQueue.remove() реагирует на прерывания, выбрасывая InterruptedException, реализация Cleaner перехватывает это исключение и продолжает свой бесконечный цикл, фактически игнорируя прерывания. Этот дизайн обеспечивает завершение критической очистки ресурсов даже во время последовательностей завершения. Однако, если зарегистрированное действие очистки застревает бесконечно (например, ожидая сетевое время ожидания или заклинив в бесконечном цикле), поток Cleaner никогда не завершится. Это может предотвратить корректное завершение JVM, если другие недемоны ожидают ресурсов, которые должен освободить очиститель.
Какой катастрофический утечка памяти возникает, если действие очистки Cleaner захватывает сильную ссылку на очищаемый объект?
Если Runnable, переданный в Cleaner.register(), захватывает сильную ссылку на объект (например, через this::cleanupMethod или лямбду, ссылающуюся на this), это создает фатальный цикл ссылок. Cleaner поддерживает внутренний набор объектов Cleanable, каждый из которых содержит ссылку на очистку Runnable. Если этот Runnable ссылается на оригинальный объект, объект остается сильно доступным с потока Cleaner. В результате объект никогда не станет фантомно доступным, PhantomReference никогда не попадет в очередь, и действие очистки никогда не выполнится. В то же время объект не может быть собран сборщиком мусора, что приводит к серьезной утечке памяти, которая не ограничена с каждым объектом, зарегистрированным в Cleaner, в конечном итоге вызывая OutOfMemoryError.