Question

Knowing that

Reads and writes are atomic for all variables declared volatile

Question1: Can this be understood as if

private volatile int x = 0;

x++; operation is atomic?

And that

Marking variable volatile does not eliminate all need to synchronize
atomic actions, because memory consistency errors are still possible.

Question2: I wonder under what circumstances (if any) it is possible to see a variable marked volatile and not see any methods of blocks marked synchronized (that attempt to access/ modify the variable)?

In other words, should all variables that need to be protected from concurrent modification be marked volatile?

Answer 1

The volatile only gives you additional visibility guarantees, atomic writes/reads for longs/doubles (otherwise not guaranteed by the JLS, yes) and some memory order guarantees. No synchronization (it is possible though to build synchronization blocks starting with just volatile – Dekker’s algorithm )
So no, it does not help you with x++ – that’s still a read, inc and write and needs some form of synchronization.

One example of volatile is the famous double-checked locking, where we avoid synchronization most of the time because the ordering guarantees are all we need:

private volatile Helper helper = null;
public Helper getHelper() {
    if (helper == null) {
        synchronized(this) {
            if (helper == null) {
                helper = new Helper();
            }
        }
    }
    return helper;
}

An example where there’s absolutely no synchronization involved, is a simple exit flag, here it’s not about ordering guarantees but only about the guaranteed visibility

public volatile boolean exit = false;
public void run() {
   while (!exit) doStuff();
   // exit when exit set to true
}

If another thread sets exit = true the other thread doing the while loop is guaranteed to see the update – without volatile it may not.