Atomic Variables in Java

In programming, variables are basic component, which used to store data. When a program start running, CPU initialize locations for the variables in the main memory. These locations are accessed by the CPU to store data, read data, or modify the existing data and puts back into the same memory location. This works in single thread but nowadays, in the era of multi-core, multi-CPU, multi-level caches it won't work correctly.



When several threads read the value at the same time and also try to modify it, then it introduces a race condition. Sometime, the value might only be stored in local CPU cache memory and not be visible to other CPUs/cores, which create a visibility problem. That's why many programmers refer to store a local copy of a variable in a thread, which is very unsafe.

To try to solve this problem, java introduce Atomic variables, which assist in writing lock and wait-free algorithms. An algorithm requiring only partial threads for constant progress is lock-free.






In a wait-free algorithm, all threads make progress continuously, even in cases of thread failure or delay. Lock and wait-free algorithms are also known as nonblocking algorithms. Nonblocking algorithms are used for process and thread scheduling at the operating system and Java virtual machine levels.

The java.util.concurrent.atomic package defines classes have the "atomic" prefix in their names. All classes have get and set methods that work like reads and writes on volatile variables. There are different types of atomic variables available in the java.util.concurrent.atomic package, including:
  • AtomicBoolean
  • AtomicInteger
  • AtomicIntegerArray
  • AtomicIntegerFieldUpdater
  • AtomicLong
  • AtomicLongArray
  • AtomicLongFieldUpdater
  • AtomicReference

In the Java language, synchronization coordinates access to shared thread fields and only allows threads holding locks to access and modify variables protected by the lock. This thread’s modifications are visible to the thread that follows, but only after the thread releases the lock.
For example, when thread A holds a lock. A is only able to access and make changes to variables protected by this lock. If thread B holds this lock after A, then only B can view A’s changes on the variables protected by that particular lock.
The main problem with locking occurs when B attempts to acquire a lock held by A. In this case, B is blocked to wait until the lock is available. Nonblocking algorithms resolve this problem.
Internally, the atomic classes make heavy use of compare-and-swap. An atomic instruction directly supported by most modern CPUs. Those instructions usually are much faster than synchronizing via locks.
The main purpose behind building atomic classes is to implement nonblocking data structures and their related infrastructure classes. Atomic classes do not serve as replacements for java.lang.Integer and related classes.
Most java.util.concurrent package classes use atomic variables instead of synchronization, either directly or indirectly. Atomic variables also are used to achieve higher throughput, which means higher application server performance.

Comments