Lock : ce que c’est, types de verrous et utilisation en synchronisation

Qu’est-ce que Lock ?

Lock est une interface du paquet java.util.concurrent.locks qui fournit des opérations explicites de verrouillage et de déverrouillage pour synchroniser l’accès aux données. Contrairement à synchronized, Lock donne au développeur un contrôle total sur le mécanisme de verrouillage.

Définition et rôle dans la synchronisation

L’interface Lock a été introduite dans Java 5 comme alternative au mécanisme synchronized intégré. Les principales méthodes sont lock, unlock, tryLock et lockInterruptibly. Les verrous permettent d’organiser un accès sécurisé aux données dans un environnement multithread, évitant les conditions de concurrence et la corruption des données.

Le principal avantage de Lock par rapport à synchronized est la flexibilité. Le développeur peut tenter d’acquérir un verrou avec un délai d’attente, vérifier sa disponibilité sans bloquer ou organiser plusieurs files d’attente avec différentes priorités.

Histoire et évolution

Avant l’apparition de l’interface Lock dans Java 5, la seule méthode de synchronisation était synchronized, qui souffrait de limitations : pas de délais d’attente, pas d’attente interruptible et une file d’attente unique. Doug Lea a conçu le paquet java.util.concurrent, incluant Lock comme bloc fondamental.

Comment fonctionne un verrou ?

Un verrou gère l’accès via un indicateur d’état interne et une file d’attente. Lorsqu’un thread appelle lock(), le mécanisme vérifie si le verrou est libre et soit l’acquiert, soit place le thread dans la file d’attente jusqu’à sa libération.

Acquisition et libération atomiques

Au cœur de tout verrou se trouve une opération atomique de comparaison et d’échange (CAS). Lors de l’appel à lock(), le thread tente de définir atomiquement l’indicateur d’occupation. Si l’indicateur est déjà défini, le thread se bloque. Lors de unlock(), l’indicateur est effacé et un thread en attente est réveillé.

import java.util.concurrent.locks.ReentrantLock

val lock = ReentrantLock()

fun performTask() {
    lock.lock()
    try {
        // section critique
        println("Le thread ${Thread.currentThread().name} travaille")
    } finally {
        lock.unlock()
    }
}

File d’attente et réveil

ReentrantLock utilise en interne une liste doublement chaînée (file d’attente CLH) où chaque thread en attente est représenté par un nœud. Lorsque le verrou est libéré, le nœud de tête de la file est réveillé. Le mode équitable (fair) garantit l’ordre FIFO, tandis que le mode non équitable permet à un nouveau thread d’acquérir le verrou avant ceux qui attendent pour améliorer le débit.

Principaux types de verrous

Dans l’écosystème Java moderne, il existe plusieurs implémentations de verrous, chacune optimisée pour des scénarios spécifiques. Le choix du bon verrou impacte directement les performances et la fiabilité d’une application multithread.

ReentrantLock

ReentrantLock est l’implémentation de base la plus utilisée de Lock. Elle prend en charge la réacquisition par le même thread : si un thread possède déjà le verrou, un nouvel appel à lock() ne le bloque pas. Cela évite les deadlocks dans les appels récursifs.

ReentrantReadWriteLock

ReadWriteLock sépare les verrous en deux modes : lecture et écriture. Plusieurs threads peuvent détenir le verrou de lecture simultanément, mais l’écriture nécessite un accès exclusif. Cela améliore considérablement les performances en cas de lectures fréquentes et d’écritures rares.

StampedLock

StampedLock est l’implémentation la plus récente, introduite dans Java 8. Elle prend en charge trois modes : écriture, lecture et lecture optimiste. La lecture optimiste ne bloque pas les autres threads et valide les données après la lecture, offrant un gain de performance de 10 à 20 % par rapport à ReadWriteLock.

ReentrantLock et ses caractéristiques

ReentrantLock est l’implémentation de Lock la plus populaire, offrant plusieurs fonctionnalités indisponibles dans synchronized. Comprendre ses caractéristiques est essentiel pour un travail efficace avec le multithreading.

Équité du verrou (fairness)

Le constructeur de ReentrantLock accepte un paramètre fair. Lorsqu’il est true, le verrou garantit l’ordre FIFO ; lorsqu’il est false, un nouveau thread peut acquérir le verrou avant ceux qui attendent. Le mode équitable évite la famine mais réduit le débit de 10 à 20 % en raison de la surcharge de maintenance de la file d’attente.

Délais d’attente et attente interruptible

Contrairement à synchronized, ReentrantLock prend en charge tryLock avec un délai d’attente. Si le verrou ne peut pas être acquis dans le délai spécifié, le thread continue son exécution au lieu de se bloquer indéfiniment. La méthode lockInterruptibly permet d’interrompre un thread en attente via Thread.interrupt().

val lock = ReentrantLock()

