Shulou(Shulou.com)06/02 Report--

This article mainly explains "the introduction of java multithreaded CAS". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "the introduction of java multithreaded CAS".

1 CAS explanation

In our work, we often need to face the problem of multi-thread counting. Our first reaction is to use "synchronized" to control concurrency.

@ Slf4jpublic class CASDemo extends Thread {private static int t = 0; @ Override public void run () {increment (); log.info ("- {} -", t);} private synchronized static void increment () {tweezers;} public static void main (String [] args) {for (int I = 0; I < 100) CASDemo casDemo +) {CASDemo casDemo = new CASDemo (); casDemo.start ();}}

The results are as follows:

From the above results, it is in line with our expectations, 100 threads executed once, and finally t is 100. But is this the best implementation mechanism? We know that "synchronized" is a synchronous lock, even if jdk6 has optimized it later (see another article: synchronized principle Analysis of the basics of java multithreading). It is just used to count whether it is too big and too useless. Is there a more elegant solution?

@ Slf4jpublic class CASDemo extends Thread {private static AtomicInteger t = new AtomicInteger (0); @ Override public void run () {log.info ("- {} -", t.incrementAndGet ());} public static void main (String [] args) {for (int I = 0; I < 100; iTunes +) {CASDemo casDemo = new CASDemo () CasDemo.start ();}

The results are as follows:

From the point of view of the results, the first and second results are the same. Why recommend the first method? Because the second kind uses a lock-free "compareAndSwap", that is, "CAS", since "CAS" is unlocked, how to ensure thread safety.

"compareAndSwap" literally, this process certainly involves two actions: compare and replace, the specific steps are as follows:

(1) the thread reads the value of I from memory. If the value of I at this time is 0, let's call it k, that is, k = 0 at this time.

(2) make j = k + 1.

(3) if the value of k is equal to the value of I in memory, it means that no other thread has modified the value of I, then we write the value of j (at this time is 1) into memory; if it is not equal (meaning that the value of I has been modified by other threads), we do not write the value of j to memory, but jump back to step 1 to continue the three operations. The specific source codes are as follows:

At the same time, the whole "CAS" is atomic, corresponding to a hardware instruction of the operating system. Although there seems to be a lot of operations in it, the operating system can guarantee that it is executed atomically.

Through the above process explanation, we can find that it is impossible to get the same K value from memory at the same time, and then submit it to memory by + 1 respectively, so as to ensure thread safety.

But we still face the question of who secretly changed my value.

For example, when thread An is about to perform the third step, thread B increases the value of I by 1, and then immediately subtracts the value of I by 1, and then thread An executes the third step. Thread A thinks that no one has changed the value of I, because the value of I has not changed. And this is what we usually call the ABA problem. For the value of the basic type, changing the number back to the original value does not have much effect, but if it is for the reference type, it will have a big impact.

How to solve this problem? -- version control (see optimistic locks).

For example, every time a thread changes the value of a reference, the version is updated, and although the two threads hold the same reference, they have different versions, so we can prevent ABA problems. The class AtomicStampedReference is provided in Java, so version control can be done.

Give me a demo.

/ / Construction method, pass in reference and stamp public AtomicStampedReference (V initialRef, int initialStamp) / / return reference public V getReference () / / return version stamp public int getStamp () / / if the current reference is equal to the expected value and the current version stamp is equal to the expected version stamp, update the new reference and new version stamp to memory public boolean compareAndSet (V expectedReference, V newReference) Int expectedStamp, int newStamp) / / if the current reference is equal to the expected reference, update the new version stamp to the memory public boolean attemptStamp (V expectedReference, int newStamp) / / set the new reference and version stamp public void set (V newReference, int newStamp) for the current reference

Public static void main (String [] args) {String str1 = "aaa"; String str2 = "bbb"; AtomicStampedReference reference = new AtomicStampedReference (str1,1); reference.compareAndSet (str1,str2,reference.getStamp (), reference.getStamp () + 1); System.out.println ("reference.getReference () =" + reference.getReference ()); boolean b = reference.attemptStamp (str2,reference.getStamp () + 1) System.out.println ("b:" + b); System.out.println ("reference.getStamp () =" + reference.getStamp ()); boolean c = reference.weakCompareAndSet (str2, "ccc", 4, reference.getStamp () + 1); System.out.println ("reference.getReference () =" + reference.getReference ()); System.out.println ("c =" + c) } output: reference.getReference () = bbbb: truereference.getStamp () = 3reference.getReference () = bbbc = falsec Why output false, because the version stamps are inconsistent

Optimization of CAS by 2jdk8

Because there is no locking on the method using this CAS mechanism, all threads can enter the increment () method. If too many threads enter this method, there will be a problem: every time a thread wants to perform the third step, the value of I is always modified, so the thread goes back to the first step and starts all over again.

This leads to a problem: because the thread is too dense, too many people want to change the value of I, and most people will change it unsuccessfully, consuming resources there in vain.

In order to solve this problem, Java8 introduced a cell [] array, which works like this: if there are 5 threads to increment I, because there are 5 threads, not many, and the chance of conflict is small, then let them use CAS as usual. However, if there are 100 threads to perform self-increment operations on I, at this time, conflicts will be greatly increased, and the system will assign these threads to different cell array elements. If cell [10] has 10 elements, and the element initialization value is 0, then the system will divide the 100 threads into 10 groups, each group will do self-increment operation on one element of the cell array, so that in the end, The values of the 10 elements of the cell array are all 10. The system is summarizing the values of these 10 elements to get 100. this is equivalent to 100 threads doing 100 self-increment operations on I.

In short, jdk8 uses a similar method to reduce lock granularity to improve performance in the case of high concurrency.

Thank you for your reading, the above is the content of "introduction of java multithreaded CAS". After the study of this article, I believe you have a deeper understanding of the introduction of java multithreaded CAS, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.