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: 
It depends on whether the reference is published "unsafely". A reference is "published" by being written to a shared variable; another thread reads the variable to get the reference. If there is no relationship of `happens-before(write, read)`, the publication is called unsafe. An example of unsafe publication is through a non-volatile static field.

@chrylis 's interpretation of "unsafe publication" is not accurate. Leaking `this` before constructor exit is orthogonal to the concept of unsafe publication. 

Through unsafe publication, another thread may observe the object in an uncertain state (hence the name); in your case, field `obj` may appear to be null to another thread. Unless, `obj` is `final`, then it cannot appear to be null even if the host object is published unsafely.

This is all too technical and it requires further readings to understand. The good news is, you don't need to master "unsafe publication", because it is a discouraged practice anyway. The best practice is simply: never do unsafe publication; *i.e.* never do data race; *i.e.* always read/write shared data through proper synchronization, by using `synchronized, volatile` or `java.util.concurrent`.

If we always avoid unsafe publication, do we still *need* `final` fields? The answer is no. Then why are some objects (e.g. `String`) designed to be "thread safe immutable" by using final fields? Because it's assumed that they can be used in malicious code that tries to create uncertain state through deliberate unsafe publication. I think this is an overblown concern. It doesn't make much sense in server environments - if an application embeds malicious code, the server is compromised, period. It probably makes a bit of sense in Applet environment where JVM runs untrusted codes from unknown sources - even then, this is an improbable attack vector; there's no precedence of this kind of attack; there are a lot of other more easily exploitable security holes, apparently.
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>) .