Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>Isn't this enough ?</p> <pre><code>if (helperWrapper == null) { synchronized(this) { if (helperWrapper == null) { helperWrapper = new FinalWrapper&lt;Helper&gt;(new Helper()); } } } </code></pre> </blockquote> <p>No this isn't enough.</p> <p>Above, first check for <code>helperWrapper == null</code> is not thread safe. It may return false (seeing non-null instance) for some thread "too early", pointing to not fully constructed helperWrapper object.</p> <p>The very <a href="http://en.wikipedia.org/wiki/Double-checked_locking" rel="nofollow">Wikipedia article</a> you refer to, explains this issue step-by-step:</p> <blockquote> <p>For example, consider the following sequence of events:</p> <ol> <li>Thread A notices that the value is not initialized, so it obtains the lock and begins to initialize the value.</li> <li>Due to the semantics of some programming languages, the code generated by the compiler is allowed to update the shared variable to point to a partially constructed object before A has finished performing the initialization.</li> <li>Thread B notices that the shared variable has been initialized (or so it appears), and returns its value. Because thread B believes the value is already initialized, it does not acquire the lock. If B uses the object before all of the initialization done by A is seen by B (either because A has not finished initializing it or because some of the initialized values in the object have not yet percolated to the memory B uses (cache coherence)), the program will likely crash.</li> </ol> </blockquote> <p>Note <em>semantics of some programming languages</em> mentioned above is exactly the semantic of Java as of version 1.5 and higher. Java Memory Model (JSR-133) explicitly allows for such behavior - search the web for more details on that if you're interested.</p> <blockquote> <p>Is it because using wrapper can speed up initialization because wrapper is stored on stack and helperWrapper is stored in heap?</p> </blockquote> <p>No, above isn't the reason.</p> <p>The reason is thread safety. Again, semantic of Java 1.5 and higher (as defined in Java Memory Model) guarantees that any thread will be able to access only properly initialized Helper instance from wrapper due to the fact that it is a final field initialized in constructor - see <a href="http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.5" rel="nofollow">JLS 17.5 Final Field Semantics</a>.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload