Page History

public  issue.


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

{code:bgColor=#ccccff}
AtomicIntegerArray aia = new AtomicIntegerArray(5);
// ...
aia.set(1, 10);
{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 properties;

  public Foo() {
    properties = new Properties();
    // ... loadLoad 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);
  }
}
{code}

This class permits a race condition. If one thread calls {{get()}} while another

public  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 effectively immutable. Consequently, once it is properly constructed, no thread can modify {{properties}} and cause a race condition.

{code:bgColor=#ccccff}
class Foo {
  private Properties properties;

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

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

The

 

{code:bgColor=#ccccff}
public class Foo {
  private volatile Properties properties;

  public Foo() {
    properties = new Properties();
    // ... loadLoad 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);
  }
}
{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

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

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