fun tryTask() {
    if (lock.tryLock(500, TimeUnit.MILLISECONDS)) {
        try {
            println("Verrou acquis")
        } finally {
            lock.unlock()
        }
    } else {
        println("Échec de l’acquisition du verrou")
    }
}

Conditions

ReentrantLock prend en charge plusieurs variables de condition via la méthode newCondition(). Chaque Condition possède sa propre file d’attente, permettant des scénarios de réveil complexes. Les méthodes await() et signal() ont remplacé wait() et notify() des blocs synchronized, mais avec la prise en charge de plusieurs files d’attente.

ReadWriteLock et StampedLock

ReadWriteLock et StampedLock abordent l’optimisation de l’accès lorsque les lectures prédominent sur les écritures. Ils sont considérablement plus efficaces que ReentrantLock dans les scénarios où la lecture est plus fréquente que l’écriture.

ReadWriteLock en pratique

L’interface ReadWriteLock contient deux méthodes : readLock() et writeLock(). Le verrou de lecture peut être détenu par plusieurs threads simultanément, tandis que le verrou d’écriture est exclusif. Un exemple typique est un cache thread-safe : de nombreux threads lisent des données tandis qu’un seul les met à jour périodiquement.

class SafeCache<K, V> {
    private val map = mutableMapOf<K, V>()
    private val rwLock = ReentrantReadWriteLock()

    fun get(key: K): V? {
        rwLock.readLock().lock()
        return try { map[key] } finally { rwLock.readLock().unlock() }
    }

    fun put(key: K, value: V) {
        rwLock.writeLock().lock()
        return try { map[key] = value } finally { rwLock.writeLock().unlock() }
    }
}

StampedLock et lecture optimiste

StampedLock ajoute un troisième mode — tryOptimisticRead. Ce mode ne bloque pas les autres threads, mais enregistre simplement un tampon (stamp) d’état. Après la lecture, le développeur appelle validate(stamp) pour vérifier si les données ont changé pendant la lecture. Si les données ont changé, l’opération doit être répétée.

Verrous dans le développement mobile

Dans les applications mobiles, les verrous sont utilisés pour coordonner l’accès aux données partagées entre les threads. Cependant, leur utilisation nécessite une prudence particulière en raison des ressources limitées de l’appareil et de la nécessité de maintenir la réactivité de l’interface.

Verrous dans Android (Kotlin)

Sur Android, ReentrantLock est utile lorsqu’on travaille avec Room, les caches et les fichiers. Il est important de se rappeler : n’acquérez jamais un verrou sur le thread principal. Pour le code asynchrone, les coroutines et Mutex de kotlinx.coroutines sont préférables, car ils suspendent la coroutine au lieu de bloquer le thread.

Verrous dans iOS (Swift)

Sous iOS, le NSLock standard est moins utilisé — les développeurs préfèrent DispatchQueue avec des indicateurs barrier ou os_unfair_lock. Swift 5.7+ fournit des mécanismes de synchronisation modernes via les acteurs, qui protègent automatiquement l’état.

import Foundation

actor DataStore {
    private var items: [String] = []

    func add(_ item: String) {
        items.append(item)
    }

    func getAll() -> [String] {
        items
    }
}

Recommandations pour éviter les deadlocks

Pour éviter les deadlocks, suivez un ordre d’acquisition cohérent dans l’ensemble du projet. Utilisez tryLock avec un délai d’attente au lieu de lock() partout où un blocage prolongé est possible. Envisagez d’utiliser des algorithmes Lock-Free (AtomicReference, ConcurrentHashMap) au lieu des verrous traditionnels.

Bonnes pratiques pour travailler avec Lock

L’utilisation de Lock nécessite de la discipline et le respect de plusieurs règles qui préviennent les deadlocks et la dégradation des performances. Ces pratiques ont été développées par la communauté Java au cours de 20 ans d’utilisation du paquet java.util.concurrent.

Libération dans finally

Le modèle le plus important est lock dans finally. Que la section critique se termine avec succès ou lève une exception, le verrou doit être libéré. Cela garantit que les autres threads ne sont pas bloqués indéfiniment à cause d’une seule erreur. En Kotlin, ce modèle est élégamment résolu grâce à l’extension withLock.

Minimiser le temps de détention

La section critique doit être aussi courte que possible. N’effectuez jamais d’E/S, de requêtes réseau ou de calculs longs à l’intérieur d’un verrou. Si vous devez lire des données depuis un serveur, récupérez-les d’abord, puis acquérez le verrou uniquement pour mettre à jour l’état partagé. Cela réduit la contention et améliore le débit du système.

Ordre d’acquisition cohérent

Pour prévenir les deadlocks lors du travail avec plusieurs verrous, établissez un ordre d’acquisition global dans l’ensemble du projet. Si lockA est acquis en premier, puis lockB — toute séquence inverse doit être interdite par les règles de révision de code. Utilisez des analyseurs statiques tels que SpotBugs et IntelliJ Inspections pour une vérification automatique.