Le Singleton en environnement Multithread

Le principe du singleton repose sur un constructeur déclaré privé, un attribut permettant de stocker l'instance de la classe et une méthode statique qui vérifie qu'une instance de la classe a été créée et la renvoie. Lors du premier appel, cette méthode voyant que l'instance n'existe pas, elle la crée et la stocke dans l'attribut privé. Le code suivant représente la structure d'un singleton

import java.util.* ;
class Singleton{
    private static Singleton instance;
    private List maList;
    private boolean etat;

    private Singleton(){
        maList= new ArrayList();
        etat = true;
    }
    public static Singleton getInstance(){
        if (instance==null)                    //1
            instance=new Singleton();            //2
        return instance;                    //3
    }
}

Cette implémentation fonctionne, mais uniquement dans un environnement monothread. Le problème est que dans le cadre d'une implémentation multithread, la méthode getInstance() est susceptible de retourner deux instances différentes du Singleton si elle n'est pas protégée par synchronisation.

Considérons deux threads appelant cette méthode de façon concurrente et la séquence suivante d'événements :

1. Thread 1 appelle getInstance() et détermine que instance est null en ligne //1 ;
2. Thread 1 entre dans le bloc if puis est préempté par le thread 2 avant l'exécution de la ligne //2 ;
3. Thread 2 appelle getInstance() et détermine que instance est null en ligne //1 ;
4. Thread 2 entre dans le bloc if, crée un nouveau Singleton et assigne ce nouvel objet à la variable instance en ligne //2 ;
5. Thread 2 retourne la référence au Singleton en ligne 3 ;
6. Thread 2 est préempté par le Thread 1 ;
7. Thread 1 reprend où il s'était arrêté et exécute la ligne //2 créant alors une autre instance de Singleton ;
8. Thread 1 retourne cette nouvelle instance en ligne //3.

Nous voyons donc que nous avons obtenu deux instances de notre Singleton. Statistiquement, ce risque est faible, puisque cela peut se produire uniquement lors du premier appel du Singleton. Il s'agit ici du cas typique de bogue, entraînant des plantages aléatoires difficilement reproductibles en débogage.

Java traite chaque thread comme s'il fonctionnait sur son propre processeur, avec sa propre mémoire locale, chacun parlant avec et se synchronisant sur une mémoire principale partagée. Même sur des systèmes monoprocesseurs, ce modèle de mémoire est important à cause des caches de mémoire et de l'utilisation de registres des processeurs pour le stockage de variables. Quand un thread modifie une variable dans sa mémoire locale, ce changement n'est pas forcément répercuté instantanément sur la mémoire principale. Le compilateur est autorisé à réordonner les opérations d'écriture/lecture vers la mémoire à des fins de performance tant que le thread courant ne voit pas la différence.

Il existe plusieurs types de gestion de mémoire et cache au niveau des processeurs en fonction des architectures matérielles, mais aussi des choix d'implémentation de l'OS. Comme java est destiné à être multiplateforme et que le modèle de mémoire de java autorise un certain nombre de réarrangements à des fins de performance, dites-vous que ce qui marche aujourd'hui sur votre machine peut ne pas marcher sur la machine de votre voisin à moins de prendre en considération ces problèmes. Ce n'est pas parce que sur votre ordinateur, votre fonction s'exécute de façon procédurale qu'il en sera de même pour les autres ordinateurs. Vous ne savez pas sur quel type d'architecture s'exécutera votre application plus tard surtout avec l'apparition des processeurs multicores dans la machine de monsieur tout le monde.

Pour parer à ces éventuels problèmes, la gestion de la mémoire en java est clairement décrite sous l'appellation de Java Memory Model ou JMM. Le JMM autorise l'optimisation des écritures/lectures en mémoire en les réordonnant. Il définit les réorganisations qui sont autorisées et définit aussi une sémantique permettant de prévoir le comportement de la mémoire. Cette sémantique comprend des termes tels que synchronized et volatile. Il est originellement défini au chapitre 17 de Java Language Specification, mais comporte certaines failles faisant, entre autres, que les String ne sont pas réellement immutables. Ce JMM a été spécifié une nouvelle fois par la JSR 133 (Java Specification Request) qui est partiellement incluse dans le JDK1.4 puis le JDK 1.5.

