Concepts multithreading dans une impasse partielle-javaDidacticiel-php.cn

Bienvenue dans la troisième partie de notre série multithreading !

Dans la première partie, nous avons exploré l'Atomicité et l'Immuabilité.
Dans la deuxième partie, nous avons discuté de la Famine.

Dans cette partie, nous allons plonger dans la mécanique du Deadlock en multithreading. Quelles en sont les causes, comment identifier les stratégies préventives que vous pouvez utiliser pour éviter de transformer votre code en une intersection bloquée. L'application s'arrête, souvent sans aucune erreur visible, laissant les développeurs perplexes et les systèmes gelés.

Multithreading Concepts Part Deadlock

Naviguer sur les pistes complexes de la concurrence

Une analogie utile pour comprendre l'impasse est d'imaginer un réseau ferroviaire avec plusieurs trains sur des voies qui se croisent.

Comme chaque train attend que le suivant parte, aucun ne peut avancer, ce qui conduit à une impasse. Dans ce scénario, le système de signalisation inefficace permettait à chaque train d'entrer dans sa section respective sans confirmer au préalable que la section suivante serait libre, piégeant tous les trains dans un cycle incassable.

Cet exemple de train illustre une impasse typique du multithreading, où les threads (comme les trains) conservent des ressources (sections de voie) en attendant que d'autres ressources soient libérées, mais aucune ne peut progresser. Pour éviter ce type de blocage dans les logiciels, des stratégies efficaces de gestion des ressources, analogues à une signalisation ferroviaire plus intelligente, doivent être mises en œuvre pour éviter les dépendances circulaires et garantir un passage sûr pour chaque thread.

1. Qu'est-ce que l'impasse ?

Deadlock est une situation dans laquelle les threads (ou processus) sont indéfiniment bloqués, en attente de ressources détenues par d'autres threads. Ce scénario conduit à un cycle incassable de dépendances, dans lequel aucun thread impliqué ne peut progresser. Comprendre les bases de l'impasse est essentiel avant d'explorer les méthodes de détection, de prévention et de résolution.

2. Conditions d'impasse

Pour qu'une impasse se produise, quatre conditions doivent être remplies simultanément, connues sous le nom de conditions de Coffman :

Exclusion mutuelle : Au moins une ressource doit être conservée dans un mode non partageable, ce qui signifie qu'un seul fil de discussion peut l'utiliser à la fois.
Maintenir et attendre : Un thread doit contenir une ressource et attendre d'acquérir des ressources supplémentaires que d'autres threads détiennent.
Aucune préemption : Les ressources ne peuvent pas être supprimées de force des threads. Ils doivent être libérés volontairement.
Attente circulaire : Il existe une chaîne fermée de threads, où chaque thread contient au moins une ressource nécessaire au thread suivant de la chaîne.

Multithreading Concepts Part Deadlock

Comprenons comme un diagramme de séquence

Multithreading Concepts Part Deadlock

Dans l'animation ci-dessus,

Le fil de discussion A contient la ressource 1 et attend la ressource 2
Pendant que le fil B détient la ressource 2 et attend la ressource 1

Les quatre conditions partagées ci-dessus pour l'impasse sont présentes, ce qui entraîne un blocage indéfini. Briser l’un d’entre eux peut éviter une impasse.

3. Détecter/Surveiller les blocages

La détection des blocages, en particulier dans les applications à grande échelle, peut s'avérer difficile. Cependant, les approches suivantes peuvent aider à identifier les impasses

Outils : La JConsole, VisualVM et les analyseurs de threads de Java dans les IDE peuvent détecter les blocages en temps réel.
Dumps de threads et journaux : L'analyse des vidages de threads peut révéler les threads en attente et les ressources qu'ils contiennent.

Pour un aperçu détaillé de la façon de déboguer/surveiller les blocages, veuillez visiter Déboguer et surveiller les blocages à l'aide de VisualVM et jstack

4. Stratégies de prévention des blocages

Application des schémas Wait-Die et Wound-Wait
Schéma Wait-Die : lorsqu'un thread demande un verrou détenu par un autre thread, la base de données évalue la priorité relative (généralement en fonction de l'horodatage de chaque thread). Si le thread demandeur a une priorité plus élevée, il attend ; sinon, il meurt (redémarre).
Schéma d'attente de blessure : si le thread demandeur a une priorité plus élevée, il bles (préempte) le thread de priorité inférieure en le forçant à libérer le verrou.
Objets immuables pour l'état partagé
Concevez l’état partagé comme immuable dans la mesure du possible. Étant donné que les objets immuables ne peuvent pas être modifiés, ils ne nécessitent aucun verrou pour un accès simultané, ce qui réduit le risque de blocage et simplifie le code.
Utilisation de tryLock avec Timeout pour l'acquisition du verrou : Contrairement à un bloc synchronisé standard, ReentrantLock permet d'utiliser tryLock(timeout, unit) pour tenter d'acquérir un verrou dans un délai spécifié. Si le verrou n’est pas acquis dans ce délai, il libère des ressources, empêchant ainsi un blocage indéfini.

