Comparison between multithreaded CAS and synchronized

Business scenario ： You need to implement a counting function that supports concurrency

1、 The basic realization of counting function is ：

public class Increment{
    

　　private int count = 0;

　　public void add(){
      
　　		count++;  
　　}

}

2、 The above implementation is not safe in a concurrent environment , Therefore, modify the scheme 1 It's locking synchronized：

public class Increment{
    

　　private int count = 0;

　　public synchronized void add(){
      
　　		count++;  
　　	}

}

// Pessimistic locking , After locking, there can only be one thread for you to execute ++ operation , Other threads need to wait

// There will be no count The problem of inaccurate counting , Thread safety

3、 But the above implementation , Will serialize threads , Queue for lock 、 Lock 、 Processing data 、 Release the lock , And sending it seems unreasonable

Revise the plan 2 It's using Java Contract issuance concurrent Under the Atomic Atomic classes

public class Increment{
    

　　private AtomicInteger count = new AtomicInteger();

　　public synchronized void add(){
    

　　　　count.incrementAndGet();

　　}

}

// Multiple threads can execute concurrently AtomicInteger Of incrementAndGet() Method , hold count The sum of the values of 1 And return the latest value after accumulation

//Atomic The bottom layer of atomic class is unlocked CAS Mechanism , Ensure the safety of multi-threaded modification of a value

4、 Realization principle ：

（1） Each thread gets the current value first , And then one atom CAS operation , That's what atoms mean CAS The operation must be completed by itself , No interruptions ;

（2） stay CAS In operation , Compare the , The current value is the same as the value I just obtained , Whether it is equal or not , Yes means that no one has changed this value , Then set it to accumulate 1 The next value is ;

（3） Empathy , If someone is executing CAS when , Find that the value you obtained before is different from the current value , It means that someone else has modified the value , Lead to CAS Failure , After failure, enter a cycle , Get the value again , Re execution CAS operation .

5、CAS The problem of ：

Every time I compare , Found that the value was changed by others , Will enter the infinite repetition cycle . When a large number of threads are highly concurrent, it is equivalent to an empty loop , Self rotation , Performance and efficiency are not particularly good .

Java8 A new class of LongAdder, Try using segmentation CAS And the way of automatic segmented migration to improve the high concurrency of multithreading CAS Performance of operation . The core idea is the separation of hot spots , similar concurrentHashMap.