Je suis en train de lire un truc dans la Javadoc qui m'intrigue un peu. Pour synchronizer un HashSet (par exemple), ils disent de faire le code suivant :

 
Ce que je comprend pas, c'est l'utilité de la manière dont ont récupère le "synchronizedSet". Puisqu'on doit quand même gérer la synchronization. Logiquement, même si j'avais pas fait "synchronizedSet", mais un new simple de ma HashSet, si je met les instructions à risque dans des bloques "synchronized", mon truc sera tread-safe qd même, non ?

et ça :

 
Selon vous, ça veut dire qu'on peut pas caster le Set obtenu en HashSet ?

Je pense que le synchronizedSet peut être accéder directement sans utiliser de bloc 'synchronized' (c'est à dire, lire un élément, ajouter un élément,...), sinon, ça n'a aucune utilité d'utiliser un Set synchronizé par rapport à un Set standard. En revanche, quand tu utilises un Iterator, pour être sûr que le set sous jacent n'est pas modifié entre le moment où tu instancies l'Iterator et le moment où tu finis de le parcourir, il faut utiliser un bloc synchronized.  
Et je ne pense pas que tu puisses caster le set obtenu par Collections.synchronizedSet() en HashSet mais seulement en Set (mais je pense que les méthodes disponibles sont les mêmes).

Pour l'histoire du cast, je posais la question parce que je m'apprête à crééer un classe étendant HashSet qui, elle, aurait des méthode autres que celles de Set.

Et, apparement, si j'étend Vector plutot que HashSet, j'ai pas à me soucier de la synchronisation, même si j'utilise une énumération rendue par

?

 
AMHA il y a deux choses :  
 
Les SynchronizedSets assurent que seul un thread a la fois manipule le contenu de ton Set : on te garantit l'atomicite des manipulations sur ton set. En d'autres termes tu as un acces atomique sequentiel au contenu du set.
 
La synchronisation d'objet assure que seul un thread a la fois manipule ton Set : Si tu desire creer un iterateur sur le contenu de ton set l'atomicite du synchronizedSet n'est pas suffisante. Non seulement tu ne veux pas que des objets soient ajoutes ou enleves de ton set en meme temps que tu fais une manipulation, mais en plus tu ne veux pas que ce soit le cas sur un ensemble de manipulations.  
 

 
Bref, cette énumération récupérée permet d'énumérer une copie du contenu des éléments de ce vector ou d'énumérer les éléments eux même. J'm'explique : par exemple si je fais ça:
1 - je récupère une enumération à un instance donné.
2 - je vide mon Vector de tout ce qu'il contient
3 - j'utilise l'énumération récupérée en "1" pour énumérer les éléments. J'énumére les éléments qui étaient ds le Vector en "1" ou j'énumère rien du tout ?

Faudrait verifier, mais je pense que elements() crée une copie des elements du Vector. Donc d'apres moi, l'énumération est inchangée après suppression du contenu du Vector. Mais je ne suis sur de rien, hein.

 
à priori je suis d'accord avec toi...

à priori...

je suis sur que ce n'est pas le cas pour iterator() de ArrayList mais pour elements de Vector je sais pas...
mais ca me parrait un peu lourd qu'il fasse une copie ...

Il n'y a pas de copie pour elements(). J'ai fait quelques tests pour en être sûr, mais comme l'a dit benou ça serait pas efficace de copier tout le Vector avant d'itérer dessus.

 
Pour Iterator, ça parait logique ce que tu dis : la méthode remove perdrait vachement de son interêt si on bossait sur une copie des éléments.
Mais alors si j'utilise une enumération ds un contexte multi threads, 'faut que je synchronize mon vector autour de l'énumération, non ?

genre :

 
non ?