What causes Java SE multi-thread security issues?

Question

Maybe the code in the picture has a low probability of negative numbers, but if you add Thread.sleep(10); after the if statement, you can see the output of negative numbers

Answer 1

I don’t know what you are asking. It is normal for multiple threads to read a resource at the same time and have desynchronization problems. This is because one thread may be getting a value while another thread is writing a value, which will cause synchronization problems.

There are many solutions. The most stupid one is to directly add synchronization to the code block and lock the entire code. The better one is to use thread-safe classes, such as AtomInteger, to ensure synchronization; if you have a lot of research on multi-threading, you can even Only a few locks are needed to get the job done.

Answer 2

The calling order of threads is not guaranteed to be in order. The fundamental reason lies in the switching between threads when the JVM coordinates resources.

Answer 3

The essential reason is that the CPU reorders instructions in order to improve efficiency

Answer 4

There is no synchronization of num. There is no guarantee that after the current thread changes the value of num, other threads can see it immediately. The questioner can learn about the Java memory model.
Take the subject's code as an example. Assume that num=1 is executed to the end, and three threads execute the if judgment at the same time, and all can judge to pass, then a negative number may appear.

Answer 5

1. Memory visibility
2. Atomicity of modifications

Since num is a static variable, it will be stored in the heap. When the run() method is executed, a copy will be copied to the stack for storage. When multiple threads modify it, the same copy may be obtained at the same time, but Due to the order of execution, one thread modifies and writes the variable. Although num in the heap has changed, other threads do not know it and they will continue to modify that copy. Then the modification is written to the heap, which will overwrite the modifications of the previous thread, leading to state inconsistency.
So what if thread safety can be ensured? Then make sure that the visibility of the heap area modification is guaranteed before modifying num, and take a copy before modifying it (even if it has been taken before). This can be guaranteed by the volatile keyword.

Atomicity, since the actual execution of num-- is two operations, there will be an execution order problem. Even though I mentioned earlier that volatile is used to ensure visibility. However, there will still be situations where modifications are overwritten by other threads, but the chance is smaller. How to ensure atomicity, you can use the synchronized keyword, Lock mechanism, and JDK concurrency toolkit, etc. For this situation, the simplest solution is

private static AtomicInteger num=new AtomicInteger(100);