Page History

The synchronized keyword is used to acquire a mutual-exclusion lock – 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. Methods declared as synchronized and blocks that synchronize on the this reference both use the object’s monitor (that is, its 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 (DoS).

...

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. Note that trusted code is permitted to subclass the class.
• Create an object of the class or of a subclass.
• Access or acquire an object instance of the class or of a subclass.

Subclasses whose parents superclasses use the private lock object idiom must themselves use the idiom. However, when a class uses intrinsic synchronization on the class object without documenting its locking policy, subclasses must not use intrinsic synchronization on their own class object. When the superclass documents its policy by stating that client-side locking is supported, the subclasses have the option to choose between intrinsic locking and using 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 preceding these restrictions are violated, the object’s intrinsic lock cannot be trusted. But when these restrictions are obeyed, the private lock object idiom fails to add any additional security. Consequently, objects that comply with all of the 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 nonatomic operations that could either use a more fine-grained locking scheme involving multiple private final lock objects or that lack a requirement for synchronization. Nonatomic operations can be decoupled from those that require synchronization and can be executed outside the synchronized block. Both for this reason and for simplification of maintenance, block synchronization using the private lock object idiom is generally preferred over intrinsic synchronization.

...

This noncompliant code example synchronizes on a private publicly accessible but nonfinal field. The lock field is declared volatile so that changes are visible to other threads.

public class SomeObject {
  private volatile Object lock = new Object();

  public void changeValue() {
    synchronized (lock) {
      // ...
    }
  }

  public void setLock(Object lockValue) {
    lock = lockValue;
  }
}

...

A compliant solution must also comply with rule LCK05-J. Synchronize access to static fields that can be modified by untrusted code. However, in
In the untrusted code, the attacker intentionally violates rule LCK09-J. Do not perform operations that can block while holding a lock.

...

Exposing the lock object to untrusted code can result in denial of service ( DoS).

...

...