Question: Consider the following class:

```
public class MyClass
{
    private MyObject obj;

    public MyClass()
    {
        obj = new MyObject();
    }

    public void methodCalledByOtherThreads()
    {
        obj.doStuff();
    }
}

```

Since obj was created on one thread and accessed from another, could obj be null when methodCalledByOtherThread is called? If so, would declaring obj as volatile be the best way to fix this issue? Would declaring obj as final make any difference?

Edit:
For clarity, I think my main question is:
Can other threads see that obj has been initialized by some main thread or could obj be stale (null)?

Answer: 
For the `methodCalledByOtherThreads` to be called by another thread and cause problems, that thread would have to get a reference to a `MyClass` object whose `obj` field is not initialized, ie. where the constructor has not yet returned.

This would be possible if you leaked the `this` reference from the constructor. For example

```
public MyClass()
{
    SomeClass.leak(this); 
    obj = new MyObject();
}

```

If the `SomeClass.leak()` method starts a separate thread that calls `methodCalledByOtherThreads()` on the `this` reference, then you would have problems, but this is true regardless of the `volatile`.

Since you don't have what I'm describing above, your code is fine.
The originally picked answer by @Sotirios Delimanolis is wrong. @ZhongYu 's answer is correct.

There is the visibility issue of the concern here. So if MyClass is published unsafely, anything could happen.

Someone in the comment asked for evidence - one can check Listing 3.15 in the book *Java Concurrency in Practice*:

```
public class Holder { 
    private int n;

    // Initialize in thread A
    public Holder(int n) { this.n = n; }

    // Called in thread B
    public void assertSanity() { 
        if (n != n) throw new AssertionError("This statement is false."); 
    }

}

```

Someone comes up an example to verify this piece of code:

[coding a proof for potential concurrency issue](https://stackoverflow.com/questions/17728710/coding-a-proof-for-potential-concurrency-issue)

As to the specific example of this post:

```
public class MyClass{
    private MyObject obj;

    // Initialize in thread A
    public MyClass(){
        obj = new MyObject();
    }

    // Called in thread B
    public void methodCalledByOtherThreads(){
        obj.doStuff();
    }
}

```

If MyClass is initialized in Thread A, there is no guarantee that thread B will see this initialization (because the change might stay in the cache of the CPU that Thread A runs on and has not propagated into main memory).

Just as @ZhongYu has pointed out, because the write and read happens at 2 independent threads, so there is no `happens-before(write, read)` relation.

To fix this, as the original author has mentioned, we can declare private MyObject obj as volatile, which will ensure that the reference itself will be visible to other threads in timely manner
(<https://www.logicbig.com/tutorials/core-java-tutorial/java-multi-threading/volatile-ref-object.html>) .