Page History

{color:

red

}we need a more precise statement about what specifically this guideline

{code}

The {{initialized}} variable can only assume the values {{true}} and {{false}}. Consequently, any other code that synchronizes on a {{Boolean}} variable with the same value, may induce unresponsiveness and deadlocks \[[Findbugs 08|AA. Java References#Findbugs 08]\]. 

{color:

red

}Not sure I completely understand this.  Is the problem that there are only two actual objects that allocated so that if two different threads syncrhronize on thesse objects they'll stomp on each other?

 


h2. Compliant Solution (Integer)

This compliant solution recommends locking on a non-boxed Integer. The {{doSomething()}} method synchronizes using the intrinsic lock of the {{Integer}} instance, {{Lock}}.

{code

:bgColor

=#ccccff

}
int lock = 0;
private final Integer Lock = new Integer(lock); 

public void doSomething() {
  synchronized(Lock) { 
    // ...
  }
}
{code}

When explicitly constructed, an {{Integer}} object has a unique reference and its own intrinsic lock that is not shared with other {{Integer}} objects or boxed integers having the same value. While this is an acceptable solution, it may cause maintenance problems.

{code} 

For more information on using an {{Object}} as a lock, see [CON04-J. Synchronize using an internal private final lock object].

h2.

 Noncompliant Code Example (interned {{String}} object)

This noncompliant code example locks on an interned {{String}} object.

{code

:bgColor

=#FFcccc

}
private final String _lock = new String("LOCK").intern();

public void doSomething() {
  synchronized(_lock) {
    // ...
  }
}
{code}

  

According to the Java API \[[API 06|AA. Java References#API 06]\], class {{java.lang.String}} documentation:

{quote}
When the {{intern()}} method is invoked, if the pool already contains a string equal to this {{String}} object as determined by the {{equals(Object)}} method, then the string from the pool is returned. Otherwise, this {{String}} object is added to the pool and a reference to this {{String}} object is returned.

 
{quote}

Consequently, an interned {{String}} object behaves like a global variable in the Java Virtual Machine (JVM). As demonstrated in this noncompliant code example, even if every instance of an object maintains its own

{code}

Section 4.3.2 "The Class Object" of the Java Language specification \[[JLS 05|AA. Java References#JLS 05]\] describes how method synchronization works:

].


h2. Compliant Solution ({{Class.forName()}})

This compliant solution uses the {{Class.forName()}} method to synchronize on the superclass's {{Class}} object.

{code

:bgColor

=#ccccff

}
public void doSomething() {
  synchronized(Class.forName("SuperclassName")) { 
    // ... 
  }
}
{code}

The class object that is being used for synchronization should not be accessible to hostile code, as discussed in the previous compliant solution. Furthermore, care must be taken to ensure that untrusted inputs are not accepted as arguments while loading classes using {{Class.forname()}}. (See [SEC05-J. Do not expose standard APIs that use the immediate caller's class loader instance to untrusted code] for more information.)

h2. Noncompliant Code Example ({{ReentrantLock}} lock object)

This noncompliant code example incorrectly uses a {{ReentrantLock}} as the lock object.

{code

:bgColor

=#FFcccc

}
private final Lock lock = new ReentrantLock();

public void doSomething() {
  synchronized(lock) {
    // ... 
  }
}
{code}

Similarly, it is inappropriate to lock on an object of a class that implements either the {{Lock}} or {{Condition}} interface (or both) of package {{java.util.concurrent.locks}}. Using intrinsic locks of these classes is a questionable practice even though the code may appear to function correctly. This problem usually comes up in practice when refactoring from intrinsic locking to the {{java.util.concurrent}} dynamic locking utilities.

h2. Compliant Solution ({{lock()}} and {{unlock()}})

Instead of using the intrinsic locks of objects that implement the {{Lock}} interface, such as {{ReentrantLock}}, use the {{lock()}} and {{unlock()}} methods provided by the {{Lock}} interface.

{code

:bgColor

=#ccccff

}
private final Lock lock = new ReentrantLock();

public void doSomething() {
  lock.lock();
  try {
    // ...
  } finally {
    lock.unlock();
  }
}
{code}

If there is no requirement of using the advanced functionality of the dynamic locking utilities of package {{java.util.concurrent}}, prefer using the {{Executor}} framework or other concurrency primitives such as synchronization and atomic classes.

h2.

 Noncompliant Code Example (collection view)

This noncompliant code example synchronizes on the view of a synchronized map.

{code

:bgColor

=#FFcccc

}
// map has package-private accessibility
final Map<Integer, String> map = Collections.synchronizedMap(new HashMap<Integer, String>());
private final Set<Integer> set = map.keySet();

public void doSomething() {
  synchronized(set) {  // Incorrectly synchronizes on set
    for(Integer k : set) { 
      // ...
    }
   }
}
{code}

When using synchronization wrappers, the synchronization object should be the {{Collection}} object. The synchronization is necessary to enforce atomicity ([CON07-J. Do not assume that a grouping of calls to independently atomic methods is atomic]). This noncompliant code example demonstrates inappropriate synchronization resulting from locking on a Collection view instead of the Collection object itself \[[Tutorials 08|AA. Java References#Tutorials 08]\]. 

The {{java.util.Collections}} interface's documentation \[[API 06|AA. Java References#API 06]\] warns about the consequences of following this practice:

{quote}
It is imperative that the user manually synchronize on the returned map when iterating over any of its collection views...  Failure to follow this advice may result in non-deterministic behavior

{code}


h2. Risk Assessment

Synchronizing on an inappropriate object can provide a false sense of thread safety and result in non-deterministic behavior. 

|| Rule || Severity || Likelihood || Remediation Cost || Priority || Level ||
| CON02- J | medium | probable | medium | {color:#cc9900}{*}P8{*}{color} | {color:#cc9900}{*}L2{*}{color} |



h3. Automated Detection



The following table summarizes the examples flagged as violations by FindBugs: 

||Noncompliant Code Example||Flagged||Checker||Message||
|{{Boolean}} lock object|Yes|DL_SYNCHRONIZATION_ON_BOOLEAN

|Synchronization on Boolean could deadlock

|
|Boxed primitive

|Yes

|DL_SYNCHRONIZATION_ON_BOXED_PRIMITIVE

|Synchronization on Integer could deadlock

|
|interned {{String}} object|No|DL_SYNCHRONIZATION_ON_SHARED_CONSTANT

|n/a

|
|String literal

|Yes

||Synchronization on interned String could deadlock

|
|{{getClass()}} lock object

|No

|WL_USING_GETCLASS_RATHER_THAN_CLASS_LITERAL

|n/a

|
|{{ReentrantLock}} lock object|No||n/a

|
|Collection view

|No

|n/a

|

The following table summarizes the examples flagged as violations by [SureLogic Flashlight

|http://www.surelogic.com/]: 

||Noncompliant Code Example||Flagged||Message||
|{{Boolean}} lock object|No|No obvious issues|
|Boxed primitive|No|No obvious issues|
|interned {{String}} object|No|No obvious issues|
|String literal|No||No data available about field accesses|
|{{getClass()}} lock object|No|No data available about field accesses|
|{{ReentrantLock}} lock object|No|No obvious issues|
|Collection view|No|No obvious issues|



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+CON36-J].

h2. References

\[[API 06|AA. Java References#API 06]\] Class String, Collections
\[[Pugh 08|AA. Java References#Pugh 08]\] "Synchronization"
\[[Miller 09|AA. Java References#Miller 09]\] Locking
\[[Tutorials 08|AA. Java References#Tutorials 08]\] [Wrapper Implementations|http://java.sun.com/docs/books/tutorial/collections

/implementations/wrapper.html]

----
[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_left.png!|VOID CON00-J. Synchronize access to

 shared mutable variables]      [!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!|CON03-J. Do not use background threads during class initialization]