CON11-J. Do not assume that declaring an object volatile guarantees visibility of its members

According to the Java Language Specification [[JLS 05]], section, 8.3.1.4 volatile Fields:

A field may be declared volatile, in which case the Java memory model (§17) ensures that all threads see a consistent value for the variable.

Notably, this applies only to fields and not to the contents of objects that are declared volatile. A thread may not observe a recent write to the object's field from another thread.

Declaring an object volatile in order to ensure visibility of the most up-to-date object state does not work without the use of explicit synchronization, unless the object is [immutable].

In the absence of synchronization, the effect of declaring an object reference volatile is that when one thread sets the object to a new value, other threads can see the new reference immediately. If the object is immutable, this has the effect that other threads also see a consistent view of the state of the object. However, if the object is mutable and so, modified by a thread, other threads may see a partially-modified object, or an object in a (temporarily) inconsistent state [[Goetz 07]]. Declaring the object volatile does not prevent this issue.

Technically the object does not have to be strictly immutable. If the object is not immutable, you must guarantee that it is effectively immutable which being shared. That is, no threads modify the object while it is shared, even if they have the capability. Furthermore, no untrusted code has access to the object; as hostile code could modify the object if it is capable of doing so.

Noncompliant Code Example (Arrays)

This noncompliant code example shows an array object (arrays are objects in Java) that is declared volatile. It appears that when, a value is written by a thread to one of the array elements, it will be visible to other threads immediately. This is misleading because the volatile keyword just makes the array reference visible to all threads and does not affect the actual data contained within the array.

volatile int[] arr = new int[20];
// ...
arr[1] = 10;

It is possible for one thread to set a new value to arr[1] while another thread attempts to read the value of arr[1], with the result that the reading thread receives an inconsistent value for arr[1].

Compliant Solution (AtomicIntegerArray)

This compliant solution suggests using the java.util.concurrent.atomic.AtomicIntegerArray concurrency utility. Using its set(index, value) method ensures that the write is atomic and the resulting value is immediately visible to other threads. The other threads can retrieve a value from a specific index by using the get(index) method.

AtomicIntegerArray aia = new AtomicIntegerArray(5);
// ...
aia.set(1, 10);

Noncompliant Code Example (Properties object)

This noncompliant code example declares an instance field of type Properties as volatile. The field can be mutated using the put() method.

class Foo {
  private volatile Properties properties;

  public Foo() {
    properties = new Properties();
    // Load some useful values into properties
  }

  public String get(String s) {
    return properties.getProperty(s);
  }

  public void put(String key, String value) {
    // Perform validation of value
    properties.setProperty(key, value);
  }
}

This class permits a race condition. If one thread calls get() while another calls put(), the first thread may receive a stale value, or an internally inconsistent value from the properties object. Declaring the object volatile does not prevent this data race.

Even if the client thread sees the new reference to properties, the object state that it observes may change in the meantime.

Because the object is not immutable, it is unsafe for use in a multi-threaded environment.

Compliant Solution (immutable)

This compliant solution renders the Foo class immutable. Consequently, once it is properly constructed, no thread can modify properties and cause a race condition.

class Foo {
  private final Properties properties;

  public Foo() {
    properties = new Properties();
    // Load some useful values into properties
  }

  public String get(String s) {
    return properties.getProperty(s);
  }
}

The drawback of this solution is that the put() method cannot be accommodated if the goal is to ensure immutability. The Foo class is [immutable] because all of its fields are final.

Compliant Solution (the cheap read-write lock trick)

This compliant solution uses explicit synchronization to ensure thread safety. It declares the object volatile to guard retrievals that use the getter method. A synchronized setter method is used to set the value of the Properties object.

public class Foo {
  private volatile Properties properties;

  public Foo() {
    properties = new Properties();
    // Load some useful values into properties
  }

  public String get(String s) {
    return properties.getProperty(s);
  }

  public synchronized void put(String key, String value) {
    // Perform validation of value
    properties.setProperty(key, value);
  }
}

This compliant solution has the advantage that it can accommodate the setter method. Declaring the object as volatile for safe publication using getter methods is cheaper in terms of performance, than declaring the getters as synchronized. However, synchronizing the setter methods is mandatory.

Risk Assessment

Failing to synchronize access to shared mutable data can cause different threads to observe different states of the object.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[Goetz 07]] Pattern #2: "one-time safe publication"
[[JLS 05]]

[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_left.png!]      [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_up.png!]      [!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_right.png!]