ReentrantLock lock1 = new ReentrantLock();
ReentrantLock lock2 = new ReentrantLock();

public void acquireLocks() {
    try {
        if (lock1.tryLock(100, TimeUnit.MILLISECONDS)) {
            try {
                if (lock2.tryLock(100, TimeUnit.MILLISECONDS)) {
                    // Critical section
                }
            } finally {
                lock2.unlock();
            }
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    } finally {
        lock1.unlock();
    }
}

Copier après la connexion

Commande et libération de verrous Définissez un ordre strict et global pour l’acquisition des verrous. Si tous les threads acquièrent les verrous dans un ordre cohérent, les dépendances cycliques sont moins susceptibles de se former, évitant ainsi les blocages. Par exemple, acquérez toujours lock1 avant lock2 dans toute la base de code. Cette pratique peut s'avérer difficile dans les applications plus volumineuses, mais elle s'avère très efficace pour réduire le risque de blocage.

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class LockOrderingExample {

    private static final Lock lock1 = new ReentrantLock();
    private static final Lock lock2 = new ReentrantLock();

    public static void main(String[] args) {
        Thread thread1 = new Thread(() -> {
            acquireLocksInOrder(lock1, lock2);
        });

        Thread thread2 = new Thread(() -> {
            acquireLocksInOrder(lock1, lock2);
        });

        thread1.start();
        thread2.start();
    }

    private static void acquireLocksInOrder(Lock firstLock, Lock secondLock) {
        try {
            firstLock.lock();
            System.out.println(Thread.currentThread().getName() + " acquired lock1");

            secondLock.lock();
            System.out.println(Thread.currentThread().getName() + " acquired lock2");

            // Perform some operations

        } finally {
            secondLock.unlock();
            System.out.println(Thread.currentThread().getName() + " released lock2");

            firstLock.unlock();
            System.out.println(Thread.currentThread().getName() + " released lock1");
        }
    }
}

Copier après la connexion

Utiliser des collections Thread-Safe/Concurrent : le package java.util.concurrent de Java fournit des implémentations thread-safe de structures de données courantes (ConcurrentHashMap, CopyOnWriteArrayList, etc.) qui gèrent la synchronisation en interne, réduisant ainsi la nécessité de verrous explicites. Ces collections minimisent les blocages car elles sont conçues pour éviter le besoin de verrouillage explicite, en utilisant des techniques telles que le partitionnement interne.
Éviter les verrous imbriqués
Minimisez l’acquisition de plusieurs verrous dans le même bloc pour éviter les dépendances circulaires. Si des verrous imbriqués sont nécessaires, utilisez un ordre de verrouillage cohérent

Points clés à retenir pour les ingénieurs logiciels

Chaque fois que vous créez une conception qui nécessite un verrouillage, vous ouvrez la possibilité de blocages.
Deadlock est un problème bloquant causé par un cycle de dépendances entre les processus. Aucun processus ne peut progresser car chacun attend une ressource détenue par un autre, et aucun ne peut procéder à la libération de ressources.
L'impasse est plus grave, car elle arrête complètement les processus impliqués et nécessite de rompre le cycle d'impasse pour la récupération.
Un Deadlock ne peut se produire que lorsqu'il existe deux verrous différents, c'est-à-dire lorsque vous détenez un verrou et attendez qu'un autre verrou se libère. (Il y a cependant plus de conditions sur les blocages).
Thread-safety ne signifie pas sans blocage. Il garantit uniquement que le code fonctionnera conformément à son interface, même lorsqu'il est appelé depuis plusieurs threads. Rendre une classe thread-safe implique généralement l'ajout de verrous pour garantir une exécution sûre.

Sortie

Que vous soyez un développeur débutant ou chevronné, comprendre les blocages est crucial pour écrire du code robuste et efficace dans des systèmes concurrents. Dans cet article, nous avons exploré ce que sont les blocages, leurs causes et les moyens pratiques de les éviter. En mettant en œuvre des stratégies efficaces d'allocation des ressources, en analysant les dépendances des tâches et en utilisant des outils tels que les thread dumps et les outils de détection des blocages, les développeurs peuvent minimiser le risque de blocage et optimiser leur code pour une concurrence fluide.

Alors que nous poursuivons notre voyage à travers les concepts fondamentaux du multithreading, restez à l'écoute pour les prochains articles de cette série. Nous allons plonger dans les Sections critiques, pour comprendre comment gérer les ressources partagées en toute sécurité entre plusieurs threads. Nous discuterons également du concept de Race Conditions, un problème de concurrence courant qui peut conduire à un comportement imprévisible et à des bugs si rien n'est fait.

À chaque étape, vous obtiendrez des informations plus approfondies sur la façon de rendre vos applications thread-safe, efficaces et résilientes. Continuez à repousser les limites de vos connaissances multithreading pour créer des logiciels meilleurs et plus performants !