[
https://issues.apache.org/jira/browse/NETBEANS-5136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280303#comment-17280303
]
Carsten Hammer commented on NETBEANS-5136:
------------------------------------------
Hi Jan,
the code that works according to the github bug description looks like this:
{code:java}
private volatile String init;
public String get() {
String init= this.init;
if (init == null) { // First check (no locking)
synchronized (this) {
if (this.init == null) // Second check (with locking)
this.init = init= computeFieldValue();
else
init= this.init;
}
}
return init;
}
{code}
So the difference is
{code:java}
init = this.init;
if (init == null) {
this.init = init = "";
}
{code}
vs
{code:java}
if (this.init == null) // Second check (with locking)
this.init = init= computeFieldValue();
else
init= this.init;
{code}
within the synchronized section. Is this the same?
It doesn't look like it is the same. But maybe similar enough and in the end
the netbeans variant is identical to the older code from Joshua Bloch published
at
https://www.oracle.com/technical-resources/articles/javase/bloch-effective-08-qa.html
that seems to be fine too.
So - apologies - your code seems to be ok!
I close this now.
As a sidenote I still prefer the variant in the description of this issue but
of course this is a matter of personal preference.
> double checked locking idiom wrong in inspect and transform
> -----------------------------------------------------------
>
> Key: NETBEANS-5136
> URL: https://issues.apache.org/jira/browse/NETBEANS-5136
> Project: NetBeans
> Issue Type: Bug
> Components: java - Refactoring
> Affects Versions: 12.2
> Reporter: Carsten Hammer
> Priority: Critical
>
> The pattern implemented in
> [https://bz.apache.org/netbeans/show_bug.cgi?id=248740] seems to be wrong
> according to
> [https://docs.google.com/document/d/1mAeEgQu4H4ADxa03k7YaVDjIP5vJBvjVIjg3DIvoc8E/edit]
> The right pattern looks like this:
> # 334, Second code example. *_This is a serious error!_* The current code
> can return null if multiple threads race to initialize the field. Here’s how
> the code should look:
>
> {code:java}
> // Double-check idiom for lazy initialization of instance fields
> private volatile FieldType field;
>
> private FieldType getField() {
> FieldType result = field;
> if (result != null) // First check (no locking)
> return result;
>
> synchronized(this){
> if (field == null) // Second check (with locking)
> field = computeFieldValue();
> return field;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
