...
The
...
usual
...
way
...
of
...
initializing
...
a
...
sub-object
...
is
...
to
...
use
...
a
...
constructor.
...
Sometimes
...
it
...
is
...
required
...
to
...
limit
...
the
...
number
...
of
...
instances
...
of
...
the
...
sub-object
...
to
...
just
...
one
...
(this
...
is
...
similar
...
to
...
a
...
singleton,
...
however,
...
the
...
sub-object
...
may
...
or
...
may
...
not
...
be
...
static
...
).
...
In
...
addition,
...
a
...
technique
...
called
...
lazy
...
initialization
...
is
...
used
...
to
...
defer
...
the
...
construction
...
of
...
the
...
sub-object
...
until
...
it
...
is
...
actually
...
required.
...
For
...
these
...
purposes,
...
instead
...
of
...
a
...
constructor,
...
a
...
class
...
or
...
an
...
instance
...
method
...
should
...
be
...
used
...
for
...
initialization,
...
depending
...
on
...
whether
...
the
...
sub-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 class Foo { private Helper helper = null; public Helper getHelper() { if (helper == null) { helper = new Helper(); } return helper; } // ... } {code} |
In
...
a
...
multi-threading
...
scenario,
...
the
...
initialization
...
must
...
be
...
synchronized
...
so
...
that
...
two
...
or
...
more
...
threads
...
do
...
not
...
create
...
multiple
...
instances
...
of
...
the
...
sub-object.
...
The
...
code
...
shown
...
below
...
is
...
correctly
...
synchronized,
...
albeit
...
slower
...
than
...
the
...
previous,
...
single
...
threaded
...
code
...
example.
| Code Block | ||
|---|---|---|
| ||
{code:bgColor=#ccccff} // Correct multithreaded version using synchronization class Foo { private Helper helper = null; public synchronized Helper getHelper() { if (helper == null) { helper = new Helper(); } return helper; } // Other functions and members... } {code} |
The
...
double
...
checked
...
locking
...
(DCL)
...
idiom
...
is
...
sometimes
...
used
...
to
...
provide
...
lazy
...
initialization
...
in
...
multithreaded
...
code.
...
In
...
a
...
multi-threading
...
scenario,
...
lazy
...
initialization
...
is
...
supplemented
...
by
...
reducing
...
the
...
cost
...
of
...
synchronization
...
on
...
each
...
method
...
access
...
by
...
limiting
...
the
...
synchronization
...
to
...
the
...
case
...
where
...
the
...
instance
...
is
...
to
...
be
...
created
...
and
...
forgoing
...
it
...
when
...
retrieving
...
an
...
already
...
created
...
instance.
...
The
...
double-checked
...
locking
...
pattern
...
eliminates
...
method
...
synchronization
...
and
...
uses
...
block
...
synchronization.
...
It
...
strives
...
to
...
make
...
the
...
previous
...
code
...
example
...
faster
...
by
...
installing
...
a
...
null
...
check
...
before
...
attempting
...
to
...
synchronize.
...
This
...
makes
...
expensive
...
synchronization
...
dispensable
...
for
...
the
...
common
...
case
...
of
...
retrieving
...
the
...
value.
...
The
...
noncompliant
...
code
...
example
...
shows
...
the
...
originally
...
proposed
...
DCL
...
pattern.
...
| 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.
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 class Foo { private Helper helper = null; public Helper getHelper() { if (helper == null) { synchronized(this) { if (helper == null) helper = new Helper(); } } return helper; } // other functions and members... } {code} h2. Compliant Solution |
Compliant Solution (volatile)
...
This
...
compliant
...
solution
...
declares
...
the
...
Helper
...
object
...
as
...
volatile
...
.
| Code Block | ||||
|---|---|---|---|---|
| =
| |||
} // Works with acquire/release semantics for volatile // Broken under JDK 1.4 and earlier 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 |
|---|
JDK 5.0 allows a write of a {{volatile}} variable to be reordered with respect to a previous read or write. A read of a {{volatile}} variable cannot be reordered with respect to any following read or write. Because of this, the double checked locking idiom can work when {{helper}} is declared {{volatile}}. If a thread initializes the {{Helper}} object, a happens-before relationship 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
...
lazy initialization)
...
| Wiki Markup |
|---|
This compliant solution eagerly initializes the {{helper}} in the declaration of the {{static}} variable \[[Manson 06|AA. Java References#Manson 06]\]. |
| Code Block | ||
|---|---|---|
| ||
(sic). {mc} \[[Pugh 04|AA. Java References#Pugh 04]\] lists this as lazy initialization but it is actually eager initialization and so the (sic). {mc} {code:bgColor=#ccccff} class Foo { static final Helper helper = new Helper(); private Helper() { // ... } public static Helper getHelper() { return helper; } } {code} |
Variables
...
declared
...
static
...
are
...
guaranteed
...
to
...
be
...
initialized
...
and
...
made
...
visible
...
to
...
other
...
threads
...
immediately.
...
Static
...
initializers
...
also
...
exhibit
...
these properties. 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 will be first used.
Compliant Solution (static lazy initialization)
This compliant solution incorporates lazy initialization which makes it more productive. It also uses a static variable as suggested in the previous compliant solution. The variable is declared within a static inner, Holder class.
| Code Block | ||
|---|---|---|
| ||
properties. h2. Compliant Solution (static lazy initialization) This compliant solution incorporates lazy initialization which makes it more productive. It also uses a {{static}} variable as suggested in the previous compliant solution. The variable is declared within a {{static}} inner, {{Holder}} class. {code:bgColor=#ccccff} class Foo { // Lazy initialization private static class Holder { static Helper helper = new Helper(); } public static Helper getInstance() { return Holder.helper; } } {code} |
| Wiki Markup |
|---|
This idiom is called the initialize-on-demand holder class idiom. Initialization of the {{Holder}} class is deferred until the {{getInstance()}} method is called, following which the {{helper}} is initialized. The only limitation of this method is that it works only for {{static}} fields and not instance fields. \[[Bloch 01|AA. Java References#Bloch 01]\] |
...
Exceptions
EX1:
...
Explicitly
...
synchronized
...
code
...
(that
...
uses
...
method
...
synchronization
...
or
...
proper
...
block
...
synchronization,
...
that
...
is,
...
enclosing
...
all
...
initialization
...
statements)
...
does
...
not
...
require
...
the
...
use
...
of
...
double-checked
...
locking.
...
| Wiki Markup |
|---|
*EX2:* "Although 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]\]
\[[Pugh 04|AA. Java References#Pugh 04]\]
\[[Bloch 01|AA. Java References#Bloch 01]\] Item 48: "Synchronize access to shared mutable data"
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 609|http://cwe.mitre.org/data/definitions/609.html] "Double-Checked Locking" |
...
...
...
...
...
...
...
...
...
Pools 11. Concurrency (CON) CON23-J.
...
...
...
...
...
...
...
...
...