Lorsque Thread.interrupt() cible un thread bloqué dans Selector.select(), le sélecteur renvoie immédiatement un ensemble de clés sélectionnées vides tout en définissant le drapeau d'interruption du thread. Cela crée une ambiguïté architecturale car le code appelant ne peut pas déterminer, uniquement à partir de la valeur de retour, si les canaux sont prêts pour l'I/O ou si le retour reflète simplement le signal d'interruption. Contrairement à Selector.wakeup(), qui débloque le sélecteur sans effets secondaires sur le statut d'interruption, une interruption confond le signal d'arrêt avec les événements I/O. Par conséquent, des implémentations robustes doivent explicitement vérifier Thread.interrupted() ou consulter une variable d'état volatile partagée pour disambiguïser entre la véritable préparation et le réveil fantôme, évitant ainsi les boucles de rotation intensives en CPU.
Considérez une passerelle Java NIO à haut débit traitant des flux de données de marché, où un thread dédié est bloqué sur Selector.select() pour dispatcher des événements SelectionKey aux threads de travail. Lors d'un déploiement sans temps d'arrêt, la couche d'orchestration doit signaler à ce thread sélecteur d'arrêter les opérations en douceur après avoir terminé les transactions en cours.
L'implémentation initiale utilisait Thread.interrupt() pour signaler la terminaison. Bien que cela ait réussi à débloquer select(), cela a entraîné un livelock critique : select() a renvoyé zéro clés, ce qui a fait que la boucle d'événements itérait continuellement à pleine utilisation du CPU. Le thread, supposant qu'une activité I/O existait, a tenté des lectures non bloquantes sur tous les canaux enregistrés, ne trouvant aucun prêt, et a immédiatement ré-invoqué select(), qui a renvoyé instantanément en raison du drapeau d'interruption persistante.
Une alternative proposée a remplacé le blocage indéfini par select(100) associé à un drapeau boolean volatile d'arrêt. Cette stratégie a empêché la saturation du CPU en limitant la durée de blocage et a offert un mécanisme de sondage simple pour les signaux de terminaison sans s'appuyer sur Thread.interrupt(). Cependant, elle a introduit une latence déterministe dans la détection d'arrêt allant jusqu'à la durée d'expiration et a augmenté la surcharge de changement de contexte de 20 % sous charge maximale, dégradant le débit pour les opérations à haute fréquence.
Une autre solution candidate a utilisé Selector.wakeup() déclenché exclusivement par un hook d'arrêt, évitant totalement la sémantique d'interruption. Cela a permis un débouchage immédiat sans l'ambiguïté des ensembles de clés vides, tout en préservant le drapeau d'interruption pour les véritables scénarios d'urgence de terminaison. Néanmoins, cela risquait une condition de course "réveil perdu" si wakeup() était exécuté pendant que le thread sélecteur traitait des clés plutôt que de bloquer, laissant potentiellement select() bloqué indéfiniment jusqu'à l'arrivée du prochain événement I/O.
La conception finale a synchronisé Selector.wakeup() avec un drapeau AtomicBoolean volatile d'arrêt en utilisant des sémantiques carefully happens-before. La séquence d'arrêt a atomiquement défini le drapeau puis invoqué wakeup(), tandis que la boucle d'événements vérifiait immédiatement le drapeau dès le retour de select(), sortant proprement si une terminaison était demandée, indépendamment de la disponibilité des clés. Cela a éliminé la rotation CPU, maintenu un débit I/O complet jusqu'à l'initiation de l'arrêt, et atteint une latence de terminaison inférieure à 50 ms sans avoir recours aux vérifications de statut d'interruption.
La passerelle a réussi à traiter plus de 10 000 connexions simultanées avec zéro demande échouée pendant les déploiements successifs. L'utilisation du CPU est restée à des niveaux de base tout au long des séquences d'arrêt, et l'architecture a permis une séparation claire entre la gestion des événements I/O et les signaux de gestion du cycle de vie.
Comment Thread.interrupted() diffère-t-il de Thread.isInterrupted(), et pourquoi le fait de vider le drapeau crée-t-il des dangers dans les routines de nettoyage imbriquées ?
Thread.interrupted() vérifie et vide l'état d'interruption du thread actuel, tandis que Thread.isInterrupted() sonde le drapeau sans modification. Dans les boucles de sélecteur, les développeurs invoquent souvent Thread.interrupted() pour détecter des signaux d'arrêt, dans l'intention de quitter la boucle. Cependant, si le code de nettoyage suivant effectue des opérations I/O bloquantes comme channel.close() ou attend la terminaison de CountDownLatch, ces opérations ne verront pas le statut d'interruption précédemment vidé, pouvant potentiellement bloquer indéfiniment au lieu de répondre à la demande de terminaison originale.
Pourquoi Selector.select() renvoie-t-il normalement zéro clés lors de l'interruption au lieu de lancer InterruptedException, et quelle ambiguïté de flux de contrôle cela crée-t-il ?
Contrairement aux méthodes bloquantes telles qu'Object.wait() ou Thread.sleep(), Selector.select() ne déclare pas InterruptedException et renvoie plutôt immédiatement zéro clés sélectionnées lorsque Thread.interrupt() est appelé. Ce choix de conception confond la véritable préparation I/O, qui peut coïncidentellement retourner zéro clés, avec les signaux d'interruption, obligeant les applications à mettre en œuvre des vérifications explicites d'état pour distinguer "aucun canal prêt" et "arrêt demandé". Les candidats oublient souvent cette distinction, écrivant des boucles qui supposent que zéro clés implique un livelock ou réessaie immédiatement, entraînant une saturation CPU lorsque le sélecteur répond simplement à un drapeau d'interruption.
Comment Selector.wakeup() ne fournit-il aucune garantie de visibilité mémoire pour les variables partagées, et pourquoi cela nécessite-t-il des sémantiques volatiles ou synchronisées pour les drapeaux d'arrêt ?
Bien que Selector.wakeup() débloque atomiquement le thread sélecteur, il n'établit pas de relation happens-before entre l'invocation de réveil et la lecture ultérieure des variables d'arrêt partagées par le thread débloqué. Par conséquent, sans déclarer le drapeau d'arrêt comme volatile ou y accéder au sein de blocs synchronisés, le thread sélecteur peut observer une valeur mise en cache obsolète (faux) même après l'exécution de wakeup(), le conduisant à ré-entrer dans select() et à se bloquer indéfiniment malgré le fait que l'arrêt logique ait été initié. Cette subtile interaction du Modèle de Mémoire Java signifie que wakeup() seul n'est pas suffisant pour une communication fiable entre threads ; il doit être associé à une synchronisation appropriée pour garantir la visibilité des changements d'état.