(できるだけ詳細に)知りたいのですが、オブジェクトをロックとして使用しているときにオブジェクトを変更するのはなぜ悪い習慣なのですか。
//Assuming the lockObject is globally available
synchronized(lockObject){
lockObject.someMutativeOperation(...);
}
乾杯
(できるだけ詳細に)知りたいのですが、オブジェクトをロックとして使用しているときにオブジェクトを変更するのはなぜ悪い習慣なのですか。
//Assuming the lockObject is globally available
synchronized(lockObject){
lockObject.someMutativeOperation(...);
}
乾杯
その主張を聞いたことがあるかどうかはわかりません。確かに、再割り当てするのは悪いことlockObject
ですが (別の場所で別のオブジェクトをロックすることになるため)、それを変更しても問題はないと思います。
synchronized
さらに、オブジェクトを変更するメソッドを持つことはかなり一般的です。
public synchronized void setSomething(int something) {
this.something = something;
}
この場合、オブジェクト自体がロックとして使用されます。別のオブジェクトで同期するポイントは何ですか?
それは悪い習慣ではなく、良い習慣です。他にどこで聞いた?
プリミティブ同期を使用している場合は、オブジェクト (または別のロック) を変更する前に同期します。
ただし、オブジェクトのスコープによって異なります。オブジェクトのスコープがクラスの外にある場合は、別の同期メカニズムを使用する必要があります
あなたが聞いたことは、参照を変更することだと思います。
synchronized (thing) {
...
thing = newThing;
...
}
This usually indicates an error. It should probably have locked using a reference that does not change. I think it was Bitter Java that had a bug of this nature in a read-write lock (there is has been a read-write lock in the Java library for five years, so the specific implementation is no longer necessary).