Page History

...

If a class uses a private final lock to synchronize shared data, subclasses must also use a private final lock. However, if a class uses intrinsic synchronization over the class object without documenting its locking policy, subclasses may not use intrinsic synchronization over their own class object, unless they explicitly document their locking policy. If the superclass documents its policy by stating that client-side locking is supported, the subclasses have the option of choosing between intrinsic locking over the class object and a private lock. Regardless of which is chosen, subclasses must document their locking policy. See guideline rule TSM00-J. Do not override thread-safe methods with methods that are not thread-safe for related information.

...

The untrusted code attempts to acquire a lock on the object’s monitor and, upon succeeding, introduces an indefinite delay that prevents the synchronized changeValue() method from acquiring the same lock. Note that in the untrusted code, the attacker intentionally violates guideline rule LCK09-J. Do not perform operations that can block while holding a lock.

...

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 guideline rule THI03-J. Always invoke wait() and await() methods inside a loop for more information.)

...

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

...

LCK00-EX1: A class may violate this guidelinerule, if all the following conditions are met:

...

A client may use a class that violates this guidelinerule, if all the following conditions are met:

• The class does not pass objects of this class to untrusted code.
• The class does not use any untrusted classes that violate this guideline rule directly or indirectly.

LCK00-EX2: If a superclass of the class documents that it supports client-side locking and synchronizes on its class object, the class can support client-side locking in the same way and document this policy.

LCK00-EX3: A package-private class may violate this guideline rule because its accessibility protects against untrusted callers. However, this condition should be documented explicitly so that trusted code within the same package does not reuse or change the lock object inadvertently.

...

Exposing the class object to untrusted code can result in denial of service.

...