...
| Wiki Markup |
|---|
The _private lock object_ idiom can be used to prevent this vulnerability. The idiom consists of a {{private}} object declared as an instance field. The {{private}} object must be explicitly used for locking purposes in {{synchronized}} blocks, within the class's methods. This lock object belongs to an instance of the internal private object and is not associated with the class itself. Consequently, there is no lock contention between athis class's methodmethods and a methodmethods of a hostile class when both try to lock on the object. \[[Bloch 01|AA. Java References#Bloch 01]\] |
The idiom can also be extended to protect static state by declaring the lock as private, static and final. Furthermore, it can also be suitably used by classes designed for inheritance. If a superclass thread requests a lock on the object's monitor, a subclass thread can interfere with its operation. This idiom separates the locking strategy of the superclass from that of the subclass. This idiom It also permits fine grained locking as opposed to coarse grained because multiple lock objects canthen can then be used for seemingly unrelated operations. This increase increases overall responsiveness of the application.
...
If a superclass uses an internal private lock to synchronize shared data, subclasses must also use an internal private lock. However, if it uses intrinsic synchronization over the class object without documenting this policy, subclasses may not use intrinsic synchronization over their own class object, unless they explicitly document this locking policy.
...