Wanneer ThreadPoolExecutor zijn kernthreads en beperkte wachtrij verzadigt, delegeert CallerRunsPolicy de afgewezen taak aan de indienende thread voor onmiddellijke uitvoering. Als die indienende thread Future.get() heeft aangeroepen om synchronisch te wachten op het resultaat van de taak die ze zojuist heeft ingediend, en de logica van de ingediende taak intern aanvullende taken indient bij dezelfde executor en op hun voltooiing wacht, ontstaat er een circulaire wacht.
De indienende thread kan niet terugkeren van get() totdat zijn taak is voltooid, maar de taak kan niet worden voltooid omdat deze wacht op subtaken die achter haar in de wachtrij staan. Er zijn geen werkthreads beschikbaar om de wachtrij te legen omdat ze allemaal bezig zijn met andere taken. Dit vergrendelt effectief de indiener, omdat het zowel de enige thread is die de ingediende subtaken kan uitvoeren (via het beleid) als tegelijkertijd geblokkeerd is in afwachting van de voltooiing van die subtaken.
We kwamen dit tegen in een gedistribueerde documentverwerkingspipeline waar een ThreadPoolExecutor met CallerRunsPolicy PDF-renderingtaken behandelde. Elke documenttaak parseerde metadata en spawnt subtaken voor afbeeldingextractie, en riep vervolgens onmiddellijk Future.get() aan op die subtaken om het uiteindelijke resultaat samen te stellen.
Bij hoge belasting was de wachtrij verzadigd, wat CallerRunsPolicy activeerde om de documenttaak in de webaanroepthread uit te voeren. Die thread diende vervolgens afbeeldingsextractietaken in en blokkeerde op get(), maar alle werkthreads waren druk met andere documenten. De nieuwe subtaken zaten aan het einde van de wachtrij, niet toegewezen.
De handler thread kon de subtaken niet uitvoeren omdat deze geblokkeerd was in afwachting ervan, en de subtaken konden niet worden uitgevoerd omdat er geen threads vrij waren. Dit creëerde een zichzelf versterkende deadlock die de service verlamde totdat handmatige tussenkomst de JVM opnieuw opstartte.
De onderstaande code illustreert het gevaarlijke patroon:
ExecutorService executor = new ThreadPoolExecutor( 2, 2, 0L, TimeUnit.MILLISECONDS, new ArrayBlockingQueue<>(2), new ThreadPoolExecutor.CallerRunsPolicy() ); // Ingediend vanuit de hoofdverzoekhandlerthread Future<?> parent = executor.submit(() -> { // Wanneer de pool verzadigd is, draait dit in de handlerthread (CallerRunsPolicy) Future<?> child = executor.submit(() -> "geëxtraheerde afbeelding"); // Handlerthread blokkeert hier, wachtend op child // Maar child is in de wachtrij, en geen werkthreads zijn vrij // Handler kan child niet uitvoeren omdat deze geblokkeerd is return child.get(); }); parent.get(); // Deadlock: handlerthread wacht voor eeuwig
We hebben vier verschillende architecturale oplossingen geëvalueerd. De eerste benadering verving CallerRunsPolicy door AbortPolicy en implementeerde een exponentiële backoff-retrylus in de client. Dit behield de beschikbaarheid van de aanroepthread, maar introduceerde tijdelijke fouten en complexe retry-logica die de idempotentiegarranties bemoeilijkte.
De tweede oplossing breidde uit naar een ongebonden LinkedBlockingQueue om volledige verzadiging te voorkomen. Hoewel dit afwijzing uitsloot, riskeerde het OutOfMemoryError bij verkeerspieken en maskeerde het terugdruksignalen, wat leidde tot overmatige latentie in plaats van expliciete fouten.
De derde optie behield de beperkte wachtrij maar verhoogde maximumPoolSize aanzienlijk boven corePoolSize, afhankelijk van threadproliferatie om de belasting te absorberen. Dit verbeterde de doorvoer ten koste van overmatige context-switching en geheugengebruik, wat uiteindelijk de prestaties degradeerde door CPU-cachethrashing.
De vierde aanpak herstructureerde de workflow met behulp van ExecutorCompletionService en asynchrone callback-functies in plaats van synchronische Future.get(). Dit stelde de oorspronkelijke documenttaak in staat om de werkthread vrij te geven bij het indienen van subtaken en alleen weer te starten wanneer CompletionService de voltooiing signaleerde.
We hebben de vierde oplossing gekozen omdat deze de indiening fundamenteel ontkoppelde van de voltooiing. Dit behield de terugdruk van de beperkte wachtrij terwijl de circulaire wachtconditie werd geëlimineerd, waardoor werkthreads konden recyclen om de subtaken te verwerken terwijl de oorspronkelijke taak wachtte op een melding op een lichte voorwaarde.
Deze wijziging loste de deadlocks op, verminderde de gemiddelde latentie met veertig procent en behield stabiele geheugensporen onder piekbelastingen zonder de faalsemantiek van de beperkte wachtrij te verminderen.
Waarom weigert ThreadPoolExecutor nieuwe threads te instantiëren boven corePoolSize wanneer het is geconfigureerd met een ongebonden BlockingQueue?
De executor probeert alleen nieuwe threads te creëren wanneer execute() de taak niet onmiddellijk aan een wachtende werkthread kan overhandigen of deze in de wachtrij kan plaatsen. De offer()-methode van een ongebonden wachtrij retourneert nooit false, zodat de executor de verzadiging nooit waarneemt en bijgevolg nooit threads toewijst boven het kerntal. Dit ontwerp neemt aan dat queuing de voorkeur heeft boven threadcreatie voor resourcebeheer, maar creëert een blinde vlek waar de pool onderbenut lijkt ondanks uitstaande werk. Kandidaten gaan vaak onterecht ervan uit dat maximumPoolSize als een harde grens fungeert, ongeacht de capaciteit van de wachtrij, en erkennen niet dat de gebondenheid van de wachtrij fungeert als de poortwachter voor threaduitbreiding.
Hoe functioneert CallerRunsPolicy als een implicitiemechanisme voor stroombeheer in plaats van alleen een afwijzingshandler?
Door de taak in de indienende thread uit te voeren, dwingt het beleid die thread om zijn indieningssnelheid te pauzeren en werk uit te voeren, waardoor de inkomende stroom natuurlijk wordt vertraagd om overeen te komen met de verwerkingscapaciteit van de pool. Deze backpressure verspreidt zich omhoog in de aanroepstack naar de oorspronkelijke producent, waardoor deze vertraagd wordt zonder expliciete snelheidsbeperkende code. Veel kandidaten zien het beleid alleen als een fail-safe voor gedropte taken, en missen dat het opzettelijk de producent blokkeert om resource-uitputting te voorkomen. Het begrijpen van dit semantische onderscheid is cruciaal voor het ontwerpen van systemen waarbij latentie de voorkeur heeft boven volledige afwijzing onder belastingpieken.
Welke subtiele interactie tussen shutdown() en CallerRunsPolicy verhindert een gracevolle degradatie tijdens de beëindiging van de executor?
Zodra shutdown() is aangeroepen, gaat de executor over naar een toestand waarin nieuwe indieningen worden afgewezen via RejectedExecutionException, waarbij het geconfigureerde afwijzingsbeleid volledig wordt omzeild. Kandidaten gaan vaak ervan uit dat CallerRunsPolicy taken in de indiener zou blijven uitvoeren tijdens de beëindiging, maar de executor controleert de shutdownstatus voordat hij het beleid raadpleegt. Dit betekent dat taken die tijdens de fase van gracevolle beëindiging worden ingediend, onmiddellijk mislukken in plaats van door de indiener te worden uitgevoerd, waardoor mogelijk huidige taken verloren gaan als de client de uitzondering niet afhandelt. Een goede stopvolgorde vereist het legen van de wachtrij via awaitTermination() of het vastleggen van afgewezen taken in een failoverstructuur, omdat het beleidsmechanisme wordt gedeactiveerd zodra de stopvlag is ingesteld.