Java: Is volatile / final required for reference to synchronized object?

Question

This seems a pretty basic issue, but I cannot find a clear confirmation.

Let's say I have a class properly synchronized in itself:

public class SyncClass {

   private int field;

   public synchronized void doSomething() {
       field = field * 2;
   }

   public synchronized void doSomethingElse() {
       field = field * 3;
   }
}

If I need to have a reference to an instance of that class, shared between threads, I do still need to declare that instance volatile or final , am I right? As in:

public class MainClass { // previously OuterClass

    public static void main(String [ ] args) {

        final SyncClass mySharedObject = new SyncClass();

        new Thread(new Runnable() {
            public void run() {
                mySharedObject.doSomething();
            }
       }).start();

       new Thread(new Runnable() {
            public void run() {
                mySharedObject.doSomethingElse();
            }
       }).start();
    }
}        

Or, if mySharedObject cannot be final, because its instantiation depends on some other conditions (interaction with GUI, info from socket, etc.), not known beforehand:

public class MainClass { // previously OuterClass

    public static void main(String [ ] args) {

        volatile SyncClass mySharedObject;

        Thread initThread = new Thread(new Runnable() {
            public void run() {

            // just to represent that there are cases in which
            //   mySharedObject cannot be final
            // [...]
            // interaction with GUI, info from socket, etc.
            // on which instantation of mySharedObject depends

            if(whateverInfo)
                mySharedObject = new SyncClass();
            else
               mySharedObject = new SyncClass() {
                   public void someOtherThing() {
                     // ...
                   }
               }
            }
       });

       initThread.start();

       // This guarantees mySharedObject has been instantied in the
       //  past, but that still happened in ANOTHER thread
       initThread.join();

       new Thread(new Runnable() {
            public void run() {
                mySharedObject.doSomething();
            }
       }).start();

       new Thread(new Runnable() {
            public void run() {
                mySharedObject.doSomethingElse();
            }
       }).start();
    }
}        

Final or volatile are mandatory , the fact that MyClass synchronizes the access to its own members, does NOT exempt to take care in ensuring that the reference is shared among threads. Is that right?

Differences with Difference between volatile and synchronized in Java

1- The referred question is about synchronized and volatile as alternatives, for the same field/variable, my question is about how to correctly use an already properly synchronized class (ie synchronized has been choosen), considering implications needed to be considered by the caller, possibly using volatile/final on a reference of an already synchronized class.

2- In other words, the referred question/answers are about locking/volatile THE SAME OBJECT, my question is: how can I be sure different threads actually SEE THE SAME OBJECT? BEFORE locking/accessing it.

When the first answer of referred question refers explicitly to a volatile reference, it's about an immutable object without synchronization . The second answer limits itself to primitive types. I DID find them useful (see below), but not complete enough to shed any doubts on the case I'm giving here.

3- The referred answers are very abstract and scholarly explanations to a very open question, with quite no code at all; as I stated in the introduction I need to a clear confirmation to actual code referring a specific, while quite common, issue. They're related, sure, but just as a text book is related to a specific problem. (I actually read it before opening this question, and find it useful, yet I still need to discuss a specific application.) If text books resolved all problems/doubts people may have applying them, we probably wouldn't need stackoverflow at all.

Consider that, in multithreading, you cannot "just try it out", you need a proper understanding and be sure of details, because race conditions can go right a thousand times and then go horribly wrong the thousand + 1 time.

Answer 1

Yes you are right. It is necessary that you make access to the variable also thread-safe. You can do that either by making it final or volatile , or you ensure that all threads access that variable again inside a synchronous block. If you wouldn't do that, it might be that one thread 'sees' already the new value of the variable, but the other thread might still 'see' null , for example.

So regarding your example, you could sometimes get a NullPointerException when a thread accesses the mySharedObject variable. But this might only happen on multi-core machines with multiple caches.

Java Memory Model

The main point here is the Java Memory Model. It states a thread is only guaranteed to see a memory update of another thread if that update happens before the read of that state in the so-called happens-before relation . The happens-before relation can be enforced by using final , volatile , or synchronized . If you do not use any of these constructs a variable assignment by one thread is never guaranteed to be visible by any other thread.

