Page History

final class Foo {
  private  {{volatile}} Fields:
{quote}
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.
{quote}

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|BB. Definitions#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|AA. Java References#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.


h2. 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. 

{code:bgColor=#FFcccc}
volatile int[] arr = new int[20];
// ...
arr[1] = 10;
{code}

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\]}}.


h2. Compliant Solution ({{AtomicIntegerArray}})

This compliant solution suggests using the {{ public int getFirst() {
    return arr[0];
  }

  public void setFirst(int n) {
    arr[0] = n;
  }

  // ...
}

final class Foo {
  private final AtomicIntegerArray atomicArray = 
    new AtomicIntegerArray(20);

  public int getFirst() {
    return atomicArray.get(0);
  }

  public void setFirst(int n) {
    atomicArray.set(0, 10);
  }

  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.

{code:bgColor=#ccccff}
AtomicIntegerArray aia = new AtomicIntegerArray(5);
// ...
aia.set(1, 10);
{code}

h2. Compliant Solution (synchronization)

To ensure visibility, accessor methods may synchronize access while performing operations on nonvolatile elements of an array declared {{volatile}}.
}

final class Foo {
  private

{code:bgColor=#ccccff}
volatile int[] arr = new int[20];
// ...
synchronized(lock
  public synchronized int getFirst() {
    return arr[10] =;
 10; 
}

  public synchronized void setFirst(int n) {
    arr[0] = n;
  }
}

final {code}

h2. 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.

{code:bgColor=#FFcccc}
class Foo {
  private volatile Properties propertiesMap<String, String> map;
 
  public Foo() {
    propertiesmap = new PropertiesHashMap<String, String>();
    // Load some useful values into propertiesmap
  }
 
  public String get(String s) {
    return propertiesmap.getPropertyget(s);
  }
 
  public void put(String key, String value) {
    // Validate Performthe validationvalues ofbefore valueinserting
    if properties(!value.setProperty(key, value);
  }
}
{code}

matches("[\\w]*")) {
      throw new IllegalArgumentException();
    }
    map.put(key, value);
  }
}

final 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. {mc} The Java Memory Model does not guarantee that the {{properties}} field will have been properly initialized when it is necessary. ==Let's not talk about initialization here=={mc} Because the object is not immutable, it is unsafe for use in a multi-threaded environment.

h2. 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.

{code:bgColor=#ccccff}
class Foo {
  private volatile finalMap<String, PropertiesString> propertiesmap;

  public Foo() {
    propertiesmap = new HashMap<String, PropertiesString>();
    // Load some useful values into propertiesmap
  }

  public String get(String s) {
    return propertiesmap.getPropertyget(s);
  }
}
{code}

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|BB. Definitions#immutable] because all of its fields are {{final}}.


h2. 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. 

{code:bgColor=#ccccff}
public  public synchronized void put(String key, String value) {
    // Validate the values before inserting
    if (!value.matches("[\\w]*")) {
      throw new IllegalArgumentException();
    }
    map.put(key, value);
  }
}

final class Foo {
  private final volatileMap<String, PropertiesString> propertiesmap;

  public Foo() {
    propertiesmap = new HashMap<String, PropertiesString>();
    // Load some useful values into propertiesmap
  }

  public synchronized String get(String s) {
    return propertiesmap.getPropertyget(s);
  }

  public synchronized void put(String key, String value) {
    // Perform validation of value Validate the values before inserting
    if (!value.matches("[\\w]*")) {
      throw new IllegalArgumentException();
    }
    propertiesmap.setPropertyput(key, value);
  }
}
{code}

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. 


h2. Risk Assessment

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

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

h3. Automated Detection

TODO

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

h2. References

\[[Goetz 07|AA. Java References#Goetz 07]\] Pattern #2: "one-time safe publication"
\[[JLS 05|AA. Java References#JLS 05]\]

----
[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_left.png!|FIO36-J. Do not create multiple buffered wrappers on an InputStream]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_up.png!|09. Input Output (FIO)]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_right.png!|09. Input Output (FIO)]

final class DateHandler {
  private static volatile DateFormat format =
    DateFormat.getDateInstance(DateFormat.MEDIUM);

  public static java.util.Date parse(String str) 
      throws ParseException {
    return format.parse(str);
  }
}

final class DateHandler {
  public static java.util.Date parse(String str) 
      throws ParseException {
    return DateFormat.getDateInstance(
      DateFormat.MEDIUM).parse(str);
  }
}

final class DateHandler {
  private static DateFormat format =
    DateFormat.getDateInstance(DateFormat.MEDIUM);

  public static java.util.Date parse(String str) 
      throws ParseException {
    synchronized (format) {
      return format.parse(str);
    }
  }
}

final class DateHandler {
  private static final ThreadLocal<DateFormat> format = 
    new ThreadLocal<DateFormat>() {
    @Override protected DateFormat initialValue() {
      return DateFormat.getDateInstance(DateFormat.MEDIUM);
    }
  };
  // ...
}