The synchronized keyword is used to acquire a mutual-exclusion lock so that no other thread can acquire the lock, while it is being held by the executing thread. Recall that there are two ways to synchronize access to shared mutable variables, method synchronization and block synchronization.
The A method declared synchronized keyword always uses the object's monitor (intrinsic 'monitor' locklock) and so does code that synchronizes on the this reference using a synchronized block. This lock is available to any code that the object itself is available to; consequently, any code can lock on the object, and potentially cause a denial of service (DoS). Excessive synchronization can induce a DoS vulnerability because another class whose member locks on the object, can fail to release the lock promptly. However, this requires the victim class to be accessible from the hostile class.
| 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 object and is not associated with the class itself. Consequently, there is no lock contention between a class method and a method of a hostile class when both try to lock on the object. \[[Bloch 01|AA. Java References#Bloch 01]\] |
This idiom 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 also permits fine grained locking as opposed to coarse grained because multiple lock objects canthen be used for seemingly unrelated operations. This increase overall responsiveness of the application.
An object should use a private internal final lock object rather than its own intrinsic lock unless the class can guarantee that untrusted code may notcannot:
- Subclass the class (However, trusted code may is allowed to subclass the class.)
- Create an object of the class (or its superclass, or a subclass)
- Access or acquire an object of the class (or a its superclass, or subclass)
Furthermore, it is highly recommended that the class
...
's superclasses do not use any synchronization
...
if the private lock object idiom is not being used. If a superclass synchronizes on its this reference, the subclass should typically synchronize on that same reference instead of synchronizing on its own this reference. On the other hand, if the superclass uses some other locking strategy, such as an internal private lock, it is still inappropriate for the subclass to synchronize on its this reference. Sometimes the subclass must use a different lock than the superclass and in these cases, separate internal private locks are the obvious choice for both classes.
Similarly, if a static method is declared synchronized
If these restrictions are not met, the object's intrinsic lock is not trustworthy. If all conditions are satisfied, then the object gains no significant security from using a private internal lock object, and may synchronize using its own intrinsic lock.
Likewise, if a static method has the synchronized keyword, the intrinsic lock of the Class object is obtained, and released when the method completes. The same restrictions listed above apply to static methods because any untrusted code that can access an object of the class, or a subclass, can use the getClass() method to obtain access to the Class object. Furthermore, hostile code must not be able to access the Class object. This may be accomplished, for instance, by making the class package-private. Reducing the accessibility of the class to package-private may provide some reprieve when using strategies other than internal locking.
If these restrictions are not met, the object's intrinsic lock is not trustworthy. If all conditions are satisfied, then the object gains no significant security from using a private internal lock object, and may synchronize using its own intrinsic lock.
Noncompliant Code Example (method synchronization)
...