Voor Java 5 had het Java Geheugenmodel (JMM) zwakke garanties voor geheugenzichtbaarheid die veel populaire gelijktijdigheidsidiomen onveilig maakten. Het Double-Checked Locking patroon ontstond eind jaren '90 als een vermeende prestatie-optimalisatie voor lui initialisatie, maar het bevatte een fatale fout met betrekking tot instructieherordening. JSR-133 herdefinieerde de semantiek van het volatile trefwoord in 2004 om een acquire-release geheugenordening te bieden, specifiek om dergelijke zichtbaarheidproblemen op te lossen zonder de overhead van volledige synchronisatie.
Zonder volatile is de JVM en de onderliggende CPU-architecturen toegestaan om instructies te herordenen, zodat de toewijzing van een referentie aan een variabele plaatsvindt voordat de uitvoer van de constructor is voltooid. Dit creëert een venster waarin een andere thread een niet-nul referentie naar een object kan waarnemen waarvan de velden standaard of niet-geïnitieerde waarden bevatten, wat leidt tot onvoorspelbaar gedrag of een NullPointerException. Het gelijktijdigheidsgevaar is bijzonder sluipend omdat het zich alleen manifesteert onder specifieke timing-voorwaarden en hardwaregeheugenmodellen, wat het moeilijk maakt om tijdens tests te reproduceren.
Het declareren van het instantieveld als volatile voegt een geheugenscherm toe dat een happens-before-relatie tot stand brengt tussen het schrijven in de constructor en alle volgende reads door andere threads. Dit voorkomt dat de compiler en processor het schrijven naar het volatile veld herordenen met de voorafgaande schrijfs in de constructor, waardoor wordt gewaarborgd dat het object volledig is geconstrueerd voordat de referentie zichtbaar wordt. Het patroon stelt threads in staat om de referentie te controleren zonder te vergrendelen na initialisatie, wat zowel threadveiligheid als hoge prestaties biedt.
public class ConnectionPool { private static volatile ConnectionPool instance; private ConnectionPool() { // Zware initialisatie } public static ConnectionPool getInstance() { if (instance == null) { synchronized (ConnectionPool.class) { if (instance == null) { instance = new ConnectionPool(); } } } return instance; } }
Een microservice met hoge doorvoer voor betalingsverwerking vereiste een singleton ConnectionPool om JDBC-verbindingen naar een PostgreSQL-cluster te beheren. Tijdens druk verkeer riepen duizenden threads tegelijkertijd getInstance() aan toen de service voor het eerst startte, wat een thread-veilige initialisatiestrategie vereiste die de vergrendelingsconcurrentie minimaliseerde. De initialisatie volgorde hield het opzetten van TCP-sockets, het toewijzen van directe bytebuffers en het uitvoeren van schema-validatiequery's in, waardoor vroege instantiatie onbetaalbaar duur werd voor autoscaling-scenario's.
Vroege Initialisatie hield in dat de pool in een statische initialisatieblok werd aangemaakt. Deze aanpak garandeerde threadveiligheid door middel van classloadingmechanismen en elimineerde volledig de behoefte aan synchronized blokken. De verbinding tot stand brengen vereiste echter drie seconden voor TCP-handshakes en credentialuitwisseling, wat de servicelevelovereenkomst voor koude starttijden tijdens autoscaling evenementen schond.
Gesynchroniseerde Methode omhulde de getInstance()-methode met het synchronized trefwoord. Hoewel dit de raceconditie corrigeerde door alle toegang te serialiseren, introduceerde het een ernstige prestatievermindering onder belasting. Profilering toonde aan dat threads na de initialisatie onnodige cycli opgaven om de monitorvergrendeling te verwerven, ondanks de onveranderlijke aard van de volledig geconstrueerde pool, wat ongeveer 18 milliseconden latentie per oproep toevoegde.
Double-Checked Locking met volatile werd gekozen als de optimale aanpak. Deze oplossing gebruikte een ongevergrendeld snel pad om te controleren op null, gevolgd door een synchronized blok voor de kritieke sectie, met een tweede null-check binnenin om meerdere instanties te voorkomen. De volatile modifier zorgde ervoor dat de volledig geïnitialiseerde poolstatus onmiddellijk zichtbaar was voor alle CPU-kernen bij publicatie, en balans hield tussen lui initialisatie en nul vergrendelingskosten na de opstart.
De gekozen oplossing resulteerde in succesvolle luie initialisatie zonder blokkeren, waardoor de service 50.000 aanvragen per seconde kon verwerken met sub-millisecond responstijden na de initiële poolcreatie. De implementatie elimineerde racecondities tijdens de opstart en hield vergrendelingsvrije toegang tijdens reguliere operaties, waardoor de waargenomen NullPointerException-gevallen die eerder voorkwamen onder hoge concurrentiescenario's werden voorkomen. Monitoring bevestigde dat de JVM de geheugenzichtbaarheid correct afhandelde over alle 64 kernen zonder expliciete synchronisatie nadat de singleton was vastgesteld.
Waarom vereist het double-checked locking-patroon twee verschillende null-checks in plaats van een enkele gesynchroniseerde controle?
De eerste controle vindt buiten het synchronized blok plaats om een snel, vergrendelingsvrij pad te bieden voor de gewone situatie waarin de instantie al bestaat. De tweede controle binnen het synchronized blok is essentieel omdat meerdere threads tegelijkertijd de eerste null-check kunnen doorstaan wanneer de instantie nog niet is geïnitialiseerd. Zonder deze tweede verificatie zou elke thread de vergrendeling sequentieel verwerven en afzonderlijke instanties creëren, wat de singleton-eigenschap zou schenden. De binnenste controle zorgt ervoor dat alleen de eerste thread die de kritieke sectie binnenkomt, constructie uitvoert, terwijl daaropvolgende threads de instantie al geïnitialiseerd ontdekken en het maken overslaan.
Hoe onderscheidt het Java Geheugenmodel de zichtbaarheidsgaranties van een volatile schrijfopdracht en een exit uit een gesynchroniseerd blok?
Beide constructies stellen happens-before-relaties vast, maar ze werken op verschillende granulariteiten en prestatiekenmerken. Een exit uit een synchronized blok haalt alle gewijzigde variabelen in het werkgeheugen van de thread naar het hoofdgeheugen, wat fungeert als een globale geheugenscherm. Daarentegen voorkomt een volatile schrijfopdracht specifiek de herordening van die specifieke variabele met omringende instructies en zorgt ervoor dat de schrijfopdracht onmiddellijk zichtbaar is. Voor Java 5 ontbraken deze garanties aan volatile, wat het onvoldoende maakte voor veilige publicatie; het moderne JMM behandelt volatile schrijfacties op een vergelijkbare manier als C++ release-operaties en leest als acquire-operaties, wat gerichte zichtbaarheid biedt zonder de volledige kosten van monitorvergrendeling.
Kunnen onveranderlijke objecten de noodzaak voor volatile in het double-checked locking patroon elimineren?
Nee, omdat final velden alleen onveranderlijkheid garanderen nadat de constructor is voltooid, niet tijdens de publicatie van de referentie zelf. Zonder volatile kan instructieherordening ervoor zorgen dat de referentie naar het hoofdgeheugen wordt geschreven voordat de constructor is voltooid, waardoor een andere thread een niet-nul referentie naar een gedeeltelijk geconstrueerd object kan waarnemen. Terwijl final velden ervoor zorgen dat waarden na de constructie niet kunnen veranderen, voorkomen ze niet de zichtbaarheid van de standaard of niet-geïnitieerde waarden als de referentie vroeg ontsnapt. Veilige publicatie vereist ofwel volatile of synchronized om de happens-before-relatie tussen constructie en zichtbaarheid te waarborgen, ongeacht de interne onveranderlijkheid van het object.