Brief introduction of some concepts of lock in java development

Exclusive lock (exclusive lock)

The lock is exclusive. With an exclusive lock, the statement block can only be executed by one thread that acquires the lock, and other threads can only wait for the lock to be released and compete for the lock

Shared lock

Shared locks can be acquired by multiple threads at the same time and executed concurrently; (may be asked why multiple threads execute concurrently and still add locks, such as read locks and write locks. Read locks are shared locks that can be acquired by multiple threads at the same time Locks, read locks are to exclude write locks. When a thread acquires a read lock, other threads cannot acquire a write lock)

Read-write lock

Read lock: that is shared locks, multiple threads can acquire a read lock at the same time, when there is a thread when reading data, other threads can not write
write lock: After an exclusive lock, the thread acquires a write lock, other threads can not read
read can multithreading Concurrency, reading and writing, writing and reading, writing and writing are all mutually exclusive

Spin lock

Spin lock: refers to when a thread is acquiring a lock, if the lock has been acquired by other threads, then the thread will wait in a loop, and then constantly judge whether the lock can be acquired successfully, and will exit the loop until the lock is acquired;
The performance consumption of thread context switching is reduced, but if a thread holds the lock for too long, it will cause other threads waiting to acquire the lock to enter the loop waiting and consume CPU. Improper use will result in extremely high CPU usage;
if the lock acquisition time is too long, it will always cause the cpu to spin idle and consume resources. Therefore, we need to add a limited number of times to the spin, and can't let it spin continuously like this. If it exceeds this number of times, it will be suspended, but there is a possibility that a problem will occur, that is, the thread that occupied the lock just released the lock when we were just suspended (this is a special fate), then this It was very embarrassing. So there is an adaptive spin lock in JDK6

Adaptive spin lock

** Change the number of self-selection that was previously fixed and dead into dynamic, so that the number of spins is no longer fixed, but is judged based on the last spin time of the same lock and the lock owner.
If the thread spins successfully, the number of spins next time will be more, because we will think that since the last time waiting for success, then this spin is very likely to succeed, so the number of self-selected
threads will be increased If the spin fails, the number of times the lock will spin on the lock will be reduced next time. If many threads acquire the lock and fail to spin, it is likely that the thread may not spin at all the next time, directly jump over. So as not to waste CPU resources**

Bias lock

The biased lock is a solution to the performance consumption of locking and releasing the lock when there is very little thread competition or when only one thread acquires the lock and releases the lock; in order to reduce the resource waste of lock acquisition and release.
The biased lock only requires a CAS during initialization. If the current thread acquires the biased lock, the lock can be directly acquired at zero cost in the future without participating in lock competition; if there is competition from other threads, it will be upgraded to a lightweight lock

Lightweight lock

The CAS algorithm is used for data operations, and no locks will be added. If thread competition problems occur, the locks will be upgraded to heavyweight locks;
for example: thread b is in lock competition and finds that the lock has been occupied by thread a, then thread b does not enter the kernel state , Let the b thread spin, execute an empty loop, and wait for the a thread to release the lock. If, after completing the spin strategy, it is found that the a thread has not released the lock, or the c thread is occupied. Then the b thread tries to upgrade the lightweight lock to a heavyweight lock.
Advantages: Competing threads will not block, which improves the response speed of the program.
Disadvantages: If a thread cannot compete for a lock, it will always be stored in a spin-null execution state, consuming CPU

Heavyweight lock

The built-in lock is abstracted as a monitor lock (monitor) in Java. Before JDK 1.6, monitor locks can be thought of as directly corresponding to mutexes in the underlying operating system. The cost of this synchronization method is very high, including switching between kernel mode and user mode caused by system calls, and thread switching caused by thread blocking. Therefore, this kind of lock was later called a "heavyweight lock. For
example: synchronized uses a built-in lock, a heavyweight lock

Deadlock

Deadlock is a state of thread suspended animation caused by threads waiting to release the lock under the condition of multi-thread competition. The threads are always in a waiting state;
a necessary condition for deadlock

1. Mutually exclusive conditions; that is, there is competition between multiple threads for shared resources and a certain resource is only occupied by one process for a period of time
2. Request and hold conditions: When the thread is blocked, keep the acquired resources
3. Non-deprivation conditions: After locking, the resources will not be released after they have been used up, and they cannot be deprived. They can only release the resources after they are used up.
4. Loop waiting conditions: When a deadlock occurs, the waiting process must form a loop (similar to an infinite loop), causing permanent blockage.
   Basic method to solve deadlock
   1. Is to destroy one or more of the conditions that cause deadlock
   2. Acquire locks sequentially
   3. Abandon over time, such as using tryLock(long time, TimeUnit unit)

Fair lock and unfair lock

The queues of fair and unfair locks are based on a doubly linked list maintained internally by the lock. The value of the node Node of the table is each thread requesting the current lock. The fair lock is that the value is taken from the top of the team every time. Unfair locks. If any new thread attempts to acquire the lock while the thread is waiting for the lock, there is a high probability that the lock will be acquired directly at random rather than in the order in the queue.

other

• Livelock : Concessions between threads cause no one to execute

• Thread starvation : the thread cannot get the execution time slice of the CPU for a long time, and it cannot be executed all the time.

• Thread starvation : Due to thread priority or the occurrence of thread exclusive resources are not released, other threads can only be in a waiting blocking state

• Lock elimination: an optimization of jvm locks at compile time, for example, sometimes we do not actually write the code lock, but the lock to perform operations such as synchronization lock operations on local variables;
  that is to say non Synchronization on shared objects is invalid, so the runtime can do nothing. Synchronization may be unnecessary, which provides opportunities for optimization.
  Therefore, if the escape analysis finds that the object is non-escaping, the compiler can eliminate synchronization by itself.

• Lock coarsening: Usually in concurrent programming, we will minimize the lock strength as much as possible. However, in some cases, high-frequency locking and releasing locks will seriously affect performance problems, so multiple locks have been merged into A lock that combines each small range of locking operations into a lock that can cover the range of the original locks expands the performance loss caused by frequent locking and releasing operations.
  Lock coarsening tells us that everything has a degree. In some cases, we want to combine many lock requests into one request to reduce the performance loss caused by a large number of lock requests, synchronization, and release in a short time.

• Lock upgrade: For example, a lightweight lock is upgraded to a heavyweight lock; or a read lock is upgraded to a write lock,

• Lock downgrade: Write lock downgrade to read lock, which is only possible in development. It is not involved in JVM's lock optimization