Geschiedenis: Voor Java 9 was het beheer van native bronnen in klassen zoals Inflater en Deflater afhankelijk van Object.finalize(). Dit mechanisme werd afgekeurd vanwege de onvoorspelbaarheid, ernstige prestatie-overhead en het risico dat objectresurrectie de garbage collection vertraagde. Java 9 introduceerde de Cleaner API als een moderne alternatieve aanpak, die gebruik maakt van PhantomReference en ReferenceQueue om de schoonmaaklogica te scheiden van de levenscyclus van het object, terwijl wordt gewaarborgd dat het object onbereikbaar blijft tijdens de schoonmaak.
Probleem: In de implementatie van de Inflater moet de onderliggende native z_stream-structuur expliciet worden vrijgegeven via de end()-methode om native geheugenlekken te voorkomen. Wanneer een applicatiedraad end() expliciet aanroept terwijl de Cleaner-draad gelijktijdig probeert de geregistreerde schoonmaakactie uit te voeren, doet zich een raceconditie voor. Zonder juiste synchronisatie kunnen beide draden proberen dezelfde native pointer vrij te geven, wat kan leiden tot een double-free fout, of één draad kan toegang krijgen tot de bron nadat de andere deze heeft vrijgegeven (gebruik-na-vrijgave), wat resulteert in JVM-crashes (SIGSEGV) in de native zlib-bibliotheek.
Oplossing: De oplossing maakt gebruik van een AtomicBoolean state vlag om te waarborgen dat de native schoonmaak precies één keer wordt uitgevoerd, ongeacht welke draad deze initieert. Zowel de expliciete end()-methode als de schoonmaakactie van de Cleaner voeren een vergelijk-en-stel (CAS) operatie op deze vlag uit. Alleen de draad die erin slaagt de vlag van false naar true over te schakelen, gaat verder met het aanroepen van de routine voor native deallocatie. Deze lock-vrije aanpak garandeert threadveiligheid terwijl de hoge prestaties worden gehandhaafd die nodig zijn voor compressiebewerkingen.
Een logcompressiedienst met hoge doorvoer verwerkt dagelijks miljoenen logvermeldingen met behulp van gepoolde Deflater-instanties om allocatie-overhead te minimaliseren. Om het gebruik van bronnen te optimaliseren, implementeerden ontwikkelaars een return-to-pool patroon dat expliciet end() aanroept op Deflater-instanties voordat ze weer aan de pool worden vrijgegeven, terwijl ook wordt vertrouwd op garbage collection om instanties terug te vorderen die verloren zijn gegaan door onopgeloste uitzonderingen in de verwerkingspijplijn.
Het systeem ervoer sporadische maar kritieke JVM-crashes (SIGSEGV) onder piekbelastingen, met core dumps die geheugenbeschadiging in de native zlib-bibliotheek aangaven. Onderzoek toonde aan dat wanneer een Deflater-instantie aan de pool werd teruggegeven, de applicatiedraad end() aanriep, maar als de instantie gelijktijdig in aanmerking kwam voor garbage collection, de Cleaner-draad ook zou proberen dezelfde native z_stream-handle op te schonen. Deze onsynchroniseerde toegang tot de native bron veroorzaakte dat het proces onvoorspelbaar crashte.
De eerste oplossing die werd overwogen, was het synchroniseren van elke toegang tot de Deflater-instantie met behulp van synchronized-blokken of -methoden. Deze aanpak zou de raceconditie effectief voorkomen door wederzijdse uitsluiting te waarborgen. Echter, het bracht aanzienlijke concurrentie-overhead met zich mee in de compressiepijplijn met hoge frequentie en riskeerde deadlocks als het object verkeerd werd benaderd door meerdere draden tegelijkertijd, wat in strijd was met het threadveiligheidscontract van de klasse.
De tweede aanpak omvatte het gebruik van een AtomicBoolean om de schoonmaakstatus bij te houden. Zowel de expliciete end()-methode als de Cleaner-actie zouden atomair deze vlag controleren en instellen voordat ze de native bron aanraakten. Dit bood lock-vrije veiligheid met minimale prestatiekosten, hoewel het zorgvuldige implementatie vereiste om ervoor te zorgen dat de native handle niet werd benaderd na de atomische controle maar vóór de native aanroep.
De derde optie was om expliciete end()-aanroepen volledig te verwijderen en uitsluitend op de Cleaner te vertrouwen voor bronnenbeheer. Dit elimineerde de raceconditie volledig, maar introduceerde onvoorspelbaarheid in de timing van de vrijgave van native geheugen, wat mogelijk ernstige geheugendruk veroorzaakte tijdens pauzes van garbage collection als de GC-cycli achterbleven bij de allocatiesnelheid van native structuren.
Het team koos voor de AtomicBoolean-aanpak (Oplossing 2) omdat het deterministische onmiddellijke schoonmaak bood wanneer mogelijk (expliciete oproep) terwijl het veiligheid waarborgde als de cleaner later werd uitgevoerd. Ze pasten de wrapperklasse aan om AutoCloseable te implementeren, waarbij ervoor werd gezorgd dat de atomische statuscontrole de native deallocatie beschermde. Dit loste de crashes volledig op en handhaafde de vereiste doorvoer, wat native geheugen gerelateerde crashes in productie eliminate.
**Hoe voorkomt de Cleaner API het objectresurrectieprobleem dat inherent is aan Object.finalize()?
In Object.finalize() is het object nog steeds toegankelijk wanneer de finalize()-methode wordt uitgevoerd omdat de this-referentie geldig blijft, waardoor het object zichzelf kan resurrecten door een referentie naar zichzelf op te slaan in een statisch veld. Deze resurrectie vertraagt de garbage collection oneindig als het object herhaaldelijk resurrect. De Cleaner API voorkomt dit door gebruik te maken van PhantomReference. Wanneer de schoonmaakactie van de Cleaner wordt uitgevoerd, is het referent (het object dat wordt opgeruimd) al in de staat van phantoms, wat betekent dat het niet kan worden geresurrect omdat er geen sterke, zachte of zwakke referenties naar het is. De schoonmaakactie is een aparte Runnable, geen methode op het object zelf, waardoor het object onbereikbaar blijft gedurende het hele schoonmaakproces.
Waarom is Thread.interrupt() ineffectief voor het stoppen van een Cleaner-draad tijdens JVM-uitschakeling, en wat zijn de implicaties?
De Cleaner-draad is een daemon-draad die continu blokkeert op ReferenceQueue.remove(), wachtend op phantom-referenties die beschikbaar komen. Terwijl ReferenceQueue.remove() reageert op onderbrekingen door InterruptedException te gooien, vangt de implementatie van de Cleaner deze uitzondering en gaat verder met zijn oneindige lus, waardoor het onderbrekingen effectief negeert. Dit ontwerp zorgt ervoor dat kritieke schoonmaak van bronnen wordt voltooid, zelfs tijdens uitschakelingssequenties. Echter, als een geregistreerde schoonmaakactie oneindig blijft hangen (bijvoorbeeld wachtend op een netwerktime-out of vastzit in een oneindige lus), zal de Cleaner-draad nooit beëindigen. Dit kan voorkomen dat de JVM op een geoefende manier wordt uitgeschakeld als andere niet-daemon draden wachten op bronnen die de cleaner zou moeten vrijgeven.
Welke catastrofale geheugenlek ontstaat er als een schoonmaakactie van een Cleaner een sterke referentie naar het object dat wordt opgeruimd, vastlegt?
Als de Runnable die aan Cleaner.register() wordt doorgegeven een sterke referentie naar het object vastlegt (bijvoorbeeld via this::cleanupMethod of een lambda die this verwijst), creëert dit een fatale referentiecylcus. De Cleaner onderhoudt een interne set van Cleanable-objecten, elk met een referentie naar de schoonmaak Runnable. Als die Runnable het oorspronkelijke object verwijst, blijft het object sterk toegankelijk vanuit de Cleaner-draad zelf. Bijgevolg wordt het object nooit phantoms bereikbaar, de PhantomReference komt nooit in de wachtrij, en de schoonmaakactie wordt nooit uitgevoerd. Ondertussen kan het object niet worden garbage-gecollecteerd, wat resulteert in een ernstig geheugenlek dat onbeperkt groeit met elk object dat is geregistreerd bij de Cleaner, wat uiteindelijk leidt tot OutOfMemoryError.