...
| Wiki Markup |
|---|
This vulnerability can be prevented using a {{java.lang.Object}} declared {{private}} and {{final}} within the class. The object must be used explicitly for locking purposes in synchronized blocks within the classâs methods. This intrinsic lock is associated with the instance of the private object and not the class. Consequently, there is no lock contention between this classâs methods and the methods of a hostile class. Bloch refers to this technique as the âprivate lock objectâ idiom \[[Bloch 2001|AA. Java References#BlochBibliography#Bloch 01]\]. |
Static state has the same potential problem. If a static method is declared synchronized, the intrinsic lock of the class object is acquired before any statements in its body are executed, and the lock is released when the method completes. Any untrusted code that can access an object of the class, or a subclass, can use the getClass() method to gain access to the class lock. Static data can be protected by locking on a private static final Object. Reducing the accessibility of the class to package-private adds further protection against untrusted callers.
...
| Wiki Markup |
|---|
\[[Bloch 2001|AA. Java References#BlochBibliography#Bloch 01]\] Item 52: "Document Thread Safety" |
...