CON11-J. Do not assume that elements of a volatile array or object are themselves volatile

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 effectively 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 change immediately. In other words, the new value is immediately visible. If the object is immutable, then this has the effect that other threads see a clear change in the object's state. However, if one thread modifies an object, then other threads may see a partially-modified object, or an object in a (temporarily) inconsistent state [[Goetz 07]]. volatile does not prevent this.

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 arrays or objects that are declared volatile. A thread may not observe a recent write to the array's element or object's field from another thread.

Noncompliant Code Example (Properties)

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

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 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 thread calls put(), then the first thread might receive a stale value, or an internally inconsistent value from the properties object. Being declared volatile does not

Even if the client thread sees the new reference to properties, the object state that it observes may change in the meantime. The Java Memory Model does not guarantee that the properties field will have been properly initialized when it is necessary. 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 effectively immutable. Consequently, once it is properly constructed, no thread can modify properties and cause a race condition.

public class Foo {
  private Properties properties;

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

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

The obvious drawback of this solution is that the put() method cannot be accommodated if the goal is to ensure immutability. The Foo and Properties classes are both effectively immutable. They are not truly immutable because the Properties class is not 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.

Noncompliant Code Example (Arrays)

This noncompliant code example shows an array 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 arr1 while another thread attempts to read the value of arr1, with the result that the reading thread receives an inconsistent value for arr1.

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);

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]]

FIO36-J. Do not create multiple buffered wrappers on an InputStream      09. Input Output (FIO)      09. Input Output (FIO)