Mutation d'un objet de verrouillage

Question

Juste curieux de savoir (avec autant de détails que possible), pourquoi est-il une mauvaise pratique à modifier l'objet tout en l'utilisant comme un verrou.

//Assuming the lockObject is globally available 
    synchronized(lockObject){ 
     lockObject.someMutativeOperation(...); 
    } 

Vive

Answer 1

Cest pas une mauvaise pratique, thats bonne pratique. Où avez-vous entendu autrement?

Si vous utilisez une synchronisation primitive, vous synchronisez sur un objet (ou un autre verrou) avant de le modifier.

Cela dépend cependant de la portée de l'objet. Si l'objet est étendu en dehors de votre classe, vous devez utiliser un mécanisme de synchronisation différent.

Answer 2

Je ne sais pas si j'ai déjà entendu cette affirmation. Certes, il serait mauvais de réattribuer lockObject (car alors vous verrouilleriez un objet différent ailleurs), mais je ne vois rien de mal à le faire.

De plus, il est assez fréquent d'avoir une méthode synchronized qui mute un objet:

public synchronized void setSomething(int something) { 
    this.something = something; 
} 

Dans ce cas, l'objet lui-même est utilisé comme la serrure. Quel est le point de synchronisation sur un objet séparé?

Answer 3

Je suppose que ce que vous avez entendu parler de la référence mute:

synchronized (thing) { 
    ... 
    thing = newThing; 
    ... 
} 

Cela indique généralement une erreur. Il aurait probablement dû être verrouillé en utilisant une référence qui ne change pas. Je pense que c'était Bitter Java qui avait un bug de cette nature dans un verrou en lecture-écriture (il y a eu un verrou en lecture-écriture dans la bibliothèque Java pendant cinq ans, donc l'implémentation spécifique n'est plus nécessaire).