Collections concurrentes

En Java, une collection (comme ArrayList, HashMap, etc.) est pensée pour un seul thread :

Un thread ajoute des éléments
Un thread lit des éléments
Et tout fonctionne sans problème.

MAIS, dans la vraie vie :

Les applications modernes sont multithread (ex: serveurs web, jeux vidéo, traitement d'images, etc.)
Plusieurs threads veulent lire, écrire, parcourir en simultanée.

Si on utilise des structures classiques sans protection → erreurs, données corrompues, exceptions.

Quels problèmes arrivent sans collections concurrentes ?

ConcurrentModificationException

Exemple : un thread modifie une liste pendant qu’un autre la parcourt.

Données perdues ou incohérentes

Exemple : deux threads ajoutent en même temps → un ajout est écrasé.

Corruption mémoire

Exemple : des structures internes (comme le tableau d'un ArrayList) sont mises à jour en même temps → état illisible, parfois même plantage du programme.

Exemple concret : une liste corrompue

Deux guichets enregistrent leurs transactions dans la même ArrayList. Chaque guichet en ajoute 1000 — on s'attend à 2000 entrées au total.

List<String> transactions = new ArrayList<>();

Thread guichet1 = new Thread(() -> {
    for (int i = 0; i < 1000; i++) {
        transactions.add("G1-retrait-" + i);
    }
});

Thread guichet2 = new Thread(() -> {
    for (int i = 0; i < 1000; i++) {
        transactions.add("G2-retrait-" + i);
    }
});

guichet1.start();
guichet2.start();
guichet1.join();
guichet2.join();

System.out.println("Transactions : " + transactions.size());
// Devrait afficher 2000, mais peut afficher 1823, 1956...
// ...ou lancer une ArrayIndexOutOfBoundsException ou NullPointerException !

Pourquoi ça plante ?

ArrayList grossit en agrandissant son tableau interne. Quand les deux threads appellent add() en même temps :

Thread 1 : lit size = 500, prépare d'écrire à l'index 500
Thread 2 : lit size = 500, prépare d'écrire à l'index 500  ← même index !
Thread 1 : écrit "G1-retrait-499" à l'index 500, size = 501
Thread 2 : écrit "G2-retrait-499" à l'index 500, size = 501  ← écrase Thread 1 !

Résultat : une entrée est perdue, size est décalé, et si un agrandissement du tableau se produit pendant ce temps → exception.

Solution avec `CopyOnWriteArrayList`

List<String> transactions = new CopyOnWriteArrayList<>();

Thread guichet1 = new Thread(() -> {
    for (int i = 0; i < 1000; i++) {
        transactions.add("G1-retrait-" + i);
    }
});

Thread guichet2 = new Thread(() -> {
    for (int i = 0; i < 1000; i++) {
        transactions.add("G2-retrait-" + i);
    }
});

guichet1.start();
guichet2.start();
guichet1.join();
guichet2.join();

System.out.println("Transactions : " + transactions.size()); // Toujours 2000

Chaque add() crée une copie complète du tableau interne — les deux threads ne peuvent jamais écraser le travail de l'autre.

Solutions naïves pour rendre une collection thread-safe

Avant Java 5 (avant les vraies collections concurrentes), on avait deux stratégies principales :

Utiliser `Collections.synchronizedXXX`

Exemples :

List<String> list = Collections.synchronizedList(new ArrayList<>());
Map<String, Integer> map = Collections.synchronizedMap(new HashMap<>());

Java fournit des wrappers qui synchronisent chaque accès à la collection.
AVANTAGE : simple à utiliser.
INCONVÉNIENT :
- Pas optimal : chaque opération est bloquante (lock global).
- Attention : lors de parcours (ex: for-each), il faut synchroniser manuellement :

synchronized(list) {
    for (String s : list) {
        System.out.println(s);
    }
}