Historique de la question
Avant Java 5, la coordination des threads reposait sur des méthodes primitives telles que Thread.suspend (dépréciée en raison des risques de blocage inhérents) ou Object.wait/notify, qui nécessitaient une propriété stricte du moniteur et souffraient de réveils manqués si la notification se produisait avant l'attente. Avec l'introduction de java.util.concurrent dans Java 5 (JSR 166), LockSupport a été conçu comme une primitive de déblocage à bas niveau pour permettre la construction de synchronisateurs haute performance tels que AbstractQueuedSynchronizer, sans le fardeau des verrous intrinsèques.
Le problème
En programmation concurrente, une condition de course classique se produit lorsqu'un thread de signalisation invoque le mécanisme de déblocage avant que le thread cible ne se parque réellement. Avec les variables de condition traditionnelles, ce signal serait perdu, entraînant un sommeil indéfini pour le thread cible. Une solution naïve pourrait utiliser un sémaphore de comptage pour accumuler des permis, mais cela introduit une complexité inutile et des fuites de ressources potentielles si le producteur dépasse le consommateur.
La solution
LockSupport utilise un permis à bit unique non cumulatif associé à chaque thread. Ce permis fonctionne comme un pass d'accès jetable et local au thread :
Comme le permis n'est pas cumulatif (il se sature à 1), il prévient les fuites de mémoire dues à des déblocages excessifs tout en garantissant qu'un unpark émis avant le park sera rappelé, éliminant ainsi le problème de réveil manqué grâce à une relation de précédence.
import java.util.concurrent.locks.LockSupport; public class PermitExample { public static void main(String[] args) throws InterruptedException { Thread worker = new Thread(() -> { System.out.println("Worker: Initial work..."); try { Thread.sleep(100); } catch (InterruptedException e) {} System.out.println("Worker: Attempting to park..."); LockSupport.park(); System.out.println("Worker: Unparked successfully!"); }); worker.start(); // Signal before the worker actually parks Thread.sleep(50); System.out.println("Main: Calling unpark before worker parks"); LockSupport.unpark(worker); worker.join(); } }
Description du problème
Lors de la conception d'un moteur d'appariement de commandes pour un système de trading à haute fréquence, nous avions besoin d'un mécanisme de rétention où les threads consommateurs pouvaient suspendre le traitement lorsque la file d'attente entrante atteignait sa capacité, sans détenir des verrous qui empêcheraient les producteurs de vérifier l'état de la file d'attente. Le ReentrantLock standard avec Condition créait de la contention sur le verrou de la file d'attente pendant la signalisation, et Object.wait/notify souffrait du risque de réveils manqués lors de courses à fort débit.
Différentes solutions envisagées
1. Object.wait/notifyAll
Cette approche utilisait le verrou intrinsèque de la file d'attente. Avantages : Simple à mettre en œuvre en utilisant des moniteurs standard. Inconvénients : Nécessitait que le producteur acquière le moniteur pour appeler notify, créant un goulot d'étranglement de sérialisation. Pire encore, si un producteur appelait notify pendant la brève fenêtre entre la vérification de la taille de la file d'attente par le consommateur et l'appel à wait, le signal était perdu, provoquant un blocage permanent du consommateur.
2. ReentrantLock avec plusieurs Conditions
Nous avons tenté d'utiliser des conditions séparées pour les états "plein" et "vide". Avantages : Plus flexible que les verrous intrinsèques, permettant des réveils sélectifs. Inconvénients : Nécessitait toujours l'acquisition du verrou pour la signalisation (signalAll), et la complexité du transfert correct des threads entre les files d'attente de condition introduisait une surcharge de maintenance sans résoudre la surcharge fondamentale des verrous.
3. LockSupport avec état atomique explicite
La solution choisie utilisait un AtomicBoolean pour représenter "permission de procéder" et LockSupport pour le blocage. Lorsque la file d'attente était pleine, le consommateur définissait atomiquement un drapeau "needsParking" et se parquait ensuite. Les producteurs, après avoir retiré un élément, vérifiaient le drapeau et appelaient unpark s'il était défini. Avantages : La signalisation nécessitait aucun verrou, éliminant la contention pendant les réveils. Le modèle à un bit de permis garantissait que même si le producteur appelait unpark des nanosecondes avant que le consommateur n'appelle park (en raison de la planification du CPU), le réveil n'était pas perdu.
Solution choisie et résultat
Nous avons choisi l'approche LockSupport. En découplant le mécanisme de signalisation du verrou structurel de la file d'attente, nous avons réduit la latence du producteur de 40 % sous forte charge et éliminé les scénarios de réveil manqué observés lors des tests de stress. La gestion explicite de l'état (vérification double de la condition après unpark) garantissait l'exactitude malgré le contrat de réveil spontané de park().
Est-ce que LockSupport.park libère la possession des moniteurs détenus par le thread ?
Non. Il s'agit d'une distinction critique par rapport à Object.wait(). Lorsqu'un thread invoque LockSupport.park, il entre dans un état d'attente mais conserve la propriété de tous les moniteurs qu'il détient actuellement. Si un autre thread tente d'entrer dans l'un de ces moniteurs (par exemple, un bloc synchronisé sur le même objet), il sera bloqué, ce qui pourrait entraîner un blocage si le thread en attente est le seul qui pourrait le libérer. Les candidats supposent souvent à tort que park est comme wait et libère des verrous ; c'est une primitive d'ordonnancement purement locale au thread.
Quel est le comportement de LockSupport.park lorsqu'il est invoqué sur un thread dont l'état d'interruption est défini ?
La méthode retourne immédiatement sans bloquer et ne vide pas l'état d'interruption. Cela diffère fondamentalement de Object.wait(), qui vide l'état d'interruption et lance InterruptedException. Avec LockSupport, le thread doit explicitement vérifier et vider l'état d'interruption (via Thread.interrupted()) s'il souhaite respecter les conventions d'interruption. Ce design permet à park d'être utilisé dans des contextes non interruptibles ou là où l'interruption est traitée comme une préoccupation distincte du permis de parking.
Comment LockSupport gère-t-il les réveils spontanés, et comment cela affecte-t-il les modèles de codage ?
LockSupport.park est documenté pour retourner "sans raison" (réveil spontané), bien qu'en pratique, cela soit rare sur les JVM modernes. Contrairement au réveil basé sur le permis (unpark), les réveils spontanés ne consomment pas le permis. Par conséquent, l'appelant doit toujours vérifier à nouveau la condition qui a causé le stationnement dans une boucle :
while (!canProceed()) { LockSupport.park(); }
Les candidats manquent souvent que simplement vérifier la condition une fois après park est insuffisant ; le thread pourrait se réveiller spontanément (ou en raison d'une interruption inattendue) sans un appel unpark, nécessitant une réévaluation de l'état de la condition. Le permis garantit qu'un unpark valide n'est pas perdu, mais il n'empêche pas les retours spontanés.