Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Edited the guideline, please check
Wiki Markup
Sometimes it is required share an object among multiple threads. During initialization, the object must remain exclusive to the thread constructing it, but once initialized, it can be published, that is, made visible to other threads. 

The Java Memory Model permits a compiler to modify the order of statements so that a seemingly innocuous publication results in multiple threads observing the object before it is fully initialized.

h2. Noncompliant Code Example

This noncompliant code example initializes a {{Helper}} object inside class {{Foo}}.

{code:bgColor=#FFCCCC}
class Foo

Sometimes you will want to construct a object to be shared among multiple threads. While being initialized, the object must remain exclusive to the thread constructing it, but once initialized, it can be 'published'. that is, made visible to other threads. However, the Java Memory Model permits a compiler to modify the order of statements to that a semmingly innocuous publication turns out to permit multiple threads to have access to an object before it is fully constructed.

Noncompliant Code Example

This noncompliant code example initializes a Helper object inside a Foo object.

Code Block
bgColor#FFCCCC

public class Helper {
  private intHelper nhelper;

  public Helper getHelper(int n) {
    this.n = nreturn helper;
  }

  public  // other fields & methods
}


class Foovoid initialize() {
    helper = new Helper(42);
  }
}

public class Helper {
  private Helperint helpern;

  public Helper(int getHelper(n) {return
 helper;}

  public void initialize() {this.n = n;
  }

  helper = new Helper(42);
  }
}

Suppose two threads have access to the same Foo object, and initialize() hasn't been called yet. Then both threads will see that getHelper() returns null. If one thread calls initialize(), and the other thread calls getHelper(), the second thread might receive null. Or it might receive a fully-initialized Helper object, with the n field set to 42. Or it might receive a partially-initialized Helper object where n is not initialized; that is n has the value 0.

In particular, the JMM permits compilers to allocate memory for the new Helper object and assign it to the helper field, then subsequently initialize it. This provides a race window during which other threads might see a partially-initialized helper object.

Compliant Solution (volatile)

If the helper field is declared volatile, then it is guaranteed to be fully constructed before becoming visible.

Code Block
bgColor#CCCCFF
// ...
}


{code}

Suppose two threads have access to the same {{Foo}} object through the use of the {{getHelper()}} method, and {{initialize()}} has not been called yet. Both threads will see the {{helper}} field as uninitialized. Subsequently, if one thread calls {{initialize()}}, and the other calls {{getHelper()}}, the second thread may either see the {{helper}} reference as {{null}}, observe a fully-initialized {{Helper}} object with the {{n}} field set to 42, or observe a partially-initialized {{Helper}} object with an uninitialized {{n}} (default value of {{n}} being {{0}}).

In particular, the JMM permits compilers to allocate memory for the new {{Helper}} object and assign it to the {{helper}} field before initializing it. This introduces a race window during which other threads may see a partially-initialized {{helper}} object.

h2. Compliant Solution ({{volatile}})

If the {{helper}} field is declared as {{volatile}}, it is guaranteed to be fully constructed (properly initialized) before the reference is made visible.

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

  public Helper getHelper() {
    return helper;
  }

  public void initialize() {
    helper = new Helper(42);
  }
}

Compliant Solution (final)

If the helper field is declared final, then it is guaranteed to be fully constructed before becoming visible.

Code Block
bgColor#CCCCFF
{code}


h2. Compliant Solution ({{final}})

If the {{helper}} field is declared as {{final}}, then it is guaranteed to be fully constructed before the reference is made visible.

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

  public Helper getHelper() {
    return helper;
  }

  public void initialize() {
    helper = new Helper(42);
  }
}

Of course, this prevents you from subsequently setting the helper field to a new object.

Compliant Solution (immutable)

If the Helper class is immutable, then it is guaranteed to be fully constructed before becoming visible. The object must be truly immutable; it is not sufficient for the program to refrain from modifying the object.

Code Block
bgColor#CCCCFF
{code}

