同步块中的原子变量

Question

I'm referring to the Java language but I think it can concern other languages as well.

The question is: does it make sense to put an atomic variable in a synchronized block? Or the fact that the synchronized block will not be executed by two threads at the same time is enough to guarantee that the operations performed in the synchronized block are atomic? (Example 1 vs. Example 2)

Example 1:

public class SharedVariables {
  public static AtomicInteger i;
}

public class MyThread extends Thread {
  public void run() {
    synchronized(SharedVariables.i) {
      i.getAndIncrement();
    }
  }
}

Example 2:

public class MyIntegerWrapper {
  public int i;
  public void increment() {
    this.i++;
  }
}

public class SharedVariables {
  public static MyIntegerWrapper i;
}

public class MyThread extends Thread {
  public void run() {
    synchronized(SharedVariables.i) {
      i.increment();
    }
  }
}

Answer 1

Not by itself no. But if you're doing an operation that involves a thread-safe class like AtomicInteger and other variables (even if they're other AtomicIntegers ), you might need to.

AtomicInteger guarantees that operations on it are thread-safe and atomic without you needing to do anything. But let's say that you increment one and decrement another, and their sum always needs to be the same. You have 2 atomic operations, but to combine them into a single atomic operation you'll need additional synchronization. Only then can you be sure that other threads will read a constant sum of those variables.

I'd still be careful when combining manual synchronization with java.util.concurrent classes, as there's most likely a far cleaner solution provided by the concurrent classes.

Answer 2

synchronized is not required in your first code, the guarantees of atomic variables are sufficient.

Your second code has one issue: the int variable is public, so you can't guarantee that it will always be called from a synchronized block.

Answer 3

原子变量使用非阻塞算法（它使用比较和交换机制），因此您不应在同步块内使用它，而应尝试尽可能使用原子变量以获得更好的性能。

Answer 4

In your examples its totally ok to use either AtomicInteger without synchronized or your MyIntegerWrapper inside synchronized .

But in general case it depends on your variable visibility scope. For example if you decided to use MyIntegerWrapper instead of AtomicInteger , then you must ensure that there is no other method which uses it without synchronization.

Also what to choose depends on how often is the variable modified by different threads. AtomoicInteger uses compare-and-set (or just cas) operation inside instead of synchronization. CAS is believed to be faster as there is less overhead comparing to entering synchronized block, however in a high contention case(when there lots of threads trying to modify this variable at the same time) synchronized block can be more efficient. Also synchronized gives jvm a space for some optimizations, like lock coarsering. So just keep that in mind when choosing AtomicInteger over synchronized .

Answer 5

In first example you use two synchronizes.

AtomicInteger implements " Non-blocking synchronization algorithm "

Exactly Look free algorithm that allows individual threads to starve but guarantees system-wide throughput.

This algorithm works with helping of machine instructions. For example in the x86 (since 80486) and Itanium architectures this is implemented as the compare and exchange (CMPXCHG) instruction.

Your key word "synchronized" is redundant and even does not allow to work Lock free algorithm which gives good advantages.

Therefore, in your case don`t use synchronized block, use AtomicInteger.