Page History

 conditions.

Given an invariant involving multiple objects, a programmer may incorrectly assume that individually atomic operations require no additional locking; however, this is not the case.  Similarly, programmers may incorrectly assume that using a thread-safe {{Collection}} does not require explicit synchronization to preserve an invariant that involves the collection's elements. A thread-safe class can only guarantee atomicity of its individual methods. A grouping of calls to such methods requires additional synchronization.

Consider, for example, a scenario where the standard thread-safe API does not provide a single method to both find a particular person's record in a {{Hashtable}} and update the corresponding payroll information. In such cases, the two method invocations must be performed atomically. 

Enumerations and iterators also require explicit synchronization on the collection object (client-side locking) or a private final lock object. 

Compound operations on shared variables are also non-atomic. See [CON01-J. Ensure that compound operations on shared variables are atomic] for more information.

[CON30-J. Do not use method chaining implementations in a multi-threaded environment] describes a specialized case of this guideline.

h2. Noncompliant Code Example ({{AtomicReference}})

This noncompliant code example wraps {{BigInteger}} objects within thread-safe {{AtomicReference}} objects. 

{code:bgColor=#FFcccc}
final class Adder {
  private final AtomicReference<BigInteger> first;	
  private final AtomicReference<BigInteger> second; 

  public Adder(BigInteger f, BigInteger s) {
    first  = new AtomicReference<BigInteger>(f);
    second = new AtomicReference<BigInteger>(s);
  }

  public void update(BigInteger f, BigInteger s) { // Unsafe
    first.set(f);
    second.set(s);
  }

  public BigInteger add() { // Unsafe
    return first.get().add(second.get()); 
  }
}
{code}

An {{AtomicReference}} is an object reference that can be updated atomically. However, operations combining {mc} "that combine"? {mc} more than one atomic reference are not atomic. In this noncompliant code example, one thread may call {{update()}} while a second thread may call {{add()}}. This might cause the {{add()}} method to add the new value of {{first}} to the old value of {{second}}, yielding an erroneous result.


h2. Compliant Solution (method synchronization)

This compliant solution declares the {{update()}} and {{add()}} methods as {{synchronized}} to guarantee atomicity. 

{code:bgColor=#ccccff}

final class Adder {
  // ...
  private final AtomicReference<BigInteger> first;
   public synchronized void updateprivate final AtomicReference<BigInteger> second;

  public Adder(BigInteger f, BigInteger s) {
    first.set  = new AtomicReference<BigInteger>(f);
    second.set = new AtomicReference<BigInteger>(s);
  }



  public synchronized void update(BigInteger f, BigInteger s){
    first.set(f);
    second.set(s);
  }

  public synchronized BigInteger add() {
    return first.get().add(second.get()); 
  }
}
{code}


h2. Noncompliant Code Example ({{synchronizedList}})

This noncompliant code example uses a {{

}}.  An array is used to iterate over {{Arraylist}} instead of an iterator to avoid a {{ConcurrentModificationException}}. 

{code:bgColor=#FFCCCC}
final class IPHolder {
  private final List<InetAddress> ips = 
      Collections.synchronizedList(new ArrayList<InetAddress>());
  
  public void addIPAddressaddAndPrintIPAddresses(InetAddress address) {
    ips.add(address);
  }
  
InetAddress[] addressCopy public void addAndPrintIPAddresses(InetAddress address) {
= 
     addIPAddress(address);
    InetAddress[] addressCopy = (InetAddress[]) ips.toArray(new InetAddress[0]);      
    // Iterate through array addressCopy ...
  }
}

{code}



Even though the {{Collection}} wrapper offers thread-safety guarantees for individual method invocations, a sequence of method calls is not atomic. For example, when multiple threads invoke the {{addAndPrintIPAddresses()}} method to add an IP address and iterate over the array {{addressCopy}}, each thread can observe {{addressCopy}} to contain a different number of IP addresses because of the race condition in the {{addAndPrintIPAddresses()}} method. 

h2. Compliant Solution (Synchronized Block)

To eliminate the race conditions, ensure atomicity by using the underlying list's lock. This compliant solution includes all statements that use the array list within a synchronized block that locks on the list. 

{code:bgColor=#ccccff}
final class IPHolder {
  private final List<InetAddress> ips = 
      Collections.synchronizedList(new ArrayList<InetAddress>());

  public void addIPAddressaddAndPrintIPAddresses(InetAddress address) { 
    synchronized (ips) { 
      ips.add(address);
    }
  }

  public void addAndPrintIPAddresses(InetAddress address) {
    synchronized (ips) {
      addIPAddress(address);
InetAddress[] addressCopy = 
       InetAddress[] addressCopy = (InetAddress[]) ips.toArray(new InetAddress[0]);           
      // Iterate through array addressCopy ...
    }
  }
}
{code}

final class KeyedCounter {
  private final Map<String, Integer> map =
      Collections.synchronizedMap(new HashMap<String, Integer>());

  public void increment(String key) {
    Integer old = map.get(key);
    int oldValue = (old == null) ? 0 : old.intValue();
    if (oldValue == Integer.MAX_VALUE) {
      throw new ArithmeticException("Out of range");
    }
    map.put( key, oldValue + 1);
  }

  public Integer getCount(String key) {
    return map.get(key);
  }
}

final class KeyedCounter {
  private final Map<String, Integer> map =
      new HashMap<String, Integer>();
  private final Object lock = new Object();

  public void increment(String key) {
    synchronized (lock) {
      Integer old = map.get(key);
      int oldValue = (old == null) ? 0 : old.intValue();
      if (oldValue == Integer.MAX_VALUE) {
        throw new ArithmeticException("Out of range");
      }
      map.put(key, oldValue + 1);
    }
  }

  public Integer getCount 06|AA. Java References#Goetz 06]\], because the class holds a lock on an object that might, presumably, be accessible to other classes. Client-side locking is not always an appropriate strategy; see [CON31-J. Avoid client-side locking when using classes that do not commit to their locking strategy] for more information. 

Although expensive in terms of performance, the {{CopyOnWriteArrayList}} and {{CopyOnWriteArraySet}} classes are sometimes used to create copies of the core {{Collection}} so that iterators do not fail with a runtime exception when some data in the {{Collection}} is modified. However, any updates to the {{Collection}} are not immediately visible to other threads. Consequently, the use of these classes is limited to boosting performance in code where the writes are fewer (or non-existent) as compared to the reads  \[[JavaThreads 04|AA. Java References#JavaThreads 04]\]. In most other cases they must be avoided (see [MSC13-J. Do not modify the underlying collection when an iteration is in progress] for details on using these classes).    

This code does not violate [CON40-J. Do not synchronize on a collection view if the backing collection is accessible], because while it does synchronize on a collection view (the {{synchronizedList}}), the backing collection is not accessible, and therefore cannot be modified by any code.


h2. Noncompliant Code Example ({{synchronizedMap}})

This noncompliant code example defines a class {{KeyedCounter}} which is not thread-safe. Although the {{HashMap}} is wrapped in a synchronized {{Map}}, the overall increment operation is not atomic \[[Lee 09|AA. Java References#Lee 09]\].   

{code:bgColor=#FFCCCC}
final class KeyedCounter {
  private final Map<String, Integer> map = new HashMap<String, Integer>(); 
  private final Object lock = new Object();

  public void increment(String key) {
    synchronized (lock) {
      Integer oldreturn = map.get(key);
      int value = (old == null) ? 1 : old.intValue() + 1;
      map.put(key, value);
    }
  }

  public Integer getCount(String key) {
    synchronized (lock) {
      return map.get(key);
    }
  }

  // Other accessors ...
}

{code}


h2. Compliant Solution (atomic method)

This compliant solution invokes the {{AtomicInteger.incrementAndGet()}} method to ensure the atomicity of the increment operation. This provides a happens-before relationship between reading and writing any integer values in the map.

{code:bgColor=#ccccff}
final class KeyedCounter {
  private final ConcurrentMap<String, AtomicInteger> map =
    new ConcurrentHashMap<String, AtomicInteger>}
  }
}

final class KeyedCounter {
  private final ConcurrentMap<String, AtomicInteger> map =
      new ConcurrentHashMap<String, AtomicInteger>();
  private final Object lock = new Object();

  public void increment(String key) {
    AtomicInteger value = new AtomicInteger(0);
    AtomicInteger old = map.putIfAbsent(key, value);
   
    if (old != null) { 
      value = old; 
    }

    value.incrementAndGetsynchronized (lock); //{
 Increment the value atomically
  }

  public Integer getCount(String keyif (value.get() == Integer.MAX_VALUE) {
       AtomicInteger valuethrow =new map.get(keyArithmeticException("Out of range");
    return value.get();
  }

      value.incrementAndGet(); // Increment Otherthe accessorsvalue ...
atomically
    }
{code  }

This compliant solutionpublic doesInteger not use {{Collections.synchronizedMap()}} because locking on the (unsynchronized) map provides sufficient thread-safety for this application. The guideline [CON40-J. Do not synchronize on a collection view if the backing collection is accessible] provides more information about synchronizing on {{synchronizedMap}} objects.

To prevent overflow, the caller must ensure that the {{increment()}} method is called no more than {{Integer.MAX_VALUE}} times for any key. Refer to [INT00-J. Perform explicit range checking to ensure integer operations do not overflow] for more information. 

h2. Compliant Solution ({{ConcurrentHashMap}})

The previous compliant solution does not scale very well because a class with several {{synchronized}} methods can be a potential bottleneck as far as acquiring locks is concerned, and may further yield a deadlock or livelock. The class {{ConcurrentHashMap}} provides several utility methods for performing atomic operations and is often a good choice, as demonstrated in this compliant solution \[[Lee 09|AA. Java References#Lee 09]\]. 

{code:bgColor=#ccccff}
final class KeyedCounter {
  private final ConcurrentMap<String, AtomicInteger> map =
    new ConcurrentHashMap<String, AtomicInteger>();

  public void increment(String key) {
    AtomicInteger value = new AtomicInteger();
    AtomicInteger old = map.putIfAbsent(key, value);
   
    if (old != null) { 
      value = old; 
    }

    value.incrementAndGet(); // Increment the value atomically
  }

  public Integer getCount(String key) {
    AtomicInteger value = map.get(key);
    return value.get();
  }

  // Other accessors ...
}
{code}

According to Goetz et al. \[[Goetz 06|AA. Java References#Goetz 06]\] section 5.2.1. ConcurrentHashMap:

{quote}
{{ConcurrentHashMap}}, along with the other concurrent collections, further improve on the synchronized collection classes by providing iterators that do not throw {{ConcurrentModificationException}}, as a result eliminating the need to lock the collection during iteration. The iterators returned by {{ConcurrentHashMap}} are weakly consistent instead of fail-fast. A weakly consistent iterator can tolerate concurrent modification, traverses elements as they existed when the iterator was constructed, and may (but is not guaranteed to) reflect modifications to the collection after the construction of the iterator.
{quote}

Note that methods such as {{size()}} and {{isEmpty()}} are allowed to return an approximate result for performance reasons. Code should not rely on these return values for deriving exact results. 


h2. Risk Assessment

Non-atomic code can induce race conditions and affect program correctness.

|| Rule || Severity || Likelihood || Remediation Cost || Priority || Level ||
| CON07- J | low | probable | medium | {color:green}{*}P4{*}{color} | {color:green}{*}L3{*}{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+CON38-J].

h2. References

\[[API 06|AA. Java References#API 06]\] 
\[[JavaThreads 04|AA. Java References#JavaThreads 04]\] Section 8.2, "Synchronization and Collection Classes"
\[[Goetz 06|AA. Java References#Goetz 06]\] Section 4.4.1, "Client-side Locking", Section 5.2.1, "ConcurrentHashMap"
\[[Lee 09|AA. Java References#Lee 09]\] "Map & Compound Operation"

----
[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_left.png!|VOID CON06-J. Do not defer a thread that is holding a lock]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_up.png!|11. Concurrency (CON)]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[!The CERT Sun Microsystems Secure Coding Standard for Java^button_arrow_right.png!|CON08-J. Do not call alien methods that synchronize on the same objects as any callers in the execution chain]

getCount(String key) {
    AtomicInteger value = map.get(key);
    return (value == null) ? null : value.get();
  }

  // Other accessors ...
}