However, this disallows setting the {{helper}} field to a new object.


h2. Compliant Solution ({{immutable}})

If the {{Helper}} class is [immutable|BB. Definitions#immutable], it is guaranteed to be fully constructed before its reference is made visible. The {{Helper}} object must be truly immutable; it is not sufficient for the program to refrain from modifying the object.

{code:bgColor=#CCCCFF}
public class Helper {
  private final int n;

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

  // other fields & methods, all fields are final
}

Note that if the Helper object is mutable, you not only need to worry about the visibility of partially-constructed objects, but you also need to worry about the object being modified while read after it has been successfully constructed. For more information see CON11-J. Do not assume that declaring an object volatile guarantees visibility of its members.

Compliant Solution (synchronized)

You can also prevent a partially-constructed object from becoming visible by using locks to control access to the object.

Code Block
bgColor#CCCCFF
...
}
{code}

Note that if the {{Helper}} object was mutable, in addition to the problem of visibility of a reference to a partially-constructed object, another problem would ensue. The state of the object may be modified after its construction and publication, causing subtle thread-safety issues. For more information see [CON11-J. Do not assume that declaring an object volatile guarantees visibility of its members].


h2. Compliant Solution ({{synchronized}})

The reference of a partially-constructed object can be prevented from being made visible by using method synchronization.

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

  public synchronized Helper getHelper() {
    return helper;
  }

  public synchronized void initialize() {
    helper = new Helper(42);
  }
}
{code}

Synchronizing both methods guarantees that they will never run simultaneously in different threads. If one

...

 thread were to call {{initialize()}} just before another thread calls {{getHelper()}},

...

 the synchronized {{initialize()

...

Compliant Solution (thread-safe composition)

Some collection classes provide thread-safety over their objects. If the helper field is contained in such a collection, then it is guaranteed to be fully constructed before becoming visible. The following code encases the helper field in a Vector.

Code Block
bgColor#CCCCFF
}} method will always finish first, fully initializing the {{Helper}} object on its way. This forbids {{getHelper()}} from retrieving a {{Helper}} object that is partially initialized. 


h2. Compliant Solution (thread-safe composition)

Some collection classes provide thread-safety of accesses to contained elements. If the {{helper}} field is contained in such a collection, the {{Helper}} object is guaranteed to be fully constructed before its reference is made visible. This compliant solution encases the {{helper}} field in a {{Vector}}.

{code:bgColor=#CCCCFF}
class Foo {
  private Vector<Helper> helper;

  public Helper getHelper() {
    return helper.elementAt(0);
  }

  public void initialize() {
    helper = new Vector<Helper>();
    helper.add(new Helper(42));
  }
}

...

{code}


h2. Compliant Solution (static initialization)

...



In this compliant solution, the {{helper}} field is initialized in a {{static}} block. When initialized statically, any object is guaranteed to be fully constructed

...

Code Block
bgColor#CCCCFF
 before its reference is made visible. {mc} cite JLS section here {mc}

{code:bgColor=#CCCCFF}
class Foo {
  private static Helper helper = new Helper(42);

  public static Helper getHelper() {
    return helper;
  } 
}
{code}

Of course, this requires that the helper field be static.

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

CON26-J

medium

probable

medium

P8

L2

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

...



This requires the {{helper}} field to be declared {{static}}.


h2. Risk Assessment

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

|| Rule || Severity || Likelihood || Remediation Cost || Priority || Level ||
| CON26-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+CON26-J].

h2. References

\[[API 06|AA. Java References#API 06]\] 
\[[Bloch 01|AA. Java References#Bloch 01]\] Item 48: "Synchronize access to shared mutable data"
\[[Goetz 06|AA. Java References#Goetz 06]\] Section 3.5.3 "Safe Publication Idioms"
\[[Goetz 07|AA. Java References#Goetz 07]\] Pattern #2: "one-time safe publication"
\[[Pugh 04|AA. Java References#Pugh 04]\]

...




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