...
This compliant solution locks on a ( non-boxed ) Integer. Integer.
Code Block | ||
---|---|---|
| ||
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 | ||
---|---|---|
| ||
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 | ||
---|---|---|
| ||
// 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 thisString
object as determined by theequals(Object)
method, then the string from the pool is returned. Otherwise, thisString
object is added to the pool and a reference to thisString
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 | ||
---|---|---|
| ||
// 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 | ||
---|---|---|
| ||
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)
...