Page History

A common errormisconception is to assume that shared references to immutable objects are made visible across multiple threads as soon as they are updated. For instance, a developer may incorrectlymisconceive conceive that a class containing fields referring to only immutable objects, is immutable. However, this class is not even thread-safe.

The Java™ Programming Language, Fourth Edition \[[JPL 06|AA. Java References#JPL 06]\], "Section 14.10.2. Final Fields and Security" states:

{quote}
... you can use {{final}} fields to define immutable objects. There is a common misconception that shared access to immutable objects does not require any synchronization because the state of the object never changes. This is a misconception in general because it relies on the assumption that a thread will be guaranteed to see the initialized state of the immutable object, and that need not be the case. The problem is that, while the shared object is immutable, the reference used to access the shared object is itself shared and often mutable. Consequently, a correctly synchronized program must synchronize access to that shared reference, but often programs do not do this, because programmers do not recognize the need to do it. For example, suppose one thread creates a {{String}} object and stores a reference to it in a {{static}} field. A second thread then uses that reference to access the string. There is no guarantee, based on what we've discussed so far, that the values written by the first thread when constructing the string will be seen by the second thread when it accesses the string.
{quote}

Immutable objects can be safely shared amongst multiple threads. However, mutable objects may not be fully constructed when their references are made visible. References to either kinds of objects must be made visible to all the threads. The guideline [CON26-J. Do not publish partially initialized objects] focuses on object construction and visibility issues specific to mutable objects. 

h2. Noncompliant Code Example

This noncompliant code example consists of an immutable class {{Helper}}: 

{code}
// Immutable Helper
public final class Helper {
  private final int n;

  public Helper(int n) {
    this.n = n;
  }
  // ...
}
{code}

and a mutable class {{Foo}}:   

{code:bgColor=#FFCCCC}
final class Foo {
  private Helper helper;

  public Helper getHelper() {
    return helper;
  }

  public void setHelper(int num) {
    helper = new Helper(num);
  }
}
{code}

The {{Foo.getHelper()}} method publishes the mutable {{helper}} field. {mc} I am changing the previous line because it talks about synchronization which is a CS {mc} As the {{Helper}} class is [immutable|BB. Definitions#immutable], it cannot be changed after it is initialized and is always properly constructed before its reference is made visible, in compliance with [CON26-J. Do not publish partially initialized objects]. However, some thread can observe the {{helper}} field of class {{Foo}} to contain a stale reference.

h2. Compliant Solution (synchronization)

This compliant solution synchronizes the methods of class {{Foo}} to ensure that no thread sees a stale {{Helper}} reference. 

{code:bgColor=#CCCCFF}
final class Foo {
  private Helper helper;

  public synchronized Helper getHelper() {
    return helper;
  }

  public synchronized void setHelper(int num) {
    helper = new Helper(num);
  }
}
{code}

The immutable {{Helper}} class is unchanged.

h2. Compliant Solution ({{volatile}})

References to immutable member objects can be made visible by declaring them {{volatile}}.

{code:bgColor=#CCCCFF}
final class Foo {
  private volatile Helper helper;

  public Helper getHelper() {
    return helper;
  }

  public void setHelper(int num) {
    helper = new Helper(num);
  }
}
{code}

The immutable {{Helper}} class isremains unchanged.

h2. Compliant Solution ({{java.util.concurrent}} utilities)

This compliant solution uses an {{AtomicReference}} wrapper around the immutable {{Helper}} object.  

{code:bgColor=#CCCCFF}
final class Foo {
  private final AtomicReference<Helper> helperRef =
    new AtomicReference<Helper>();

  public Helper getHelper() {
    return helperRef.get();
  }

  public void setHelper(int num) {
    helperRef.set(new Helper(num));
  }
}
{code}

The immutable {{Helper}} class isremains unchanged.

h2. Risk Assessment

The assumption that classes containing immutable objects are immutable is misleading and can cause serious thread-safety issues.

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

h2. References

\[[API 06|AA. Java References#API 06]\] 
\[[JPL 06|AA. Java References#JPL 06]\], 14.10.2. Final Fields and Security:


----
[!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)]