Overriding thread-safe methods with methods that are not thread-safe unsafe for concurrent use can result in improper synchronization, if the client when a client that depends on the thread-safety promised by the parent inadvertently operates on an instance of the subclass. An For example, an overridden synchronized method's contract can be violated , if when a subclass provides an implementation that is not safe unsafe for concurrent use. Overriding thread-safe methods with methods that are not thread-safe is not, in itself, an error. However, it is disallowed by this rule, because it may Such overridings can easily result in errors that are difficult to diagnose. Consequently, programs in general should (and security-critical programs must) never override thread-safe methods with methods that are unsafe for concurrent use.
The locking strategy of classes designed for inheritance should always be documented. This information can subsequently be used to determine an appropriate locking strategy for subclasses (see rule LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code).
...
This programming error can be difficult to diagnose, because threads that accept instances of Base can also accept instances of its subclasses. Consequently, clients could be unaware that they are operating on an instance of the subclass of a thread-safe class that is not fails to be thread-safe.
Compliant Solution (Synchronized Method)
...
| Code Block | ||
|---|---|---|
| ||
class Base {
public synchronized void doSomething() {
// ...
}
}
class Derived extends Base {
@Override public synchronized void doSomething() {
// ...
}
}
|
This compliant solution does not violate 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 accessibility is allowable permitted when untrusted code cannot infiltrate the package.
...
This is an acceptable solution, provided that the locking policy of the Derived class has a consistent locking policyis consistent with that of the Base class.
Noncompliant Code Example (Private Lock)
...
Overriding thread-safe methods with methods that are not thread-safe unsafe for concurrent access can result in unexpected behavior.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
TSM00-J | low | probable | medium | P4 | L3 |
Automated Detection
...
Related Vulnerabilities
Any vulnerabilities resulting from the violation of this rule are listed on the CERT website.
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="12ac738ece497c41-b23e7812-46cc449e-8408b3c8-9ffb280810bb05ca7df3d6d5"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API 06]] |
| ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="305b6389c4e51495-865841a7-47e345e1-98fd9df5-78348afdaeb5a09cff7fc289"><ac:plain-text-body><![CDATA[ | [[SDN 2008 | AA. Bibliography#SDN 08]] | Sun bug database, [Bug ID 4294756 | http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4294756] | ]]></ac:plain-text-body></ac:structured-macro> |
...