Wiki Markup |
---|
_Lazy initialization_ defers the construction of a member field or an object referred to by a member field until an instance is actually required rather than computing the field value or constructing the referenced object in the class's constructor. Lazy initialization helps to break harmful circularities in class and instance initialization . It also enables other optimizations \[[Bloch 2005|AA. Bibliography#BlochReferences#Bloch 05]\]. |
Lazy initialization uses either a class or an instance method, depending on whether the member object is static. The method checks whether the instance has already been created and, if not, creates it. When the instance already exists, the method simply returns the instance:
...
Wiki Markup |
---|
According to Pugh \[[Pugh 2004|AA. Bibliography#PughReferences#Pugh 04]\] |
Writes that initialize the
Helper
object and the write to thehelper
field can be done or perceived out of order. As a result, a thread which invokesgetHelper()
could see a non-null reference to ahelper
object, but see the default values for fields of thehelper
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.
...
Wiki Markup |
---|
When a thread initializes the {{Helper}} object, a [happens-before relationship|BB. Glossary#happens-before order] is established between this thread and any other thread that retrieves and returns the instance \[[Pugh 2004|AA. Bibliography#PughReferences#Pugh 04], [Manson 2004|AA. Bibliography#MansonReferences#Manson 04]\]. |
Compliant Solution (Static Initialization)
Wiki Markup |
---|
This compliant solution initializes the {{helper}} field in the declaration of the static variable \[[Manson 2006|AA. Bibliography#MansonReferences#Manson 06]\]. |
Code Block | ||
---|---|---|
| ||
final class Foo { private static final Helper helper = new Helper(); public static Helper getHelper() { return helper; } } |
...
Wiki Markup |
---|
Initialization of the static {{helper}} field is deferred until the {{getInstance()}} method is called. The necessary happens-before relationships are created by the combination of the class loader's actions loading and initializing the {{Holder}} instance and the guarantees provided by the Java memory model. This idiom is a better choice than the double-checked locking idiom for lazily initializing static fields \[[Bloch 2008|AA. Bibliography#BlochReferences#Bloch 08]\]. However, this idiom cannot be used to lazily initialize instance fields \[[Bloch 2001|AA. Bibliography#BlochReferences#Bloch 01]\]. |
Compliant Solution (ThreadLocal
Storage)
Wiki Markup |
---|
This compliant solution (originally suggested by Alexander Terekhov \[[Pugh 2004|AA. Bibliography#PughReferences#Pugh 04]\]) uses a {{ThreadLocal}} object to track whether each individual thread has participated in the synchronization that creates the needed happens-before relationships. Each thread stores a non-null value into its thread-local {{perThreadInstance}} only inside the synchronized {{createHelper()}} method; consequently, any thread that sees a null value must establish the necessary happens-before relationships by invoking {{createHelper()}}. |
...
Wiki Markup |
---|
*LCK10-EX0:* Use of the noncompliant form of the double-checked locking idiom is permitted for 32-bit primitive values (for example, {{int}} or {{float}}) \[[Pugh 2004|AA. Bibliography#PughReferences#Pugh 04]\], although this usage is discouraged. The noncompliant form establishes the necessary happens-before relationship between threads that see an initialized version of the primitive value. The second happens-before relationship (for the initialization of the fields of the referent) is of no practical value because unsynchronized reads and writes of primitive values up to 32-bits are guaranteed to be atomic. Consequently, the noncompliant form establishes the only needed happens-before relationship in this case. Note, however, that the noncompliant form fails for {{long}} or {{double}} because unsynchronized reads or writes of 64-bit primitives lack a guarantee of atomicity and consequently require a second happens-before relationship to guarantee that all threads see only fully assigned 64-bit values (See rule [VNA05-J. Ensure atomicity when reading and writing 64-bit values] for more information.) |
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="eab502d3bb8d3801-16c06d8c-446945d5-8c89a7ba-c58ea2eacd2584f255e7e89d"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API References#API 06]] |
| ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="5a229644a48df7ad-f623eafe-4ead45c8-bfcebec3-109338de5c441ef1dda20621"><ac:plain-text-body><![CDATA[ | [[Bloch 2001 | AA. Bibliography#Bloch References#Bloch 01]] | Item 48. Synchronize access to shared mutable data | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="a7155494cfdea8f5-363e1af5-45f14778-b2a0ae00-327f5ab780d0befd481954f7"><ac:plain-text-body><![CDATA[ | [[Bloch 2008 | AA. Bibliography#Bloch References#Bloch 08]] | Item 71. Use lazy initialization judiciously]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="8136568db616eb77-312d8ed7-404042dc-bb2babd5-c49093106e4beceb6029d7fa"><ac:plain-text-body><![CDATA[ | [[JLS 2005 | AA. Bibliography#JLS References#JLS 05]] | §12.4, Initialization of Classes and Interfaces | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="7ce0fa3433efb2c8-2716968a-4f014a5b-a6f7aa9a-6851319da131cdb419b9d81e"><ac:plain-text-body><![CDATA[ | [[Pugh 2004 | AA. Bibliography#Pugh References#Pugh 04]] |
| ]]></ac:plain-text-body></ac:structured-macro> |
...