Discussion :

[C�dou]

Bonjour ,

Je voulais un patron qui ne permait qu'une seule instance d'une classe par id :
je suis tomb� sur le patron Multiton :

Code java :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
public class FooMultiton {
    private static final Map<Object, FooMultiton> instances = new HashMap<>();
 
    private FooMultiton() {
        // no explicit implementation
    }
 
    public static synchronized FooMultiton getInstance(Object key) {
 
        // Our "per key" singleton
        FooMultiton instance = instances.get(key);
 
        if (instance == null) {
            // Lazily create instance
            instance = new FooMultiton();
 
            // Add it to map   
            instances.put(key, instance);
        }
 
        return instance;
    }
 
    // other fields and methods ...
}

source

qui correspond � ce que je veux

n�hanmoins, connaissant le patron singleton je me demande si c'est optimal

ne faudrait-il pas faire :

Code Java :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
public class FooMultitonPerso {
    private static volatile Map<Object, FooMultitonPerso> instances = new HashMap<>();
 
    private FooMultitonPerso() {
        // no explicit implementation
    }
 
    public static FooMultitonPerso getInstance(Object key) {
 
        FooMultitonPerso instance = instances.get(key);
 
        if (instance == null) {
            synchronized(FooMultitonPerso.class) {
            // ou synchronized(instances) { est-ce équivalent dans ce cas ?
                instance = instances.get(key);
                if(instance == null) {
                    instance = new FooMultitonPerso();
                    instances.put(key, instance);
                }
            }
        }
        return instance;
    }
 
    // other fields and methods ...
}

de cette mani�re la synchronization, couteuse en temps, n'est utilis�e que si r�ellement n�c�ssaire et pas syst�matiquement comme dans la m�thode FooMultiton.getInstance propos�e par wikipedia.

Mais en ce qui concerne FooMultitonPerso
1) est-ce que ce code est bien thread safe ?
2) et est-il plus performant que FooMultiton ?
3) faut-il mieux faire la synchronisation sur FooMultitonPerso.class ou instances ?

merci d'avance

[tristan_m]

Bonjour,

Je ne connais pas le mot cl� synchronized. Je suppose que c'est une sorte de section critique?

Ici la variable � prot�ger des acc�s concurrentiels est 'instances', car elle est static et donc accessible par tous les threads en m�me temps.
Donc TOUTES les op�rations sur cette variable doivent �tre prot�g�es. A l'exception d'une op�ration atomique isol�e.

Votre fonction getInstance n'est pas thread-safe dans les cas suivants :

• instances.get(key) n'est pas prot�g�. N'�tant vraisemblablement pas atomique, un autre thread peut modifier le contenu des donn�es en m�me temps que le thread courant est en train de le lire. Le r�sultat est donc non garanti.
• l'appel � get(key) retourne une valeur existante. Un autre thread d�truit l'instance juste apr�s. Le retour de votre fonction est donc une instance qui en fait n'existe plus.
• Deux threads appellent la m�thode getInstance en m�me temps avec le m�me param�tre key. Ils d�tectent tous les deux que l'intance n'existe pas encore. Le premier thread r�serve la section critique et cr�� l'instance. Le deuxi�me thread attend que le premier thread ait termin� puis cr�� �galement l'instance. L'instance retourn�e par le premier thread devient invalide.

Ce dernier cas implique que les deux op�rations 'instances.get(key)' et 'instances.put(key, instance)' soient 1) prot�g�es et 2) dans la m�me section critique.

Donc � moins que j'aie mal interpr�t� le fonctionnement de synchronized, je pense que l'exemple que vous avez cit� de wikip�dia est bon.