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.
This code is fine because the reference to the instance of `MyClass` can't be visible to any other threads before the constructor returns.

Specifically, the [happens-before relation](http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.5) requires that the visible effects of actions occur in the same order as they're listed in the program code, so that in the thread where the `MyClass` is constructed, `obj` must be definitely assigned before the constructor returns, and the instantiating thread goes directly from the state of not having a reference to the `MyClass` object to having a reference to a fully-constructed `MyClass` object.

That thread can then pass a reference to that object to another thread, but all of the construction will have transitively happened-before the second thread can call any methods on it. This might happen through the constructing thread's launching the second thread, a `synchronized` method, a `volatile` field, or the other concurrency mechanisms, but all of them will ensure that all of the actions that took place in the instantiating thread are finished before the memory barrier is passed.

Note that if a reference to `this` gets passed out of the class inside the constructor somewhere, that reference might go floating around and get used before the constructor is finished. That's what's known as *unsafe publishing* of the object, but code such as yours that doesn't call non-`final` methods from the constructor (or directly pass out references to `this`) is fine.