Safe initialisation of null reference

Question

I'm wondering what publication guarantees exist for a non-final field initialised to null, if any.

Consider the following snippet:

public class MyClass {

    private final CopyOnWriteArrayList<Inner> list = new CopyOnWriteArrayList<>();

    //called by thread 1
    public void init() {
        // initialise Inner instance
        list.add(new Inner());
    }

    //called by thread 2
    public void doSomething() {
        for (Inner i : list) {
            // access non-final field
            Object ref = i.ref;
            // do something
            // ...
            // ...

            // potentially set i.ref
        }
    }

    private static class Inner {
        // initialised by thread 1
        Object ref = null;
    }
}

Assuming doSomething() is always called by thread 2, is this safe? What guarantees are made about what thread 2 will see the first time it's accessed? Is there any possibility thread 2 would see something that's non-null?

Where in the JMM are the semantics around this situation described?

Eugene · Accepted Answer · 2018-10-02T13:11:13.190

1

JVM will guarantee that you don't see out of thin air values, so anything other than null it not possible, in case that List is not empty (in this example, of course). If there would have been a different thread involved (let's say Thread3) that would alter your list (add elements to it), Thread2 could see those updates. Just note that individual methods of CopyOnWriteArrayList are thread safe; your method doSomething is not.

See the JLS for the specifics or the excellent (and rather complicated, may be just to me) Aleksey article.

edited Oct 02 '18 at 13:11

answered Sep 25 '18 at 11:24

Eugene

117,005
15
201
306

Thanks. On the point: "JVM will guarantee that you don't see out of thin air values, so anything other than null it not possible" - is this guaranteed anywhere in JMM? – user2248785 Sep 25 '18 at 11:30
@user2248785 what you are looking for is the `JLS` as the official language spec, not the `JMM` - which is *for compiler writers* (and neither of us is such). This term `out of thin air` is mentioned in the `JLS` *once only*; it's a term I first read about in a book by Brian Goetz - I think it is derived from multiple other places, like `default` values and the like – Eugene Sep 25 '18 at 11:48
Thanks, I believe the OoTA guarantee is the one I was looking for. This is described in [JLS-17.4.8](https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.8). Will accept your answer if you are happy to add the reference. – user2248785 Oct 02 '18 at 08:19
@user2248785 which part exactly do you have in mind about that JLS btw? I am reading it now... – Eugene Oct 02 '18 at 08:25
I think the section I referenced above covers it. (i.e. [JLS-17.4.8](https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.8)) There's also an example "Example 17.4.8-1. Happens-before Consistency Is Not Sufficient" which illustrates the concept of OoTA consistency. I also found this [separate document](https://shipilev.net/blog/2014/jmm-pragmatics/#_part_iv_out_of_thin_air) a good explanation - it references the same JLS section. – user2248785 Oct 02 '18 at 09:57
@user2248785 I added the references for completeness, but truth being said I probably need to re-read them to fully understand... – Eugene Oct 02 '18 at 13:12

Andrew Tobilko · Answer 2 · 2018-09-25T11:22:56.117

0

Talking about safe publication makes sense only when you are initialising a field with a meaningful object that has the state. Then, improper publication may lead to observing a partially constructed object.

In this case, null doesn't convey any state. It can be considered an immutable object. Immutable objects don't have publication problems.

What guarantees are made about what thread 2 will see the first time it's accessed?

Thread 2 will see null when referring to i.ref.
Note that the list may be empty because Thread 1 may not have added an Inner to it yet.

Is there any possibility thread 2 would see something that's non-null?

No.

edited Sep 25 '18 at 11:22

answered Sep 25 '18 at 11:09

Andrew Tobilko

48,120
14
91
142

Thanks for the response. This was my suspicion. Are you able to reference this back to the JMM specification? I couldn't see anything specifically about this situation... – user2248785 Sep 25 '18 at 11:17

Safe initialisation of null reference

2 Answers2