Historia: Antes de Java 9, la gestión de recursos nativos en clases como Inflater y Deflater dependía de Object.finalize(). Este mecanismo fue desaprobado debido a su imprevisibilidad, su severo impacto en el rendimiento y el riesgo de resurrección del objeto que retrasaba la recolección de basura. Java 9 introdujo la API Cleaner como una alternativa moderna, utilizando PhantomReference y ReferenceQueue para desacoplar la lógica de limpieza del ciclo de vida del objeto, asegurando que el objeto permanezca inalcanzable durante la limpieza.
Problema: En la implementación de Inflater, la estructura nativa subyacente z_stream debe ser desliberada explícitamente a través del método end() para prevenir fugas de memoria nativa. Cuando un hilo de aplicación llama a end() explícitamente mientras el hilo del Cleaner intenta simultáneamente ejecutar la acción de limpieza registrada, surge una condición de carrera. Sin la sincronización adecuada, ambos hilos podrían intentar liberar el mismo puntero nativo, lo que lleva a un error de doble liberación, o un hilo podría acceder al recurso después de que el otro lo haya liberado (uso después de liberar), resultando en bloqueos del JVM (SIGSEGV) en la biblioteca nativa zlib.
Solución: La solución emplea un estado de bandera AtomicBoolean para asegurar que la limpieza nativa se ejecute exactamente una vez, independientemente de qué hilo la inicie. Tanto el método explícito end() como la acción de limpieza del Cleaner realizan una operación de comparación y establecimiento (CAS) en esta bandera. Solo el hilo que logra cambiar la bandera de false a true procede a invocar la rutina de desliberación nativa. Este enfoque sin bloqueo garantiza la seguridad de los hilos mientras mantiene el alto rendimiento requerido para las operaciones de compresión.
Un servicio de compresión de registros de alto rendimiento procesa millones de entradas de registro diariamente utilizando instancias de Deflater agrupadas para minimizar la sobrecarga de asignación. Para optimizar el uso de recursos, los desarrolladores implementaron un patrón de retorno al grupo que llama explícitamente a end() en las instancias de Deflater antes de liberarlas de nuevo al grupo, al tiempo que también confiaban en la recolección de basura para recuperar instancias que se filtraron debido a excepciones no manejadas en la tubería de procesamiento.
El sistema experimentó bloqueos esporádicos pero críticos de JVM (SIGSEGV) bajo carga máxima, con volcado de núcleo que indicaba corrupción de memoria dentro de la biblioteca nativa zlib. La investigación reveló que cuando una instancia de Deflater se devolvía al grupo, el hilo de la aplicación llamaba a end(), pero si la instancia se volvía elegible para recolección de basura simultáneamente, el hilo del Cleaner también intentaría limpiar el mismo controlador nativo z_stream. Este acceso no sincronizado al recurso nativo causó que el proceso fallara de manera impredecible.
La primera solución considerada fue sincronizar cada acceso a la instancia de Deflater utilizando bloques o métodos synchronized. Este enfoque evitaría efectivamente la condición de carrera al asegurar la exclusión mutua. Sin embargo, introdujo una sobrecarga de contención significativa en la tubería de compresión de alta frecuencia y corrió el riesgo de bloqueos si el objeto era accedido incorrectamente desde múltiples hilos concurrentemente, violando el contrato de seguridad de hilos de la clase.
El segundo enfoque involucró el uso de un AtomicBoolean para rastrear el estado de limpieza. Tanto el método explícito end() como la acción del Cleaner comprobarían y establecerían esta bandera de manera atómica antes de tocar el recurso nativo. Esto ofrecía seguridad sin bloqueo con una penalización mínima de rendimiento, aunque requería una implementación cuidadosa para asegurar que el controlador nativo no se accediera después de la verificación atómica pero antes de la llamada nativa.
La tercera opción fue eliminar completamente las llamadas explícitas a end() y confiar únicamente en el Cleaner para la gestión de recursos. Esto eliminó completamente la condición de carrera, pero introdujo imprevisibilidad en el momento de liberación de la memoria nativa, lo que podría causar una presión severa de memoria durante las pausas de recolección de basura si los ciclos de GC se retrasaban en relación con la tasa de asignación de estructuras nativas.
El equipo seleccionó el enfoque de AtomicBoolean (Solución 2) porque proporcionó una limpieza inmediata determinística cuando era posible (llamada explícita) mientras aseguraba seguridad si el limpiador se ejecutaba más tarde. Modificaron la clase envolvente para implementar AutoCloseable, asegurando que la verificación del estado atómico protegiera la desliberación nativa. Esto resolvió completamente los bloqueos mientras mantenía el rendimiento requerido, eliminando bloqueos relacionados con la memoria nativa en producción.
**¿Cómo evita la API Cleaner el problema de resurrección de objetos inherente a Object.finalize()?
En Object.finalize(), el objeto sigue siendo alcanzable cuando se ejecuta el método finalize() porque la referencia this sigue siendo válida, lo que permite que el objeto se resucite almacenando una referencia a sí mismo en un campo estático. Esta resurrección retrasa la recolección de basura indefinidamente si el objeto se resucita repetidamente. La API Cleaner previene esto al usar PhantomReference. Cuando se ejecuta la acción de limpieza del Cleaner, el referente (el objeto que se está limpiando) ya está en el estado phantom alcanzable, lo que significa que no puede ser resucitado porque no existen referencias fuertes, suaves o débiles hacia él. La acción de limpieza es un Runnable separado, no un método del propio objeto, asegurando que el objeto permanezca inalcanzable durante todo el proceso de limpieza.
¿Por qué es ineficaz Thread.interrupt() para detener un hilo del Cleaner durante el apagado de la JVM, y cuáles son las implicaciones?
El hilo del Cleaner es un hilo de demonio que se bloquea de forma continua en ReferenceQueue.remove(), esperando a que las referencias fantasmas estén disponibles. Mientras que ReferenceQueue.remove() responde a interrupciones lanzando InterruptedException, la implementación del Cleaner captura esta excepción y continúa su bucle infinito, ignorando efectivamente las interrupciones. Este diseño asegura que la limpieza de recursos críticos se complete incluso durante las secuencias de apagado. Sin embargo, si una acción de limpieza registrada se queda atascada indefinidamente (por ejemplo, esperando un tiempo de espera de red o atrapada en un bucle infinito), el hilo del Cleaner nunca terminará. Esto puede impedir que la JVM se apague de manera ordenada si otros hilos no daemon están esperando recursos que el limpiador debe liberar.
¿Qué fuga de memoria catastrófica ocurre si la acción de limpieza de un Cleaner captura una referencia fuerte al objeto que se está limpiando?
Si el Runnable pasado a Cleaner.register() captura una referencia fuerte al objeto (por ejemplo, a través de this::cleanupMethod o una lambda que hace referencia a this), se crea un ciclo de referencia fatal. El Cleaner mantiene un conjunto interno de objetos Cleanable, cada uno sosteniendo una referencia al Runnable de limpieza. Si ese Runnable hace referencia al objeto original, el objeto permanece fuertemente alcanzable desde el hilo del Cleaner. En consecuencia, el objeto nunca se vuelve alcanzable como phantom, la PhantomReference nunca entra en la cola y la acción de limpieza nunca se ejecuta. Mientras tanto, el objeto no puede ser recolectado por la basura, resultando en una fuga de memoria severa que crece indefinidamente con cada objeto registrado al Cleaner, causando eventualmente OutOfMemoryError.