You can think of threads to conceptually have local caches and as long as you do not enforce that caches of multiple threads are synchronized, a thread just reads and writes to its local cache. This might lead to the situation where two threads see completely different values when reading from the same field.

Note that there are some additional ways to enforce visibility of memory changes, for example, using static initializers. In addition, a newly created thread always sees the current memory of its parent thread, without further synchronization. So your example might even work without any synchronization, because the creation of your threads are somehow enforced to happen after the field has been initialized. However relying on such a subtle fact is very risky and can easily break if you later refactor your code without having that detail in mind. Further details about the happens-before relation are described (but hard to understand) in the Java Language Specification .

Answer 2

If I need to have a refence to an instance of that class, shared between threads, I do still need to declare that instance volatile or final, am I right?

Yes, you are right. In this case you have two shared variables:

private int field

private SyncClass mySharedObject

Because of the way you have defined SyncClass any reference to a SyncClass will give you the most up to date value of that SyncClass .

If you don't synchronize the access to mySharedObject correctly (a non-final, non-volatile) field and you change the value of mySharedObject you may get a mySharedObject which is out of date.

Answer 3

This depends entirely on the context of how this variable is shared.

Here is a simple example where it's fine:

class SimpleExample {
    private String myData;

    public void doSomething() {
        myData = "7";

        new Thread(() -> {
            // REQUIRED to print "7"
            // because Thread#start
            // mandates happens-before ordering.
            System.out.println(myData);
        }).start();
    }
}

Your given examples may fall under this case. 17.4.5 :

• If x and y are actions of the same thread and x comes before y in program order, then hb(x, y) .

• A call to start() on a thread happens-before any actions in the started thread.

In other words if the assignment to mySharedObject takes place on the same thread that starts the new thread, the new thread is mandated to see the assignment regardless of synchronization.

However, if you expect, for example, that init could be called on a thread that is different from the one that calls doSomething , then you may have a race condition.

public static void main(String[] args) {
    final OuterClass myOuter = new OuterClass();

    Thread t1 = new Thread( () -> myOuter.init(true)    );
    Thread t2 = new Thread( () -> myOuter.doSomething() );

    t1.start(); // Does t1#run happen before t2#run? No guarantee.
    t2.start(); // t2#run could throw NullPointerException.
}

The fact that SyncClass has synchronized methods is completely irrelevant with respect to guaranteed state of the mySharedObject reference. Reading that reference is performed outside the synchronized block.

When in doubt, use final or volatile . Whichever is appropriate.

Answer 4

Two things to keep in mind here for understanding:

1. Racing for your reference variable has no conceptual difference from that of a member field.
2. Sharing a reference variable requires careful handling of safe publication

Answer 5

It's not mandatory to use any of them but you should know about them if you want to write proper multi-threaded code.

Final

final means you cannot re-initialize that variable again, so when you say

final SyncClass mySharedObject = new SyncClass();

you cannot do the initialization of mySharedObject again in some other part of code like below

   mySharedObject = new SyncClass(); // throws compiler error

Even though you cannot re-assign mySharedObject reference to some other object, you can still update it's state (field counter variable) by calling methods on it because field is not final.

Synchronization and volatile are just constructs to ensure that any change to a shared mutable object (in this case updating a field counter) by one thread is visible to all other threads.

Synchronization

synchronized method means that any thread trying to invoke that method should acquire a lock on the object in which that method is defined.

So in your case, If thread-1 is trying to do mySharedObject.doSomething() , it will acquire lock on mySharedObject and thread-2 has to wait until thread-1 releases that lock on the same object to be able to do mySharedObject.doSomethingElse() ie using Synchronization at any given point of time, only ONE thread will update the state of the object. At the end of the method, just before releasing the lock all the changes done by thread-1 are flushed to main memory so that thread-2 can work on the recent state.

Volatile

volatile on the other hand ensures read/write visibility to all the threads. Any read and write to volatile variable are always flushed to main memory.

If your field variable inside SyncClass is volatile, any update like field++ by thread-1 is visible to thread-2 but I'm not sure how it applies to object references.

As volatile only guarantees visibility but not atomicity, it's possible that both thread-1 and thread-2 try to update field counter at the same time and the final updated value may not be proper.