| Wiki Markup |
|---|
...
Protecting the fields of a class is unnecessary when it is designed for single-threaded use. Such classes are required to document their lack of thread-safety. For instance, the documentation of class {{java.lang.StringBuilder}} states \[[API 06|AA. Java References#API 06]\] : |
...
{quote} This class is designed for use as a drop-in replacement for {{StringBuffer}} in places where the string buffer was being used by a single thread (as is generally the case). Where possible, it is recommended that this class be used in preference to {{StringBuffer}} as it will be faster under most implementations. |
...
{quote} Multithreaded clients of classes that are not thread-safe must |
...
protect any accesses if the documentation of the classes specify the lack of thread-safety, or fail to provide any conclusive information. |
...
Classes that use |
...
Noncompliant Code Example
This noncompliant code example does not synchronize access to the static field counter.
| Code Block | ||
|---|---|---|
| ||
{{static}} fields that are both publicly accessible and mutable must always protect accesses to their fields. This is because there is no guarantee that all clients will synchronize externally when accessing the field. Because a {{static}} field is shared by all clients, unrelated clients may violate the contract by not performing suitable locking. h2. Noncompliant Code Example This noncompliant code example does not synchronize access to the {{static}} field {{counter}}. {code:bgColor=#FFCCCC} /** This class is not thread-safe! */ public final class CountHits { private static int counter; public void incrementCounter() { counter++; } } } |
It relies on clients to externally synchronize the object and specifies its lack of thread-safety in the documentation. However, there is no guarantee that all unrelated (trusted or untrusted) clients will follow this advice.
Compliant Solution
This compliant solution internally synchronizes the counter field and consequently, does not depend on any external synchronization.
| Code Block | ||
|---|---|---|
| ||
{code} {mc} This class is not thread-safe because it violates [CON01-J. Ensure that compound operations on shared variables are atomic]. {mc} The class relies on clients to externally synchronize the object and specifies its lack of thread-safety in the documentation. This code is non-compliant, not because it violates [CON01-J. Ensure that compound operations on shared variables are atomic], and not because it documents its lack of thread-safety, but rather because it has an accessible mutable static field {{counter}}. Untrusted code is free to modify {{CountHits.counter}} with no respect for this class's lack of thread-safety. h2. Compliant Solution This compliant solution uses a static private final lock to protect the {{counter}} field and consequently, does not depend on any external synchronization. This is recommended by [CON04-J. Use private final lock objects to synchronize classes that may interact with untrusted code]. {code:bgColor=#ccccff} /** This class is thread-safe */ final class CountHits { private static int counter; private public synchronizedstatic final Object lock = new Object(); public void incrementCounter() { synchronized (lock) { counter++; } } } {code} h2. Risk Assessment |
...
Failing to |
...
protect classes containing accessible static members can result in unexpected results when a client fails to obey the classes' synchronization policy. |
...
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
CON32- J | low | probable | medium | P4 | L3 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
...
|| Rule || Severity || Likelihood || Remediation Cost || Priority || Level || | CON32- J | low | probable | medium | {color:green}{*}P4{*}{color} | {color:green}{*}L3{*}{color} | h3. Automated Detection TODO h3. Related Vulnerabilities Search for vulnerabilities resulting from the violation of this rule on the [CERT website|https://www.kb.cert.org/vulnotes/bymetric?searchview&query=FIELD+KEYWORDS+contains+CON32-J]. h2. References \[[API 06|AA. Java References#API 06]\] \[[Bloch 08|AA. Java References#Bloch 08]\] Item 67: "Avoid excessive synchronization" |
...
---- [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_left.png!|VOID CON06-J. Do not defer a thread that is holding a |
...
lock] [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_up.png!|11. Concurrency (CON)] [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_right.png!|CON08-J. Do not call alien methods that synchronize on the same objects as any callers in the execution chain]
|