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.