Detailed explanation of atomicity and visibility examples in java concurrency
Concurrency is actually a decoupling strategy that helps us separate what to do (goal) and when to do (time). Doing so can significantly improve the application's throughput (get more CPU scheduling time) and structure (the program has multiple parts working together). Anyone who has done Java Web development knows that the Servlet program in Java Web adopts a single instance multi-threaded working mode with the support of the Servlet container, and the Servlet container handles concurrency problems for you.
Atomicity
Atoms are the smallest unit in the world and are indivisible. For example, a=0; (a is not a long and double type) This operation is inseparable, so we say that this operation is atomic operation. For example: a++; this operation is actually a = a + 1; it is separable, so it is not an atomic operation. Non-atomic operations will have thread safety problems, and we need to use synchronization technology (sychronized) to make it an atomic operation. An operation is an atomic operation, so we call it atomicity. Java's concurrent package provides some atomic classes, and we can understand the usage of these atomic classes by reading the API. For example: AtomicInteger, AtomicLong, AtomicReference, etc.
Visibility
Visibility refers to the visibility between threads, and the modified state of one thread is visible to another thread. That is the result of a thread modification. Another thread will be seen immediately. For example: variables modified with volatile will have visibility. Variables modified by volatile do not allow internal cache and reordering of threads, that is, directly modifying memory. So it is visible to other threads. However, one issue needs to be noted here: volatile can only make the content modified by it visibility, but it cannot guarantee that it is atomic. For example, volatile int a = 0; there is an operation a++ afterwards; this variable a has visibility, but a++ is still a non-atomic operation, and this operation also has thread safety problems.
Their relationship
Atomicity means whether an operation is split. Visibility means whether the operation result is visible to other threads. It seems that they have nothing to do with each other.
Example
package ;
/**
* Visibility analysis
* @author Administrator
*
*volatile will refuse the compiler to optimize its modified variables. There will be no reordering problem. volatile only affects visibility and not atomicity.
*If the following program is not added
*/
public class Test {
volatile int a = 1;
volatile boolean ready;
public class PrintA extends Thread{
@Override
public void run() {
while(!ready){
();
}
(a);
}
}
public static void main(String[] args) throws InterruptedException {
Test t = new Test();
PrintA().start();
//If the following two lines are not added with volatile, the order of execution is unpredictable. And the following two lines are atomic operations, but as a whole these two lines are not atomic operations. = 48; //This is an atomic operation, but the result is not necessarily visible. After adding volatile, it becomes visibility. = true;//Same }
}
If the variable a is not modified with volatile in the above program, the output result is likely to be 0.
Thank you for reading, I hope it can help you. Thank you for your support for this site!