Bon, c'est surement très bateau, mais tant pis, ça me saoule, j'arrive pas.
Voila le bout de code suivant :

 
 
ça se passe dans nu singleton (JLDSExploitLog).
Cette méhode étant statique, dans une appli multi threadée, il faut que je synchronize qqch. Je voudrais synchroniser le moins possible, évidement, mais je n'sais pas comment me servir de ce "synchronized"...

Tu peux tenter de synchroniser sa classe (java.lang.Class).

Ca depends si les objets d'autres classes utilisent ton singleton. Sinon tu peux faire :

Mais je suis pas un pro de cs choses-là no plus.

el_gringo, c'est aps évident à dire comme ca où tu dois placer ton bloc synchronized ... ca dépend de ce qui doit être executé en mono-threadé ...
 
 
Si ta méthode n'était pas statique, tu pourrait faire un bloc synchronized sur this comme le disait R3g ...
 
Souvent, quand la méthode est statique, comme on a pas de "this", on gère la synchronization sur l'objet Class de l'objet genre :  
 

mais perso j'aime pas comme méthode parce que cet objet class est atteignable de partout dans la JVM => rien n'empeche un autre objket ailleur dans le programme de se synchronizer sur ce même objet class (même si ce serait vraiment bizarre) et donc de flinguer le comportement de ton objet
 
Moi dans ces cas là, je déclarre un objet bidon qui servira de verrou :
 

j'avais lu un article tres interessant à ce sujet ... qui en fait démystifiait le synchronized et son mythe(donc) associé à sa lenteur/lourdeur... j'essaie de le retrouver
 
ha ben le voila:
http://www-106.ibm.com/developerwo [...] 04223.html

 
Mais ça, ça empêche un accès multi threadé à tous le contenu du bloc ? je croyais que ça empêchais juste à plusieurs threads d'opérer sur "lock" en meme temps...

benou >
 
Wu gui > Excellent article. Ça me rappelle un certain Michael Jackson (pas sûr du nom, j'ai égaré le bouquin qui le citait) qui proposait deux règles en Java :
1. N'optimise pas.
2. N'optimise pas encore.
 
El_gringo > Que veux-tu dire par "opérer" ? Si c'est synchroniser dessus, c'est bien le cas, puisque cet objet est privé, en supposant qu'il n'ait pas de getter.

 
Mais en synchronizant comme ça donc, j'empêche tout accès simultané daans ce bloc, c ça ?

Oui oui c'est bien ça.

  ca revient exactement au même tes 2 phrases ...
 
Chaque objet a un jeton. Quand un thread se synchronize sur un objet, il prend le jeton de l'objet et execute le bloc. Si un autre thread se synchronize sur le même objet, il doit attendre que l'autre thread ait relaché le jeton. Là il pourra le prendre, et executer le bloc, etc ....

 
Ouais, évidement. J'pensais un peu "tordu".
Ben, merci alors.

 
et puis il ne me semble pas que l'article dise de ne pas optimiser, mais simplement qu'il demystifie le synchronized. la synchro autour d'un objet comme la propose benou me parait claire, mais dans d'autre cas, certains pourrait arriver à du code totalement tordu pour... rien ou presque...
 

Oui, mais ça allait dans le même sens à mon avis : optimiser seulement quand c'est nécessaire.

euh mais en fait ta réponse était serieuse alors? c'est qui ce michael jackson? devrait changer de nom, ça fait pas serieux

Arf, désolé, j'aurais du le préciser. Je m'en souviens justement parce qu'un tel nom dans ce milieu, ça marque forcément. D'après mes souvenirs, le bouquin dont je parle donne des conseils concernant les conventions de codage. C'est un bouquin en anglais.

ok