...
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 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 object. The private final lock object idiom can be used to protect static data by declaring the lock as private, static and final. Reducing the accessibility of the class to package-private may offer some protection from untrusted callers when using strategies other than internal lockingadds further protection against untrusted callers.
This idiom is also suitable for classes designed for inheritance. If 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, causing significant lock contention. Also, excessive use of the same lock frequently results in deadlocks. This idiom separates the locking strategy of the superclass from that of the subclass. It also permits fine-grained locking because multiple lock objects can be used for seemingly unrelated operations. This increases the overall responsiveness of the application.
...
However, it is possible for untrusted code to change the value of the lock object and disrupt proper synchronization.
Noncompliant Code Example (publicly-accessible non-final lock object)
This noncompliant code example synchronizes on a private but non-final field.
...
Any thread can modify the field's value to refer to some other object in the presence of an accessor such as setLock(). This might cause two threads that intend to lock on the same object to lock on different objects, enabling them to execute the two critical sections in an unsafe manner. For example, if one thread is in its critical section and the lock is changed, a second thread will lock on the new reference instead of the old one.
A class that provides no accessible methods to change the lock is secure against untrusted manipulation, however, it is not secure against inadvertent manipulation from within the class. Consequently, this solution is not recommended for maintainability reasons.
Compliant Solution (private final lock object)
...
EX2: If a superclass of the class documents that it supports client-side locking and synchronizes on its class object, the class should also support client-side locking in the same way and document this policy. If instead the superclass uses an internal private lock, the derived class should document its own locking policy.
EX3: A package-private class may violate this guideline because its accessibility protects against untrusted callers, however, this condition should be explicitly documented so that trusted code within the same package does not reuse or change the lock object inadvertently.
Risk Assessment
Exposing the class object to untrusted code can result in denial-of-service.
...