Ce pattern, ou plutôt cet antipattern, est très bien connu des développeurs seniors, architectes ou tous ceux qui ont une passion certaines pour l’informatique et qui se sont penchés sur des problématiques d’optimisation en environnement multithread.

Je tiens à vous rappeler ici les principes de cet antipattern qui en réalité n’en est pas un en logique pur ! Que je m’explique, l’antipattern au sens où on l’entend classiquement, est  une violation des principes objets ou des  principes de design applicatifs. Pour l’avoir vécu, un feu EJB entity (je parle de ces bons vieux EJB entity BMP, CMP que JPA grâce à Hibernate a fini par tuer) qui appelle un EJB session est un antipattern. Pour ceux qui ne connaissent pas, on ne fait pas une couche d’accès aux données remonter au niveau de la couche de services.  Cela viole les principes de séparation des couches et de responsabilités. Cela peut également créer des  problématiques de référence circulaire contourné par des antipatterns encore plus affreux. Dans le cas des EJB entities, cela pouvait même amener des problématiques de performance…

Le double-checked locking, lui, ne viole aucun principe de design ou objet. Quelqu’un qui maîtrise le threading peut réussir à le mettre en oeuvre par pure réflexion, sans penser une seconde qu’il se trompe. Et le pire, c’est qu’il n’y a pas de problématique de raisonnement ; il faut simplement connaître le problème, sinon on ne le contourne pas.

Bon, de quoi parle-t-on ? Qu’est-ce que le double-checked locking ?

Pour le comprendre, commençons par créer un Singleton en Java

public class MonSingleton {
    private static MonSingleton c = null;
    public static MonSingleton getInstance() {
        if (instance == null) {
            instance = new MonSingleton();
        }
        return instance;
    }
    // Méthodes
}

En multithread, un bug peut se créer au niveau du getInstance. Imaginons 2 threads, thread 1 et thread 2 qui se retrouvent en simultanée dans la méthode getInstance. Iml’ginons que thread1 soit juste avant l’appel à new MonSingleton que l’ordonnanceur donne le contrôle à thread 2. Il rentre dans la méthode getInstance, « instance » est toujours nul donc il rentre dans le if. L’ordonnanceur donne le contrôle à thread 1 qui fait sont new MonSingleton(), retourne ensuite une instance… Puis thread 2 s’exéute, créé son instance  et retourne donc un nouveal object, pas le même que thread 1. Nous n’avons donc pas créé un singleton en multithread. Pour info, ceci n’est pas obligatoirement gênant mais vous pourriez être dans un ccas de figure où ça l’est.

Comment éviter ceci ? Premier réflexe, utiliser synchonized en Java ou lock en C#.

public class MonSingleton {
    private static MonSingleton c = null;
    public static synchronized MonSingleton getInstance() {
        if (instance == null) {
            instance = new MonSingleton();
        }
        return instance;
    }

L’inconvénient de cette méthode, qui marche très bien, est qu’elle dégrade les performances. En effet, l’appel à getInstance se fait en série. Il n’est pas possible à 2 threads d’obtenir l’instance même si celle-ci a été créée.

Le double-checked locking peut alors être mis en place

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

Aucun problème de logique ici. On décale au plus tard la phase de lock et on ne synchronise que la partie qui nous intéresse. En faisant ainsi on pense avoir trouvé la solution idéale… Mais il y a un hic !! Ce hic est la façon dont fonctionne les compilateurs et les processeurs qui réordonnent les instructions. Les processeurs  utilisent également leurs registres pour accéder plus rapidement aux variables plutôt qu’en les lisant en RAM.La solution ne tient pas à grand chose. En C#(depuis le début) et Java (depuis Java 5), le mot clé « volatile » est la solution.

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