Get the App
SLTechnology News&Howtos  ›  Development  › 

What is the atomicity of the Java self-increasing operation?

Shulou Source: shulou.com Published: 2022-06-02 20:47:30 10月02日 Update

In this issue, the editor will bring you about the atomicity of Java self-increasing operation. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

Recently, there was a red-faced debate with a colleague at work over whether self-increment is atomic operation or not. The answer is no, that is, Java self-increment operation is not atomic operation.

1. First, let's take a look at what Bruce Eckel says:

In the JVM an increment is not atomic and involves both a read and a write. (via the latest Java Performance Tuning Newsletter)

The meaning is very simple, that is, self-increment in jvm is not an atomic operation, it includes a read operation and a write operation.

two。 The above may not convince you, if you want to be convincing, you must speak in code. Just like the culture of FaceBook: code wins the argument. Then let's look at a piece of code:

The following code uses 100 threads to perform the self-increment operation at the same time, each thread increments 100 times. If the self-increment operation is atomic, then the value of the finished amount is 10000. After running the code, you will find that the value of amount is less than 10, 000, which means that the self-increment operation is not atomic.

/ * @ author renrun.wu * / public class MultiThread implements Runnable {private int count; private int amount = 1; public MultiThread () {count = 100;} public MultiThread (int count) {this.count = count;} @ Override public void run () {for (int I = 0; I < count) ITunes +) {amount++;}} public static void main (String [] args) {ExecutorService executorService = Executors.newCachedThreadPool (); MultiThread multiThread = new MultiThread (); for (int I = 0; I < 100; iTunes +) {executorService.execute (multiThread);} executorService.shutdown () Try {Thread.sleep (60000);} catch (InterruptedException e) {e.printStackTrace ();} System.out.println (multiThread.amount);}}

3. If the above doesn't convince you, it doesn't matter. Let's decompile the self-increment operation and see how the java bytecode works

The following is a simple self-increment operation code

Public class Increment {private int id = 0; public void getNext () {id++;}}

Let's take a look at the decompiled Java bytecode, focusing on the Java bytecode inside the getNext () method.

Public class Increment extends java.lang.Object {public Increment (); Code:: aload_0: invokespecial # 1; / / Method java/lang/Object. "": () V: aload_0: iconst_0: putfield # 2; / / Field id:I: return public void getNext () Code:: aload_0 / / load the variable whose index is 0, in this case this: dup / / copy the object reference at the top of the current stack: getfield # 2 / / Field id:I, get the value of id and press it into the top of the stack: iconst_1 / / push the value of int type 1 to the top of the stack: iadd / / add the two elements of type int at the top of the stack and press their values into the top of the stack: putfield # 2; / / Field id:I, assign the value of the top of the stack to id: return}

Obviously, we can see that inside the getNext () method, there is a process of taking values first and then adding and assigning values to the class variable id. Therefore, we can say with certainty that the self-increment operation in Java is not atomic.

4. You may ask whether the self-increment operation of that local variable is atomic. Okay, let's take a look at the code:

Public class Increment {public void getNext () {int id = 0; id++;}}

Let's take a look at the decompiled Java bytecode, focusing on the Java bytecode inside the getNext () method.

Public class Increment extends java.lang.Object {public Increment (); Code:: aload_0: invokespecial # 1; / / Method java/lang/Object. "": () V: return public void getNext (); Code:: iconst_0: istore_1: iinc 1,1: return}

Compared with the self-increment operation of global variables, it is obvious that the self-increment operation of local variables has fewer getfield and putfield operations. And for local variables, it will not involve multithreaded operations in any case, so it is less important whether the self-increment operation of local variables is an atomic operation.

The above is the atomicity of the Java self-increment operation shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Tags: Atom variable code byte local method thread compile obvious content that is and argue analyze important blush anyway it doesn't matter professional two Apple Docker Huawei Linux macOS MariaDB Microsoft MySQL NVidia OPPO Reno Huawei MySQL MariaDB vpn Shulou Information