Page History

The synchronized keyword is used to acquire a mutual-exclusion lock; that is, a lock that cannot be acquired by any other thread while it is held by the executing thread. There are two ways to synchronize access to shared mutable variables: method synchronization and block synchronization.

Both methods Methods declared as synchronized and blocks that synchronize on the this reference both use the object’s monitor (intrinsic lock). An attacker can manipulate the system to trigger contention and deadlock by obtaining and indefinitely holding the intrinsic lock of an accessible class, consequently causing a denial of service.

One technique for preventing this vulnerability is the “private lock object” idiom \[[Bloch 2001|AA. Bibliography#Bloch 01]\]. This idiom uses the intrinsic lock associated with the instance of a {{private}} {{final}} {{java.lang.Object}} declared within the class in placeinstead of the intrinsic lock of the object itself. This idiom requires the use of synchronized blocks within the class’s methods rather than the use of synchronized methods. Lock contention between the class’s methods and those of a hostile class isbecomes impossible, because the hostile class cannot access the {{private}} {{final}} lock object.

Static methods and state also share this vulnerability. When a static method is declared synchronized, it acquires the intrinsic lock of the class object before any statements in its body are executed, and it releases the intrinsic lock when the method completes. Untrusted code that has access to an object of the class, or of a subclass, can use the getClass() method to gain access to the class object, and consequently to its manipulate the class object's intrinsic lock. Protect static data by locking on a private static final Object. Reducing the accessibility of the class to package-private adds further protection against untrusted callers.

The private lock object idiom is also suitable for classes that are designed for inheritance. When a superclass thread requests a lock on the object’s monitor, a subclass thread can interfere with its operation. For example, a subclass may use the superclass object’s intrinsic lock for performing unrelated operations, caus-ing significant causing lock contention and deadlock. Separating the locking strategy of the superclass from that of the subclass ensures that they do not share a common lock, and also permits fine-grained locking by supporting the use of multiple lock objects for unrelated operations. This increases the overall responsiveness of the application.

Objects that require synchronization must use the private lock object idiom rather than their own intrinsic lock in any case where untrusted code could:

• Subclass the class or its superclass. Note that trusted code is permitted to subclass the class.
• Create an object of the class, its superclass, or a subclass
• Access or acquire an object instance of the class, its superclass, or subclass

Subclasses whose parents use the private lock object idiom must themselves use the idiom. However, when a class uses intrinsic synchronization over the class object without documenting its locking policy, subclasses are forbidden to use intrinsic synchronization over their own class object, unless they explicitly document their locking policy. When the superclass documents its policy by stating that client-side locking is supported, the subclasses have the option to choose between intrinsic locking over the class object or use of the private lock object idiom. Subclasses must document their locking policy regardless of which locking option is chosen. See rule TSM00-J. Do not override thread-safe methods with methods that are not thread-safe for related information.

When any of the above restrictions is violated, the object’s intrinsic lock cannot be trusted. When the restrictions are obeyed, the private lock object idiom fails to add additional security. Consequently, objects that comply with all of the above restrictions are permitted to synchronize using their own intrinsic lock. However, block synchronization using the private lock object idiom is superior to method synchronization for methods that contain non-atomic operations that could either can use a more fine-grained locking scheme involving multiple private final lock objects or that lack a requirement for synchronization. Non-atomic operations can be decoupled from those that require synchronization and can be executed outside the synchronized block. Both for this reason and also for simplification of maintenance, block synchronization using the private lock object idiom is generally recommendedpreferred over intrinsic synchronization.

Noncompliant Code Example (Method Synchronization)

...

Any thread can modify the field’s value to refer to a different object in the presence of an accessor such as setLock(). That modification might cause two threads that intend to lock on the same object to lock on different objects, thereby enabling them to execute the two critical sections in an unsafe manner. For example, when one thread is in its critical section and the lock is changed, a second thread will lock on the new object instead of the old one.

A class that lacks accessible methods to change the lock is secure against untrusted manipulation. However, it remains susceptible to inadvertent modification by the programmer. For maintainability reasons, eliminating the accessor method (which is presumably needed for other reasons) is not the preferred solution.

Noncompliant Code Example (Public Final Lock Object)

...

Untrusted code that has the ability to create an instance of the class or has access to an already created instance can invoke the wait() method on the publicly accessible lock, causing the lock in the changeValue() method to be released immediately. Furthermore, if the method invokes lock.wait() from its body and does not test a condition predicate, it will be vulnerable to malicious notifications. (See rule THI03-J. Always invoke wait() and await() methods inside a loop for more information.)

This noncompliant code example also violates OBJ01-J. Declare data members as private and provide accessible wrapper methods.

Compliant Solution (Private Final Lock Object)

...

• It sufficiently documents that callers are forbidden to pass objects of this class to untrusted code.
• The class cannot invoke methods on objects of any untrusted classes that violate this guide-linerule, whether directly or indirectly.
• The synchronization policy of the class is documented properly.

...

...