JAVA-Concurrent programming-thread safety scenarios

This article mainly introduces Java in the concurrency environment, what are the scenarios for thread safety, note that threading problems are mainly caused by the memory model (in the basic article)

Directory

Valotile Visibility

CAS Lock-free programming

Built-in lock (sync keyword synchronied)

Show Lock (Lock)

Valotile Visibility

1 Two-tier semantics of the volatile keyword (once a shared variable is modified by volatile)

1.1 Ensures the visibility of different threads operating on this variable, that is, a thread modifies the value of a variable, which is visible to other threads

1.2 Command punch ordering is prohibited

2 Implementation principle (plus lock prefix for memory masking)

2.1 Ensure that the command reordering does not place the instructions behind the memory screen, nor does the preceding instruction be placed behind the memory barrier, that is, when the command is executed to the memory screen, the operation in front of it has all been done

2.2 It forces the modification of the cache to be immediately written to main memory

2.3 If it is a write operation, it causes the corresponding cache line in other CPUs to be invalid

3 use of the scene (need to ensure the atomic nature of the operation)

3.1 writes to a variable do not depend on the current value

3.2 The variable is not included in the invariant with other variables

4 Summary of visibility, not guaranteed atomicity, to a certain extent guaranteed order

CAS Lock-free programming

1 What is CAS no lock programming?

CAS has 3 operands, memory value V, old expected value A, new value B to be modified, and only when a=v, change memory value V to B, otherwise do nothing

2 Why the CAs no lock concept and mechanism (based on the defect of lock mechanism)

2.1 In multi-threaded competition, lock, release lock will lead to more context switching and scheduling delay, causing performance problems

2.2 A thread holding a lock causes all other threads that need this lock to hang

2.3 If a high-priority thread waits for a low-priority line Cheng causes the priority to be inverted, causing performance problems

3 CAs defects

3.1 ABA Problem If a value is a, programming B, and programming A, then checking with CAS will show that its value has not changed (workaround: Use version number)

3.2 Cycle time long, overhead, spin CAS if the long time is unsuccessful, it will bring a very large execution overhead to the CPU

3.3 Only the atomic operation of a shared variable can be guaranteed

4 Java support for CAS (Atomic)

Built-in lock (sync keyword synchronied)

Modification method	Function range	Action Object	Lock type	Code
code block	Code enclosed in curly braces {}	Object that calls this block of code	Object lock	Synchronied (this) {}
Method	The whole method	The object that called this method	Object lock	synchronied void Method () {}
Static methods	The entire static method	All objects of this class	Class lock	Synchronied static void Method () {}
Class	The section that follows the keyword	All objects of this class	Class lock	Synchronied (class name) {}

　　　　　

1 Rules (class and Object locks) Object Locks (mutually exclusive, different objects not mutually exclusive (re-entrant)) class lock (Mutex) object locks and class locks are not mutually exclusive, and non-synchronous methods do not affect

1.1 When two concurrent threads access the synchronized (this) (object lock) synchronization code block in the same object, only one thread can be executed for a period of time, while another thread can execute this code only after the current thread has finished executing

1.2 When a thread accesses an object's synchronized (this) (object Lock) synchronization line Cheng, other threads can still access other non-synchronized (this) blocks of code in this object

1.3 When a thread accesses an object's synchronized (this) (object lock) code block, other threads will block access to the other synchronized (this) synchronized code block in this object

Show Lock (Lock)

　　1 Lock interface

2 Reentrantlock re-entry lock provides the same mutex and memory visibility as the Sync keyword

3 Why Java should provide a lock so similar to the Sync keyword

　　　　3.1 Internal locks are different interrupts the process that is waiting to acquire the lock, and the thread must wait indefinitely in case the request lock fails

　　　　3.2 Memory locks must be freed in the code block that gets them, which simplifies the code well, but in some cases a more flexible locking mechanism provides better activity and performance

　　4 Advantages of Reentrantlock can poll and can be timed lock request, interruptible Lock acquisition operation

　　5 Reentrantreadwritelock read-write lock characteristics Reading-read not mutually exclusive, reading-writing mutex, write-write mutually exclusive)

5.1 readlock () read lock

5.2 Writelock () write lock

　　6 Choice of lock and synchronized

6.1 Lock is an interface, and synchronized is a keyword in Java, built-in language implementation

6.2 Synchronized When an exception occurs, a thread-occupied lock is automatically freed, and lock is an exception that needs to be released in the finally block, or it is likely to cause deadlocks

6.3 Lock allows the thread waiting for the lock to respond to interrupts, while synchronized does not, and the waiting thread waits until the synchronized is used.

6.4 Through lock to know if there is a successful acquisition of the lock, and synchronized can not do

　　　　6.5 Lock can improve the efficiency of multiple threads for read operations

JAVA-Concurrent programming-thread-safe scenarios