历史：在 Java 9 之前，Inflater 和 Deflater 等类中的本地资源管理依赖于 Object.finalize()。由于不可预测性、严重的性能开销以及对象复活带来的风险，导致垃圾收集延迟，该机制被弃用。Java 9 引入了 Cleaner API 作为现代替代方案，利用 PhantomReference 和 ReferenceQueue 将清理逻辑与对象的生命周期解耦，同时确保在清理期间对象保持不可达状态。
问题：在 Inflater 实现中，底层的本地 z_stream 结构必须通过 end() 方法显式解除分配，以防止本地内存泄漏。当应用线程显式调用 end() 时，如果 Cleaner 线程同时尝试运行注册的清理操作，就会出现竞争条件。如果没有适当的同步，两个线程可能会同时尝试释放相同的本地指针，导致双重释放错误，或者一个线程在另一个线程释放后访问了资源（使用后释放），导致 JVM 在本地 zlib 库中崩溃（SIGSEGV）。
解决方案：该解决方案使用 AtomicBoolean 状态标志确保本地清理只执行一次，无论哪个线程启动它。显式的 end() 方法和 Cleaner 的清理操作都会对该标志执行比较并设置（CAS）操作。只有成功将标志从 false 转变为 true 的线程才会继续调用本地解除分配例程。这种无锁方法在保持压缩操作所需的高性能的同时，确保了线程安全。
一个高吞吐量的日志压缩服务每天处理数百万条日志条目，使用池化的 Deflater 实例以最小化分配开销。为了优化资源使用，开发人员实施了返回池的模式，在将 Deflater 实例释放回池之前，显式调用 end()，同时也依赖于垃圾收集来回收由于处理管道中未处理异常而泄漏的实例。
在高峰负载下，系统经历了偶发但关键的 JVM 崩溃（SIGSEGV），核心转储表明在本地 zlib 库中存在内存损坏。调查发现，当 Deflater 实例返回到池时，应用线程调用了 end()，但如果实例同时变得可以进行垃圾收集，则 Cleaner 线程也会尝试清理同一个本地 z_stream 句柄。对本地资源的这种不同步访问导致进程不可预测地崩溃。
考虑的第一个解决方案是使用 synchronized 块或方法来同步对 Deflater 实例的每次访问。这种方法通过确保互斥有效地防止了竞争条件。然而，这在高频率的压缩管道中引入了显著的争用开销，并且如果多个线程同时不正确地访问对象，可能会导致死锁，从而违反类的线程安全契约。
第二种方法是使用 AtomicBoolean 来跟踪清理状态。显式的 end() 方法和 Cleaner 操作在接触本地资源之前都会原子性地检查和设置该标志。这提供了无锁安全，几乎没有性能损失，尽管需要小心实现，以确保在原子检查后但在本地调用之前不会访问本地句柄。
第三种选择是完全移除显式的 end() 调用，仅依赖 Cleaner 进行资源管理。这完全消除了竞争条件，但引入了本地内存释放时机的不确定性，如果 GC 周期落后于本地结构的分配速率，可能会导致垃圾收集暂停期间严重的内存压力。
团队选择了 AtomicBoolean 方法（解决方案2），因为它提供了在可能的情况下确定性的即时清理（显式调用），同时确保清理程序在稍后运行时的安全性。他们修改了包装类以实现 AutoCloseable，确保原子状态检查保护本地解除分配。这完全解决了崩溃问题，同时保持了所需的吞吐量，消除了生产环境中与本地内存相关的崩溃。
Cleaner API 如何防止 Object.finalize() 中固有的对象复活问题？
在 Object.finalize() 中，当 finalize() 方法执行时，对象仍然可达，因为 this 引用保持有效，允许对象通过在静态字段中存储对自身的引用来复活。如果对象反复复活，这会无限期延迟垃圾收集。Cleaner API 通过使用 PhantomReference 防止了这种情况。当 Cleaner 的清理操作运行时，所引用的对象（正在清理的对象）已经处于幻影可达状态，这意味着它无法被复活，因为对它没有强引用、软引用或弱引用。清理操作是一个单独的 Runnable，而不是对象本身的方法，确保在整个清理过程中对象保持不可达状态。
为什么 Thread.interrupt() 在 JVM 关闭期间对停止 Cleaner 线程无效？其影响是什么？
Cleaner 线程是一个守护线程，持续在 ReferenceQueue.remove() 上阻塞，等待虚幻引用变为可用。虽然 ReferenceQueue.remove() 通过抛出 InterruptedException 响应中断，但 Cleaner 实现捕获此异常并继续其无限循环，实际上忽略了中断。这种设计确保在关闭序列期间尽管注册的清理操作会无休止地挂起（例如，等待网络超时或陷入无限循环），Cleaner 线程确保关键资源清理完成。然而，如果注册的清理操作无限期挂起，则 Cleaner 线程将永远无法终止。这可能会阻止 JVM 平稳关闭，因为其他非守护线程在等待 Cleaner 应该释放的资源。
如果 Cleaner 的清理操作捕获了被清理对象的强引用，会发生什么灾难性内存泄漏？
如果传递给 Cleaner.register() 的 Runnable 捕获了对象的强引用（例如，通过 this::cleanupMethod 或引用 this 的 lambda），这将创建一个致命的引用循环。Cleaner 保持一组内部 Cleanable 对象，每个对象持有对清理 Runnable 的引用。如果该 Runnable 引用原始对象，则该对象将保持强可达状态，因此 Cleaner 线程本身不会进入鬼魂可达状态。因此，该对象永远无法被垃圾收集，造成严重的内存泄漏，随着每个注册到 Cleaner 的对象不断增长，最终导致 OutOfMemoryError。