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

Today, I will talk to you about the meaning of deadlocks, live locks and hunger in Java concurrency. Many people may not know much about it. In order to make you understand better, the editor summarized the following content for you. I hope you can get something from this article.

Solution

Deadlock refers to the phenomenon that two or more processes (or threads) wait for each other because of competing for resources during execution. If there is no external force, they will not be able to push forward.

If the thread is not intelligent enough and adheres to the principle of "humility" and actively releases the resources to others, it will cause the resources to jump constantly between the two threads, and no one thread can get all the resources to execute normally at the same time. This situation is called a livelock.

Hunger means that one or more threads cannot get the resources they need for a variety of reasons, resulting in a constant inability to execute. For example, its thread priority may be too low, and the high-priority thread constantly grabs the resources it needs, making the low-priority thread unable to work.

Supplementary deadlock

Refers to two or more processes (or threads) in the execution process, due to competition for resources caused by a mutual waiting phenomenon, if there is no external force, they will not be able to push forward. At this point, it is said that the system is in a deadlock state or the system has a deadlock, and these processes that are always waiting for each other are called deadlock processes.

The cause of deadlock

Compete with each other for shared resources

Four conditions for deadlock

1. Mutex condition: shared resources are occupied by a thread

two。 Request and hold condition (possession and wait): when a process is blocked by a request for a resource, it does not release the acquired resource.

3. Inalienable condition (non-preemptive): the process has acquired resources and cannot be deprived until it is used up.

4. Loop wait condition: multiple threads loop waiting for resources, and it is a loop waiting for each other

How to solve the deadlock?

You only need to break one of the above four conditions.

1. Request and retention conditions: enlarge the lock range and remove preemption of resources

two。 No deprivation: replace it with a reentrant lock ReentrantLock

3. Loop wait: change it to a sequential lock to avoid loop waiting

4. Mutex is a multithreaded feature, so this condition cannot be avoided.

Live lock

Thread 1 can use resources, but it is polite to let other threads use resources first, and thread 2 can also use resources, but it is very gentlemanly and allows other threads to use resources first. So you let me, I let you, the last two threads can't use the resource. The livelock will not be blocked, but will constantly detect a condition that can never be true. In addition to the resources held by the process itself, processes in the livelock state continue to consume valuable CPU time.

The task or executor is not blocked, because some conditions are not met, resulting in repeated attempts, failures, attempts, failures. During this time, the state of the thread will keep changing.

hunger

It means that if thread T1 takes up the resource R, thread T2 requests to block R, so T2 waits. T3 also requests resource R, and when T1 releases the blockade on R, the system first approves T3's request, and T2 is still waiting. Then T4 requests to block R, and when T3 releases the blockade on R, the system approves T4's request. T2 may wait forever.

This is the unfair locking mechanism provided in ReentrantLock display locks (of course, ReentrantLock also provides a fair locking mechanism for users to decide which locking strategy to use according to specific usage scenarios). Unfair locking can improve throughput but will inevitably cause hunger in some threads.

The cause of hunger

[that is, the reason why the thread has been waiting but cannot execute]

1. High priority threads preempt resource threads

two。 Waiting for an object that is also permanently waiting for completion.

3. The thread is permanently blocked in a state waiting to enter the synchronous block because other threads can always access the synchronous block continuously before it (such as blocking in synchronized).

The difference between a live lock and a deadlock

Deadlocks will block, waiting for the other party to release resources, always in a blocked state; livelocks will constantly change the thread state to try to obtain resources.

The livelock may unlock itself, but not the deadlock.

The difference between deadlock and hunger

Processes are hungry because other higher-priority processes continue to request the same resources. Unlike deadlocks or live locks, hunger can be unlocked. For example, when other high-priority processes are terminated and no higher-priority processes arrive.

After reading the above, do you have any further understanding of what deadlocks, live locks, and hunger mean in Java concurrency? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.