C'est vrai qu'aujourd'hui, avec les dernières JVM, il n'est plus utile d'avoir recours au double-checked locking étant donné que le coût des blocs synchronized a fortement baissé.
Lorsque j'ai entendu parler de ce problème, j'ai voulu voir si devoir faire deux tests ne faisait pas perdre le temps gagné en ne passant pas dans un bloc synchronized. Résultat des courses avec la JVM 1.4, que ça soit en interprété ou avec hotspot (client et serveur) : laisse tomber, c'est quasiment la même chose. Donc autant déclarer toute la méthode synchronized.
De plus, une petite recherche dans la base de données de bugs chez SUN montre qu'il n'existe aucun bug ouvert ressemblant à ça ... Il a probablement été résolu (du moins pour la JVM de SUN) : http://search.java.sun.com/Search/java?qt=+%2Bstate%3Aopen+%2B%22do(...) (il faut être enregistré (gratuit) sur le JDC pour accéder à cette page)
[^] # Re: Sympa ce comparatif
Posté par François B. . En réponse à la dépêche "The Great Computer Language Shootout" Divers langages et compilateur au banc d'essai. Évalué à 9.
Lorsque j'ai entendu parler de ce problème, j'ai voulu voir si devoir faire deux tests ne faisait pas perdre le temps gagné en ne passant pas dans un bloc synchronized. Résultat des courses avec la JVM 1.4, que ça soit en interprété ou avec hotspot (client et serveur) : laisse tomber, c'est quasiment la même chose. Donc autant déclarer toute la méthode synchronized.
De plus, une petite recherche dans la base de données de bugs chez SUN montre qu'il n'existe aucun bug ouvert ressemblant à ça ... Il a probablement été résolu (du moins pour la JVM de SUN) : http://search.java.sun.com/Search/java?qt=+%2Bstate%3Aopen+%2B%22do(...) (il faut être enregistré (gratuit) sur le JDC pour accéder à cette page)