Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: raw Object is the standard way to do this; everything else would cause maintainability problems/more confusion. I added another NCE with interned String objects. Some other edits too.

...

This compliant solution locks on a ( non-boxed ) Integer. Integer.

Code Block
bgColor#ccccff

int lock = 0;
private final Integer Lock = new Integer(lock);
synchronized(Lock) { /* ... */ }

When explicitly constructed, an Integer object has a unique reference and its own intrinsic lock , that is not shared by other Integer objects or boxed integers , autoboxed or nothaving the same value. While this is an acceptable solution, it may cause maintenance problems. It is always better to synchronize on a private final raw Object as described next.

Compliant Solution (private internal raw Object)

This compliant solution uses an internal private lock object. This is one of the few cases where a raw Object is useful.

Code Block
bgColor#ccccff
int lock = 0;
private final IntegerObject Locklock = new IntegerObject( lock);

synchronized(Locklock) { 
//* ... */ 
}

Noncompliant Code Example (interned String

...

object)

This noncompliant code example locks on a final an interned String literal object.

Code Block
bgColor#FFcccc
// This bug was found in jetty-6.1.3 BoundedThreadPool
private final String _lock = new String("LOCK").intern();
synchronized(_lock) { /* ... */ }

Wiki Markup
A {{String}} literal is a constant and is interned. According to the Java API \[[API 06|AA. Java References#API 06]\], class {{String}} documentation:

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.

Consequently, a an interned String constant object behaves like a global variable in the JVM. As demonstrated in this noncompliant code example, even if every instance of an object maintains its own field lock, the field points to a common String constant in the JVM. Trusted code that locks on the same String constant renders all synchronization attempts inadequate. Likewise, hostile code from any other package can exploit this vulnerability.

...

Noncompliant Code Example (

...

String literal)

This compliant solution noncompliant code example locks on a final String literal.

Code Block
bgColor#FFcccc

// This bug was found in jetty-6.1.3 BoundedThreadPool
private final String _lock = "LOCK";
synchronized(_lock) { /* ... */ }

A String literal is a constant and is interned. Consequently, it suffers from the same pitfalls as the preceding noncompliant code example.

Compliant Solution (String instance)

This compliant solution locks on a String instance that is not interned explicitly constructed. This String object has a unique reference and its own intrinsic lock, not shared by other strings.

Code Block
bgColor#ccccff
private final String _lock = new String("LOCK");
synchronized(_lock) { /* ... */ }

A String instance differs from a String literal. The instance has a unique reference and its own intrinsic lock, not shared by other string objects or literals. A more suitable approach is to use the private final internal raw Object discussed earlier.

Noncompliant Code Example (getClass() lock object)

...