Discussion :

[alladdin]

Bonjour,

J'ai lu ce tutoriel sur le singleton en environnement multithread : http://christophej.developpez.com/tu...n/multithread/

Dedans on trouve notamment l'explication du pourquoi le DCL ne marche pas (possibilite d'avoir un objet partiellement initialise). Je pense avoir trouve une solution a ce problème et je voudrais avoir votre avis concernant cette solution.

L'idée est de rajouter , au niveau de la classe, un boolean (isCompleted) pour savoir si l'exécution du constructeur est fini ou non. Si le constructeur a fini, on retourne l'objet sinon on attend. Voici un code descriptif :

Code :

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
 
import java.util.* ;
class Singleton{
	private static Singleton instance;
	private List maList;
	private static boolean isCompleted = false;
	private Singleton(){
		maList= new ArrayList();
	}
	public static Singleton getInstance(){
	   if (instance==null){
		synchronized (Singleton.class){			
			if(instance==null){			
				instance=new Singleton();
                                isCompleted = true;
	                 }
	        }
	    } else{
                 while(!isCompleted){
                        wait(2000); //ajouter le try catch block. 2000 est un exemple mettre le temps approximatif de construction de l'objet 
                 }
            }
	 return instance;				
	}
}

A votre avis est ce que cette méthode marche ou pas ? Si oui qu'en pensez vous de manière général (meilleur que synchroniser toute la méthode getInstance() ?).


Merci d'avance pour vos réponses .

[adiGuba]

Salut,



Ca peut fonctionner... mais c'est lourd !

La plupart du temps l'initialisation static est amplement suffisante et bien plus simple à mettre en place...


a++

[alladdin]

Merci pour ta réponse rapide. Je ne peux pas utiliser l'initialiseur static, car j'ai absolument besoin que l'objet soit construit au premier appel de la méthode getInstance et pas avant. J'ai donc le choix entre synchroniser toute la méthode ou faire ce DCL "amélioré" (je trouve personnellement la méthode du ThreadLocal trop complique).

[tchize_]

et utiliser des apis comme commons discovery? Qui sont déjà prévue et conçues pour éviter ce problème

[alladdin]

Je ne connais pas l'api commons discovery, je vais faire un tour sur le net pour en apprendre d'avantage. En tout cas merci pour ce pointeur.

Sinon je pense que le code que tu as propose est plus simple que le mien et je pense qu'il devrait aussi fonctionner. Si ce n'est pas le cas quel est le problème ?

Encore merci pour ton aide.

[tchize_]

je l'ai retiré, mon code se faisait avoir comme un bleu: le out of order write

[thelvin]

Notons au passage que dans le code donné au départ, isCompleted n'est pas volatile.
Par conséquent, si elle est false en entrant dans la boucle while, elle ne deviendra jamais true à l'intérieur de cette boucle, et la boucle ne finira pas.

volatile permettrait à sa valeur de changer pendant la boucle, et avec les JVM modernes cela règlerait en effet le problème... Mais du coup, je ne vois pas ce que cela est censé faire de mieux qu'un DCL ?

[tchize_]

Notons au passage que dans le code donné au départ, isCompleted n'est pas volatile.
Par conséquent, si elle est false en entrant dans la boucle while, elle ne deviendra jamais true à l'intérieur de cette boucle, et la boucle ne finira pas.

Je ne suis pas certains que ce soit nécessaire dans ce cas ci. En effet, il y a un appel de méthode dans la boucle, la jvm n'a aucun moyen de savoir si cet appel ne change pas le champ de manière synchrone et donc est bien forcée de le relire depuis les champs de la classe.

Par contre, ta réflexion aurait été totalement justifié si on avait eu une boucle active:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

while(!isComplete){}

Enfin, rappelons pour le fun que volatile peut être ignoré par la JVM

[adiGuba]

Merci pour ta réponse rapide. Je ne peux pas utiliser l'initialiseur static, car j'ai absolument besoin que l'objet soit construit au premier appel de la méthode getInstance et pas avant.

Si getInstance() est l'unique élément static et que les constructeurs sont bien privés, alors ce sera bien le cas, à moins de charger la classe explicitement via un Class.forName("")...


a++