Page History

Overriding thread-safe methods with methods that are unsafe for concurrent use can result in improper synchronization , when a client that depends on the thread-safety promised by the parent inadvertently operates on an instance of the subclass. For example, an overridden synchronized method's contract can be violated when a subclass provides an implementation that is unsafe for concurrent use. Such overridings overriding can easily result in errors that are difficult to diagnose. Consequently, programs in general should — and security-critical programs must — never must not override thread-safe methods with methods that are unsafe for concurrent use.

...

This compliant solution also complies with rule LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code because the accessibility of the class is package-private. That type of Package-private accessibility is permitted when untrusted code cannot infiltrate the package.

...

This is an acceptable solution, provided that the locking policy of the Derived class is consistent with that of the Base class.

...

This noncompliant code example defines a doSomething() method in the Base class that uses a private final lock , in accordance with rule LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code.

...

This compliant solution synchronizes the doSomething() method of the subclass using a its own private final lock object.

...

Note that the Base and Derived objects maintain distinct locks that are inaccessible from each othersother's classes. Consequently, Derived can provide thread-safety guarantees independent of Base.

...

...