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

This article introduces the relevant knowledge of "what is the principle and function of LockSupport". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

What is LockSupport?

Basic thread blocking primitive for creating locks and other synchronization classes.

Using it, you can use it to build locks for specific logic. The AQS framework for jdk concurrent packages depends on it.

What is the function of LockSupport?

It provides thread blocking and awakening.

Every time a thread uses it, it can be treated as if the thread maintains a binary semaphore, which can be compared to holding a license.

Call the pack () method, if there is a license, consume it and return directly, and the thread continues to execute. On the contrary, it is blocked.

Call the unpack () method, which becomes available if the license is not available, and nothing else if it is available. In other words, licenses cannot be accumulated multiple times.

Because there is an intermediate medium like license, it avoids the situation of thread deactivation caused by invocation of Thread.suspend () and Thread.resume (), which are not recommended by threads. My personal understanding here is the complexity and latency of thread scheduling. For example, thread dormancy and pause cannot be done immediately, rearrangement between commands, and so on. Also, park () has additional support for thread interruptions and timeouts.

An additional idiom is mentioned in the documentation for the class, which says that the pack () call returns "for no reason", causing the thread to execute inexplicably. Then the idiom is to wrap the pack () logic in a loop, and the condition for the loop to exit is the condition for the thread to wait for synchronization permission. This is equivalent to a spin optimization, but requires the cooperation of unpack ().

A simple example of blocking threads:

Public static void main (String [] args) {LockSupport.park (); System.out.println ("the main thread blocks and does not print the current message");}

A common usage paradigm:

Public static void main (String [] args) throws InterruptedException {Thread busThreadJim = new Thread (()-> {System.out.println ("Parameter check..."); System.out.println ("execute business logic..."); System.out.println ("enter state sync point"); LockSupport.park ("thread is blocked due to possible reason A") System.out.println ("syncpoint completion, progressive business closure phase"); System.out.println ("enter the end of the last sync point"); LockSupport.park ("report the current working level or status of this thread xxxx"); System.out.println ("business logic completion exit");}) BusThreadJim.start (); System.out.println ("Control the thread or monitor thread to start doing other logic..."); Thread.sleep (2000); System.out.println ("check whether the worker thread is blocked, why: + LockSupport.getBlocker (busThreadJim)); LockSupport.unpark (busThreadJim) / / if the thread scheduling is slow LockSupport.getBlocker gets the null / / that is, the worker thread has not blocked the System.out.println ("you can send out some thread work information by blocking the object:" + LockSupport.getBlocker (busThreadJim)); System.out.println ("of course, sharing variables is also possible"); LockSupport.unpark (busThreadJim) System.out.println ("logical completion");}

Multiple unpack () can only be consumed once.

Public static void main (String [] args) throws InterruptedException {Thread worker = new Thread (()-> {System.out.println ("execute business logic."); System.out.println ("enter the state synchronization point."); LockSupport.park (); System.out.println ("synchronization point completed, progressive business closing phase.") LockSupport.park (); System.out.println ("Last Sync Point ends");}); worker.start (); LockSupport.unpark (worker); LockSupport.unpark (worker); Thread.sleep (2000); LockSupport.unpark (worker);}

When designing code logic, try to have clear blocking conditions, and then select functions with deadlines and objects that provide blocking information.

In theory, this class should not be used. But once used, it is estimated that the design is very basic, there must be complex logic on it. When there is no blocking information, logical troubleshooting will be fatal.

The difference between and wait/notify mechanism

Wait/notify must be used in synchronous code blocks, which alone feels limited.

Wait/notify manipulates the object and then maps it to the thread on which the object resides, thinking in a somewhat forgiving way.

Complex logic, especially nesting, is particularly suffocating.

Source implementation key public class LockSupport {private LockSupport () {} / / this class cannot instantiate / / all functions are proxied internally to implement private static final sun.misc.Unsafe UNSAFE; / / block the current thread public static void park () {UNSAFE.park (false, 0L) } / / associate the current thread of execution with a blocking object / / so that the object of concern becomes a thread rather than an object public static void park (Object blocker) {Thread t = Thread.currentThread (); setBlocker (t, blocker); UNSAFE.park (false, 0L); setBlocker (t, null) } / / below is a series of time-dependent functions public static void parkNanos (Object blocker, long nanos) {if (nanos > 0) {Thread t = Thread.currentThread (); setBlocker (t, blocker); UNSAFE.park (false, nanos); setBlocker (t, null) }} public static void parkUntil (Object blocker, long deadline) {Thread t = Thread.currentThread (); setBlocker (t, blocker); UNSAFE.park (true, deadline); setBlocker (t, null);} public static void parkNanos (long nanos) {if (nanos > 0) UNSAFE.park (false, nanos) } public static void parkUntil (long deadline) {UNSAFE.park (true, deadline);} / / Wake up target is also the same thread as blocking concern public static void unpark (Thread thread) {if (thread! = null) UNSAFE.unpark (thread) } / / return blocking object information / / if there is a frequent pack, then the object may be changing all the time, and its life cycle will be relatively short, only the most recent blocking information public static Object getBlocker (Thread t) {if (t = null) throw new NullPointerException (); return UNSAFE.getObjectVolatile (t, parkBlockerOffset);}}

A noteworthy concern is the information acquisition of blocker, which directly manipulates memory, because the thread is blocked and can only be obtained through this mechanism.

This is the end of the content of "what is the principle and function of LockSupport". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.