Java concurrent Programming principle and combat 20: A simple summary of thread safety issues

I. Conditions for thread safety issues• In a multi-threaded environment• Must have shared resources• Non-atomic operations on shared resources second, the way to solve the problem of thread safetysynchronized (bias Lock, lightweight lock, heavyweight lock)volatileatomic classes provided by JDK• Use lock (Shared lock, exclusive lock) Iii. the "* lock" of cognition • Biased lockJava bias Lock (biased Locking) is a multithreaded optimization introduced by JAVA6.
Bias Lock, as the name implies, it will be biased to the first access lock thread, if in the run process, the synchronization lock only one thread access, there is no multi-threaded contention, the thread is not required to trigger synchronization, in this case, the thread will be added a biased lock.
If another thread preemption lock is encountered during the run, the thread holding the biased lock is suspended, the JVM removes the biased lock on it, and restores the lock to a standard lightweight lock. • Lightweight LockThe lightweight lock is promoted by the bias, the bias lock runs in the case of a thread entering the synchronization block, when the second thread joins the lock contention, the bias lock will be upgraded to a lightweight lock;• Heavy-weight lockA heavyweight lock is a thread that converts a lock into a kernel state from the user's state. Allow the CPU to thread coordinate with the operating system • Re-entry lockre-entry means that any thread acquires the lock again after acquiring it and is not blocked by the lock. Associating a thread holder + counter, re-entering means that the granularity of the lock operation is "thread • Spin lock

The principle of spin-lock is very simple, if the thread holding the lock can release the lock resource in a short time, then those who wait for the competition lock will not need to do the switch between the kernel state and the user state into the blocking suspend state, they only need to wait (spin), wait for the lock thread to release the lock immediately, This avoids the consumption of switching between the user thread and the kernel.

But thread spin is the need to consume Cup, White is to let the cup do not work hard, if you have not been able to obtain the lock, the thread can not always occupy the cup spin do not work, so need to set a spin wait for the maximum time.

If the thread holding the lock executes longer than the maximum time of the spin wait and throws no release lock, it causes the thread of the other contention lock to get no lock during the maximum wait time, when the contention thread stops spinning into a blocking state.

• Shared Locksalso called a read lock, if the transaction T with the data object a plus s lock, then the transaction T can read a but cannot modify a, the other transaction can only a plus s lock, and cannot add x lock, until T release S lock on A. This ensures that other transactions can read a, but cannot make any modifications to a before T releases the S lock on a. • Exclusive LockExclusive Locks (Exclusive Locks, or X-locks), also known as write locks, exclusive locks, are a basic type of lock. • Exclusive LockExclusive Locks (Exclusive Locks, or X-locks), also known as write locks, exclusive locks, are a basic type of lock. • Read/write lockread-write lock is actually a special spin lock, it divides the audience of the shared resources into readers and writer, the readers only read access to the shared resources, the writer needs to write to the shared resources. • Fair Lock

Both fair and unfair lock queues are based on a doubly linked list maintained within the lock, and the table node node value is each thread that requests the current lock. A fair lock is a value that is taken from the head of the team each time.

• Non-fair lock

In the process of waiting for a lock, if any new thread is attempting to acquire a lock, there is a great chance of acquiring the lock directly.

• DeadlockDeadlock : A deadlock occurs when two or more threads wait for each other to release the lock. The Java Virtual machine does not detect and does not take measures to handle the deadlock situation, so multithreaded programming should take steps to avoid the advent of deadlocks. Once a deadlock occurs, the entire program does not have any exceptions, and no hints are given, except that all threads are plugged in. • Live lock The task or performer is not blocked because some conditions are not met, resulting in repeated attempts, failures, attempts, and failures. The difference between a live lock and a deadlock is that the entity that is in a live lock is constantly changing state, so-called "live", while the entity in the deadlock behaves as a wait; a live lock may be unlocked by itself, and a deadlock cannot. • Optimistic lock

Optimistic lock is a kind of optimistic thinking, that is, read more write less, encountered concurrent write the possibility of low, every time to take the data when they think others will not be modified, so will not lock, but in the update will be judged during this period when others have to update this data, to take in writing, read the current version number, Then the lock operation (compare with the previous version number, if the same update), if it fails, repeat the read-compare-write operation.
Optimistic locks in Java are basically implemented by CAS, which is an updated atomic operation that compares the current value to whether the value passed in is the same as if it was updated or failed.

• Pessimistic lockpessimistic lock is pessimistic thinking, that is, write more, encountered concurrent write high probability, every time to take the data when they think others will be modified, so every time in reading and writing data will be locked, so that others want to read and write this data will block until the lock. The pessimistic lock in Java is the lock in the SYNCHRONIZED,AQS framework is the first attempt to get the CAs optimistic lock to obtain the lock, can not be obtained, will be converted to pessimistic locks, such as retreenlock.

Java concurrent Programming principle and combat 20: A simple summary of thread safety issues