| Wiki Markup |
|---|
Instead of initializing a member object using a constructor, sometimes a technique called lazy initialization is used to defer the construction of the member object until an instance is actually required. Lazy initialization also helps in breaking harmful circularities in class and instance initialization, and performing other optimizations \[[Bloch 05|AA. Java References#Bloch 05]\]. |
...
A
...
class
...
or
...
an
...
instance
...
method
...
is
...
used
...
for
...
lazy
...
initialization,
...
depending
...
on
...
whether
...
the
...
member
...
object
...
is
...
static
...
or
...
not.
...
The
...
method
...
checks
...
whether
...
the
...
instance
...
has
...
already
...
been
...
created
...
and
...
if
...
not,
...
creates
...
it.
...
If
...
the
...
instance
...
already
...
exists,
...
it
...
simply
...
returns
...
it.
...
This
...
is
...
shown
...
below:
| Code Block | ||||
|---|---|---|---|---|
| =
| |||
} // Correct single threaded version using lazy initialization final class Foo { private Helper helper = null; public Helper getHelper() { if (helper == null) { helper = new Helper(); } return helper; } // ... } {code} |
In
...
a
...
multithreading
...
scenario,
...
the
...
initialization
...
must
...
be
...
synchronized
...
so
...
that
...
two
...
or
...
more
...
threads
...
do
...
not
...
create
...
multiple
...
instances
...
of
...
the
...
member
...
object.
...
The
...
code
...
shown
...
below
...
is
...
safe
...
for
...
execution
...
in
...
a
...
multithreaded
...
environment,
...
albeit
...
slower
...
than
...
the
...
previous,
...
single
...
threaded
...
code
...
example.
| Code Block | ||
|---|---|---|
| ||
{code:bgColor=#ccccff} // Correct multithreaded version using synchronization final class Foo { private Helper helper = null; public synchronized Helper getHelper() { if (helper == null) { helper = new Helper(); } return helper; } // ... } {code} |
The
...
double
...
checked
...
locking
...
(DCL)
...
idiom
...
is
...
used
...
to
...
provide
...
lazy
...
initialization
...
in
...
multithreaded
...
code.
...
In
...
a
...
multithreading
...
scenario,
...
traditional
...
lazy
...
initialization
...
is
...
supplemented
...
by
...
reducing
...
the
...
cost
...
of
...
synchronization
...
for
...
each
...
method
...
access
...
by
...
limiting
...
the
...
synchronization
...
to
...
the
...
case
...
where
...
the
...
instance
...
is
...
required
...
to
...
be
...
created
...
and
...
forgoing
...
it
...
when
...
retrieving
...
an
...
already
...
created
...
instance.
...
The
...
double-checked
...
locking
...
pattern
...
uses
...
block
...
synchronization
...
instead
...
of
...
method
...
synchronization.
...
It
...
strives
...
to
...
make
...
the
...
previous
...
code
...
example
...
faster
...
by
...
installing
...
an
...
additional
...
null
...
check
...
before
...
attempting
...
synchronization.
...
This
...
makes
...
a
...
potentially
...
expensive
...
synchronization
...
necessary
...
only
...
for
...
initialization,
...
and
...
dispensable
...
for
...
the
...
common
...
case
...
of
...
retrieving
...
the
...
value
...
of
...
helper
...
.
...
The
...
noncompliant
...
code
...
example
...
shows
...
the
...
originally
...
proposed
...
DCL
...
pattern.
Noncompliant Code Example
This noncompliant code example uses the incorrect form of the double checked locking idiom.
| Code Block | ||
|---|---|---|
| ||
h2. Noncompliant Code Example This noncompliant code example uses the incorrect form of the double checked locking idiom. {code:bgColor=#FFCCCC} // "Double-Checked Locking" idiom final class Foo { private Helper helper = null; public Helper getHelper() { if (helper == null) { synchronized (this) { if (helper == null) { helper = new Helper(); } } } return helper; } // Other methods and members... } {code} |
| Wiki Markup |
|---|
According to the Java Memory Model (discussion reference) \[[Pugh 04|AA. Java References#Pugh 04]\]: |
...
...
...
writes
...
that
...
initialize
...
the
...
Helper
...
object
...
and
...
the
...
write
...
to
...
the
...
helper
...
field
...
can
...
be
...
done
...
or
...
perceived
...
out
...
of
...
order.
...
As
...
a
...
result,
...
a
...
thread
...
which
...
invokes
...
getHelper()
...
could
...
see
...
a
...
non-null
...
reference
...
to
...
a
...
helper
...
object,
...
but
...
see
...
the
...
default
...
values
...
for
...
fields
...
of
...
the
...
helper
...
object,
...
rather
...
than
...
the
...
values
...
set
...
in
...
the
...
constructor.
...
Even
...
if
...
the
...
compiler
...
does
...
not
...
reorder
...
those
...
writes,
...
on
...
a
...
multiprocessor
...
the
...
processor
...
or
...
the
...
memory
...
system
...
may
...
reorder
...
those
...
writes,
...
as
...
perceived
...
by
...
a
...
thread
...
running
...
on
...
another
...
processor.
...
This makes the originally proposed double-checked
...
locking
...
pattern
...
insecure.
...
The
...
guideline
...
...
...
...
...
...
...
...
further
...
discusses
...
the
...
possibility
...
of
...
a
...
non-null
...
reference
...
that
...
refers
...
to
...
a
...
partially
...
initialized
...
object.
Compliant Solution (volatile)
This compliant solution declares the Helper object as volatile and consequently, uses the correct form of the double-checked locking idiom.
| Code Block | ||
|---|---|---|
| ||
h2. Compliant Solution ({{volatile}}) This compliant solution declares the {{Helper}} object as {{volatile}} and consequently, uses the correct form of the double-checked locking idiom. {code:bgColor=#ccccff} // Works with acquire/release semantics for volatile // Broken under JDK 1.4 and earlier final class Foo { private volatile Helper helper = null; public Helper getHelper() { if (helper == null) { synchronized (this) { if (helper == null) { helper = new Helper(); // If the helper is null, create a new instance } } } return helper; // If helper is non-null, return its instance } } {code} |
| Wiki Markup |
|---|
If a thread initializes the {{Helper}} object, a [happens-before relationship|BB. Definitions#happens-before order] is established between this thread and another that retrieves and returns the instance. \[[Pugh 04|AA. Java References#Pugh 04]\] and \[[Manson 04|AA. Java References#Manson 04]\] |
...
Compliant Solution (static
...
initialization)
...
| Wiki Markup |
|---|
This compliant solution initializes the {{helper}} field in the declaration of the {{static}} variable \[[Manson 06|AA. Java References#Manson 06]\]. |
| Code Block | ||||
|---|---|---|---|---|
| =
| |||
} final class Foo { private static final Helper helper = new Helper(); public static Helper getHelper() { return helper; } } {code} |
| Wiki Markup |
|---|
Variables that are declared {{static}} and initialized at declaration or from a static initializer, are guaranteed to be fully constructed before being made visible to other threads. This approach should not be confused with eager initialization because in this case, the Java Language Specification guarantees lazy initialization of the class when it is first used \[[JLS 05|AA. Java References#JLS 05]\]. |
...
| Wiki Markup |
|---|
"Today, the double-check idiom is the technique of choice for lazily initializing an instance field. While you can apply the double-check idiom to {{static}} fields as well, there is no reason to do so: the lazy initialization holder class idiom is a better choice." \[[Bloch 08|AA. Java References#Bloch 08]\]. |
...
Compliant Solution (initialize-on-demand
...
holder
...
class
...
idiom)
...
This
...
compliant
...
solution
...
uses
...
the
...
initialize-on-demand
...
holder
...
class
...
idiom
...
that
...
implicitly
...
incorporates
...
lazy
...
initialization.
...
It
...
uses
...
a
...
static
...
variable
...
as
...
suggested
...
in
...
the
...
previous
...
compliant
...
solution
...
and
...
declares
...
it
...
within
...
a
...
static
...
inner
...
class,
...
Holder.
| Code Block | ||
|---|---|---|
| ||
}}. {code:bgColor=#ccccff} final class Foo { // Lazy initialization private static class Holder { static Helper helper = new Helper(); } public static Helper getInstance() { return Holder.helper; } } {code} |
| Wiki Markup |
|---|
Initialization of the {{Holder}} class is deferred until the {{getInstance()}} method is called, following which the {{helper}} field is initialized. The only limitation of this method is that it works only for {{static}} fields and not for instance fields \[[Bloch 01|AA. Java References#Bloch 01]\]. This idiom is a better choice than the double checked locking idiom for lazily initializing {{static}} fields \[[Bloch 08|AA. Java References#Bloch 08]\]. |
...
Compliant Solution (ThreadLocal storage)
| Wiki Markup |
|---|
This compliant solution (originally suggested by Alexander Terekhov \[[Pugh 04|AA. Java References#Pugh 04]\]) uses a {{ThreadLocal}} object to lazily create a {{Helper}} instance. |
| Code Block | ||||
|---|---|---|---|---|
| =
| |||
} class Foo { // If perThreadInstance.get() returns a non-null value, this thread // has done synchronization needed to see initialization of helper private final ThreadLocal<Object>ThreadLocal<Foo> perThreadInstance = new ThreadLocal<Object>ThreadLocal<Foo>(); private Helper helper = null; public Helper getHelper() { if (perThreadInstance.get() == null) { createHelper(); } return helper; } private final synchronized void createHelper() { if (helper == null) { helper = new Helper(); } // Any non-null value would do as the argument here perThreadInstance.set(this); } } {code} h2. Compliant Solution ({{ |
Compliant Solution (java.util.concurrent
...
utilities)
...
This
...
compliant
...
solution
...
uses
...
an
...
AtomicReference
...
wrapper
...
around
...
the
...
Helper
...
object.
...
It
...
uses
...
the
...
standard
...
compareAndSet
...
(CAS)
...
functionality
...
to
...
set
...
a
...
newly
...
created
...
Helper
...
object
...
if
...
helperRef
...
is
...
null
...
.
...
Otherwise,
...
it
...
simply
...
returns
...
the
...
already
...
created
...
instance.
...
(Tom
...
Hawtin,
...
...
...
List)
| Code Block | ||
|---|---|---|
| ||
|https://mailman.cs.umd.edu/mailman/private/javamemorymodel-discussion/2006-December/000067.html]) {code:bgColor=#ccccff} // Uses atomic utilities final class Foo { private final AtomicReference<Helper> helperRef = new AtomicReference<Helper>(); public Helper getHelper() { Helper helper = helperRef.get(); if (helper != null) { return helper; } Helper newHelper = new Helper(); return helperRef.compareAndSet(null, newHelper) ? newHelper : helperRef.get(); } } {code} |
While
...
this
...
code
...
ensures
...
that
...
only
...
one
...
Helper
...
object
...
is
...
prevented
...
from
...
being
...
garbage
...
collected,
...
it
...
allows
...
multiple
...
Helper
...
objects
...
to
...
be
...
created.
...
If
...
constructing
...
multiple
...
Helper
...
objects
...
is
...
infeasible
...
or
...
expensive,
...
this
...
solution
...
may
...
not
...
be appropriate.
Compliant Solution (immutable)
In this compliant solution the Foo class is unchanged, but the Helper class is made immutable. Consequently, the Helper class 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 | ||
|---|---|---|
| ||
appropriate. {mc} Ok, so this won't work with weak refs because the refs are still strong. Even if not, helper may be mistakenly assigned null. ~DM For example, if there is only a limited amount of memory available, this approach may cause an {{OutOfMemoryError}} unless a weak reference is used to hold {{Helper}}. {mc} h2. Compliant Solution ({{immutable}}) In this compliant solution the {{Foo}} class is unchanged, but the {{Helper}} class is made [immutable|BB. Definitions#immutable]. Consequently, the {{Helper}} class 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:bgColor=#CCCCFF} public final class Helper { private final int n; public Helper(int n) { this.n = n; } // Other fields and methods, all fields are final } final class Foo { private Helper helper = null; public Helper getHelper() { if (helper == null) { synchronized (this) { if (helper == null) { helper = new Helper(); // If the helper is null, create a new instance } } } return helper; // If helper is non-null, return its instance } } {code} |
Note
...
that
...
if
...
class
...
Foo
...
were
...
mutable,
...
the
...
Helper
...
field
...
would
...
need
...
to
...
be
...
declared
...
volatile
...
as
...
recommended
...
in
...
...
...
...
...
...
...
...
...
...
.
...
Also,
...
the
...
getHelper()
...
method
...
is
...
an
...
instance
...
method
...
and
...
the
...
accessibility
...
of
...
the
...
helper
...
field
...
is
...
private
...
.
...
This
...
allows
...
safe
...
publication
...
of
...
the
...
Helper
...
object,
...
in
...
that
...
a
...
thread
...
cannot
...
observe
...
a
...
partially
...
initialized
...
Foo
...
object
...
(
...
...
...
...
...
...
...
...
).
...
The
...
class
...
Helper
...
is
...
also
...
compliant
...
with
...
...
...
...
...
...
...
...
and
...
consequently,
...
it
...
cannot
...
be
...
observed
...
to
...
be
...
in
...
a
...
partially
...
initialized
...
state.
...
Exceptions
EX1:
...
Explicitly
...
synchronized
...
code
...
(that
...
uses
...
method
...
synchronization
...
or
...
proper
...
block
...
synchronization,
...
enclosing
...
all
...
initialization
...
statements)
...
does
...
not
...
require
...
the
...
use
...
of
...
double-checked
...
locking.
...
| Wiki Markup |
|---|
*EX2:* "Although the \[noncompliant form of the\] double-checked locking idiom cannot be used for references to objects, it can work for 32-bit primitive values (e.g., int's or float's). Note that it does not work for long's or double's, since unsynchronized reads/writes of 64-bit primitives are not guaranteed to be atomic." \[[Pugh 04|AA. Java References#Pugh 04]\]. (See [CON25-J. Ensure atomicity when reading and writing 64-bit values] for more information.) |
...
Risk Assessment
Using incorrect forms of the double checked locking idiom can lead to synchronization issues.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
CON22- J | low | probable | medium | P4 | L3 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
| Wiki Markup |
|---|
\[[API 06|AA. Java References#API 06]\]
\[[JLS 05|AA. Java References#JLS 05]\] 12.4 "Initialization of Classes and Interfaces"
\[[Pugh 04|AA. Java References#Pugh 04]\]
\[[Bloch 01|AA. Java References#Bloch 01]\] Item 48: "Synchronize access to shared mutable data"
\[[Bloch 08|AA. Java References#Bloch 08]\] Item 71: "Use lazy initialization judiciously"
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 609|http://cwe.mitre.org/data/definitions/609.html] "Double-Checked |
...
Locking" |
...
...
...
...
...
...
...
...
...
...
...
during traffic bursts 11. Concurrency (CON) CON23-J.
...
...
...
...
...
...
...
...
...