L'utilisation de la synchronisation inclut l'exclusion mutuelle de l'exécution de certaines portions de code sur la base de sémaphores, mais elle impose aussi des règles sur l'interaction des threads avec la mémoire principale. Ainsi un thread doit transférer toutes ses variables modifiées dans la mémoire principale avant la libération du sémaphore. De même à l'entrée d'un bloc synchronisé, c'est comme si toute la mémoire locale du thread était invalidée et ce dernier doit recharger depuis la mémoire principale toutes les variables qui sont référencées dans le bloc synchronisé. On peut dire que deux blocs de code se synchronisant sur le même objet s'exécutent de façon atomique l'un pour l'autre. Ces lectures/écritures de variables et l'acquisition des sémaphores font que la synchronisation de code entraîne un ralentissement de son exécution.

III-B-1. La synchronisation de getInstance()▲

public static synchronized Singleton getInstance(){
    if (instance==null)                //1
        instance=new Singleton();        //2
    return instance;                //3
}

III-B-2. La synchronisation de l'appel au constructeur▲

public static Singleton getInstance(){
    if (instance==null)                    
    {
        synchronized (Singleton.class){
            instance=new Singleton();        
        }
    }
    return instance;                    
}

III-B-3. Le double-check locking▲

public static Singleton getInstance(){
    if (instance==null)                    
    {
        synchronized (Singleton.class){            //1
            if(instance==null)            //2
                instance=new Singleton();    //3
        }
    }
    return instance;                    
}

mem = allocate() ;
instance = mem ;
ctorSingleton(instance)

Apparu avec le JDK 1.2, ThreadLocal peut sembler être une solution au problème du DCL. Une variable ThreadLocal est une variable qui a une copie différente pour chacun des threads qui l'utilisent. Chaque thread peut manipuler sa version de la variable indépendamment des autres threads et, en réalité, ignore complètement la valeur de cette variable dans les autres threads. La classe ThreadLocal présente trois méthodes :

public class ThreadLocal {
    public Object get();
    public void set(Object newValue);
    public Object initialValue();
}

Les méthodes get() et set() sont des accesseurs à la valeur pour la version de la variable du thread courant, et la méthode initialValue() agit comme un constructeur qui initialise la variable sur la base d'une variable par thread. Le code du Singleton pourrait alors être le suivant :

Class ThreadLocalSingleton{
  private static ThreadLocal initHolder = new ThreadLocal()
  private static ThreadLocalSingleton instance=null;

  public static ThreadLocalSingleton getInstance(){
    if (initHolder.get() == null){
      synchronized{
        if (instance== null)
          instance = new ThreadLocalSingleton();
        initHolder.set(Boolean.TRUE);
      }
    }
    return instance;
  }
}

Le principe de cette implémentation est qu'au lieu de vérifier l'instance partagée entre les threads, elle utilise l'objet ThreadLocal pour voir si le thread est passé dans le bloc synchronisé. Comme ThreadLocal implique qu'il n'y a pas de partage de la variable entre les threads, nous n'avons pas de problème d'écriture dans le désordre. Toutefois l'implémentation de ThreadLocal était peu performante dans les premiers JDK et reposait sur la synchronisation, ce qui fait que cette méthode n'est pas plus performante que la synchronisation de toute la méthode getInstance. L'implémentation de ThreadLocal a été repensée et réécrite pour les JDK plus récents. Toutefois vous ne pouvez garantir sur quelle version du JDK votre application fonctionnera et donc si cette méthode vous apportera un gain de performance.

On peut envisager de déclarer instance comme un champ volatile. Volatile est défini pour faire en sorte qu'il n'y ait pas d'utilisation du cache pour les attributs déclarés volatile.

Toutefois, si l'ancien modèle de mémoire de la JVM prévient de la réorganisation de l'écriture des variables volatile entre elles et assure qu'elles sont transférées immédiatement dans la mémoire principale, il autorise la réorganisation des lectures/écritures des variables volatile par rapport aux lectures/écritures des variables non volatile. Cela signifie que -à moins que toutes les ressources soient volatiles- thread 2 peut percevoir les effets du constructeur après que instance ait référencé le nouveau Singleton créé. La solution est alors de déclarer toutes les variables comme volatiles, ayant pour conséquence l'absence d'utilisation des registres et la dégradation des performances.

Le nouveau JMM fixe ce problème en interdisant la réorganisation par rapport aux autres variables. Mais alors, nous nous retrouvons dans le cas de la synchronisation avec un flush complet du registre du processeur. Le gain de performance recherché en n'utilisant pas la synchronisation est alors nul.

Comme vous ne savez pas sur quelle version de la JVM votre application s'exécutera, il est fortement recommandé de ne pas utiliser cet idiome.