AQS源碼解讀----AbstractQueuedSynchronizer

来源:https://www.cnblogs.com/wha6239/archive/2023/05/25/17348446.html
-Advertisement-
Play Games

36 package cn.com.pep; 37 import java.util.concurrent.TimeUnit; 38 import java.util.concurrent.locks.AbstractOwnableSynchronizer; 39 import java.util. ...


  36 package cn.com.pep;
  37 import java.util.concurrent.TimeUnit;
  38 import java.util.concurrent.locks.AbstractOwnableSynchronizer;
  39 import java.util.concurrent.locks.Condition;
  40 import java.util.concurrent.locks.LockSupport;
  41 import java.util.ArrayList;
  42 import java.util.Collection;
  43 import java.util.Date;
  44 
  45 import sun.misc.Unsafe;
  46 
  47 /**
  48  * Provides a framework for implementing blocking locks and related
  49  * synchronizers (semaphores, events, etc) that rely on
  50  * first-in-first-out (FIFO) wait queues.  This class is designed to
  51  * be a useful basis for most kinds of synchronizers that rely on a
  52  * single atomic {@code int} value to represent state. Subclasses
  53  * must define the protected methods that change this state, and which
  54  * define what that state means in terms of this object being acquired
  55  * or released.  Given these, the other methods in this class carry
  56  * out all queuing and blocking mechanics. Subclasses can maintain
  57  * other state fields, but only the atomically updated {@code int}
  58  * value manipulated using methods {@link #getState}, {@link
  59  * #setState} and {@link #compareAndSetState} is tracked with respect
  60  * to synchronization.
  61  *
  62  * <p>Subclasses should be defined as non-public internal helper
  63  * classes that are used to implement the synchronization properties
  64  * of their enclosing class.  Class
  65  * {@code AbstractQueuedSynchronizer} does not implement any
  66  * synchronization interface.  Instead it defines methods such as
  67  * {@link #acquireInterruptibly} that can be invoked as
  68  * appropriate by concrete locks and related synchronizers to
  69  * implement their public methods.
  70  *
  71  * <p>This class supports either or both a default <em>exclusive</em>
  72  * mode and a <em>shared</em> mode. When acquired in exclusive mode,
  73  * attempted acquires by other threads cannot succeed. Shared mode
  74  * acquires by multiple threads may (but need not) succeed. This class
  75  * does not &quot;understand&quot; these differences except in the
  76  * mechanical sense that when a shared mode acquire succeeds, the next
  77  * waiting thread (if one exists) must also determine whether it can
  78  * acquire as well. Threads waiting in the different modes share the
  79  * same FIFO queue. Usually, implementation subclasses support only
  80  * one of these modes, but both can come into play for example in a
  81  * {@link ReadWriteLock}. Subclasses that support only exclusive or
  82  * only shared modes need not define the methods supporting the unused mode.
  83  *
  84  * <p>This class defines a nested {@link ConditionObject} class that
  85  * can be used as a {@link Condition} implementation by subclasses
  86  * supporting exclusive mode for which method {@link
  87  * #isHeldExclusively} reports whether synchronization is exclusively
  88  * held with respect to the current thread, method {@link #release}
  89  * invoked with the current {@link #getState} value fully releases
  90  * this object, and {@link #acquire}, given this saved state value,
  91  * eventually restores this object to its previous acquired state.  No
  92  * {@code AbstractQueuedSynchronizer} method otherwise creates such a
  93  * condition, so if this constraint cannot be met, do not use it.  The
  94  * behavior of {@link ConditionObject} depends of course on the
  95  * semantics of its synchronizer implementation.
  96  *
  97  * <p>This class provides inspection, instrumentation, and monitoring
  98  * methods for the internal queue, as well as similar methods for
  99  * condition objects. These can be exported as desired into classes
 100  * using an {@code AbstractQueuedSynchronizer} for their
 101  * synchronization mechanics.
 102  *
 103  * <p>Serialization of this class stores only the underlying atomic
 104  * integer maintaining state, so deserialized objects have empty
 105  * thread queues. Typical subclasses requiring serializability will
 106  * define a {@code readObject} method that restores this to a known
 107  * initial state upon deserialization.
 108  *
 109  * <h3>Usage</h3>
 110  *
 111  * <p>To use this class as the basis of a synchronizer, redefine the
 112  * following methods, as applicable, by inspecting and/or modifying
 113  * the synchronization state using {@link #getState}, {@link
 114  * #setState} and/or {@link #compareAndSetState}:
 115  *
 116  * <ul>
 117  * <li> {@link #tryAcquire}
 118  * <li> {@link #tryRelease}
 119  * <li> {@link #tryAcquireShared}
 120  * <li> {@link #tryReleaseShared}
 121  * <li> {@link #isHeldExclusively}
 122  * </ul>
 123  *
 124  * Each of these methods by default throws {@link
 125  * UnsupportedOperationException}.  Implementations of these methods
 126  * must be internally thread-safe, and should in general be short and
 127  * not block. Defining these methods is the <em>only</em> supported
 128  * means of using this class. All other methods are declared
 129  * {@code final} because they cannot be independently varied.
 130  *
 131  * <p>You may also find the inherited methods from {@link
 132  * AbstractOwnableSynchronizer} useful to keep track of the thread
 133  * owning an exclusive synchronizer.  You are encouraged to use them
 134  * -- this enables monitoring and diagnostic tools to assist users in
 135  * determining which threads hold locks.
 136  *
 137  * <p>Even though this class is based on an internal FIFO queue, it
 138  * does not automatically enforce FIFO acquisition policies.  The core
 139  * of exclusive synchronization takes the form:
 140  *
 141  * <pre>
 142  * Acquire:
 143  *     while (!tryAcquire(arg)) {
 144  *        <em>enqueue thread if it is not already queued</em>;
 145  *        <em>possibly block current thread</em>;
 146  *     }
 147  *
 148  * Release:
 149  *     if (tryRelease(arg))
 150  *        <em>unblock the first queued thread</em>;
 151  * </pre>
 152  *
 153  * (Shared mode is similar but may involve cascading signals.)
 154  *
 155  * <p id="barging">Because checks in acquire are invoked before
 156  * enqueuing, a newly acquiring thread may <em>barge</em> ahead of
 157  * others that are blocked and queued.  However, you can, if desired,
 158  * define {@code tryAcquire} and/or {@code tryAcquireShared} to
 159  * disable barging by internally invoking one or more of the inspection
 160  * methods, thereby providing a <em>fair</em> FIFO acquisition order.
 161  * In particular, most fair synchronizers can define {@code tryAcquire}
 162  * to return {@code false} if {@link #hasQueuedPredecessors} (a method
 163  * specifically designed to be used by fair synchronizers) returns
 164  * {@code true}.  Other variations are possible.
 165  *
 166  * <p>Throughput and scalability are generally highest for the
 167  * default barging (also known as <em>greedy</em>,
 168  * <em>renouncement</em>, and <em>convoy-avoidance</em>) strategy.
 169  * While this is not guaranteed to be fair or starvation-free, earlier
 170  * queued threads are allowed to recontend before later queued
 171  * threads, and each recontention has an unbiased chance to succeed
 172  * against incoming threads.  Also, while acquires do not
 173  * &quot;spin&quot; in the usual sense, they may perform multiple
 174  * invocations of {@code tryAcquire} interspersed with other
 175  * computations before blocking.  This gives most of the benefits of
 176  * spins when exclusive synchronization is only briefly held, without
 177  * most of the liabilities when it isn't. If so desired, you can
 178  * augment this by preceding calls to acquire methods with
 179  * "fast-path" checks, possibly prechecking {@link #hasContended}
 180  * and/or {@link #hasQueuedThreads} to only do so if the synchronizer
 181  * is likely not to be contended.
 182  *
 183  * <p>This class provides an efficient and scalable basis for
 184  * synchronization in part by specializing its range of use to
 185  * synchronizers that can rely on {@code int} state, acquire, and
 186  * release parameters, and an internal FIFO wait queue. When this does
 187  * not suffice, you can build synchronizers from a lower level using
 188  * {@link java.util.concurrent.atomic atomic} classes, your own custom
 189  * {@link java.util.Queue} classes, and {@link LockSupport} blocking
 190  * support.
 191  *
 192  * <h3>Usage Examples</h3>
 193  *
 194  * <p>Here is a non-reentrant mutual exclusion lock class that uses
 195  * the value zero to represent the unlocked state, and one to
 196  * represent the locked state. While a non-reentrant lock
 197  * does not strictly require recording of the current owner
 198  * thread, this class does so anyway to make usage easier to monitor.
 199  * It also supports conditions and exposes
 200  * one of the instrumentation methods:
 201  *
 202  *  <pre> {@code
 203  * class Mutex implements Lock, java.io.Serializable {
 204  *
 205  *   // Our internal helper class
 206  *   private static class Sync extends AbstractQueuedSynchronizer {
 207  *     // Reports whether in locked state
 208  *     protected boolean isHeldExclusively() {
 209  *       return getState() == 1;
 210  *     }
 211  *
 212  *     // Acquires the lock if state is zero
 213  *     public boolean tryAcquire(int acquires) {
 214  *       assert acquires == 1; // Otherwise unused
 215  *       if (compareAndSetState(0, 1)) {
 216  *         setExclusiveOwnerThread(Thread.currentThread());
 217  *         return true;
 218  *       }
 219  *       return false;
 220  *     }
 221  *
 222  *     // Releases the lock by setting state to zero
 223  *     protected boolean tryRelease(int releases) {
 224  *       assert releases == 1; // Otherwise unused
 225  *       if (getState() == 0) throw new IllegalMonitorStateException();
 226  *       setExclusiveOwnerThread(null);
 227  *       setState(0);
 228  *       return true;
 229  *     }
 230  *
 231  *     // Provides a Condition
 232  *     Condition newCondition() { return new ConditionObject(); }
 233  *
 234  *     // Deserializes properly
 235  *     private void readObject(ObjectInputStream s)
 236  *         throws IOException, ClassNotFoundException {
 237  *       s.defaultReadObject();
 238  *       setState(0); // reset to unlocked state
 239  *     }
 240  *   }
 241  *
 242  *   // The sync object does all the hard work. We just forward to it.
 243  *   private final Sync sync = new Sync();
 244  *
 245  *   public void lock()                { sync.acquire(1); }
 246  *   public boolean tryLock()          { return sync.tryAcquire(1); }
 247  *   public void unlock()              { sync.release(1); }
 248  *   public Condition newCondition()   { return sync.newCondition(); }
 249  *   public boolean isLocked()         { return sync.isHeldExclusively(); }
 250  *   public boolean hasQueuedThreads() { return sync.hasQueuedThreads(); }
 251  *   public void lockInterruptibly() throws InterruptedException {
 252  *     sync.acquireInterruptibly(1);
 253  *   }
 254  *   public boolean tryLock(long timeout, TimeUnit unit)
 255  *       throws InterruptedException {
 256  *     return sync.tryAcquireNanos(1, unit.toNanos(timeout));
 257  *   }
 258  * }}</pre>
 259  *
 260  * <p>Here is a latch class that is like a
 261  * {@link java.util.concurrent.CountDownLatch CountDownLatch}
 262  * except that it only requires a single {@code signal} to
 263  * fire. Because a latch is non-exclusive, it uses the {@code shared}
 264  * acquire and release methods.
 265  *
 266  *  <pre> {@code
 267  * class BooleanLatch {
 268  *
 269  *   private static class Sync extends AbstractQueuedSynchronizer {
 270  *     boolean isSignalled() { return getState() != 0; }
 271  *
 272  *     protected int tryAcquireShared(int ignore) {
 273  *       return isSignalled() ? 1 : -1;
 274  *     }
 275  *
 276  *     protected boolean tryReleaseShared(int ignore) {
 277  *       setState(1);
 278  *       return true;
 279  *     }
 280  *   }
 281  *
 282  *   private final Sync sync = new Sync();
 283  *   public boolean isSignalled() { return sync.isSignalled(); }
 284  *   public void signal()         { sync.releaseShared(1); }
 285  *   public void await() throws InterruptedException {
 286  *     sync.acquireSharedInterruptibly(1);
 287  *   }
 288  * }}</pre>
 289  *
 290  * @since 1.5
 291  * @author Doug Lea
 292  */
 293 public abstract class AbstractQueuedSynchronizer
 294     extends AbstractOwnableSynchronizer
 295     implements java.io.Serializable {
 296 
 297     private static final long serialVersionUID = 7373984972572414691L;
 298 
 299     /**
 300      * Creates a new {@code AbstractQueuedSynchronizer} instance
 301      * with initial synchronization state of zero.
 302      */
 303     protected AbstractQueuedSynchronizer() { }
 304 
 305     /**
 306      * Wait queue node class.
 307      *
 308      * <p>The wait queue is a variant of a "CLH" (Craig, Landin, and
 309      * Hagersten) lock queue. CLH locks are normally used for
 310      * spinlocks.  We instead use them for blocking synchronizers, but
 311      * use the same basic tactic of holding some of the control
 312      * information about a thread in the predecessor of its node.  A
 313      * "status" field in each node keeps track of whether a thread
 314      * should block.  A node is signalled when its predecessor
 315      * releases.  Each node of the queue otherwise serves as a
 316      * specific-notification-style monitor holding a single waiting
 317      * thread. The status field does NOT control whether threads are
 318      * granted locks etc though.  A thread may try to acquire if it is
 319      * first in the queue. But being first does not guarantee success;
 320      * it only gives the right to contend.  So the currently released
 321      * contender thread may need to rewait.
 322      *
 323      * <p>To enqueue into a CLH lock, you atomically splice it in as new
 324      * tail. To dequeue, you just set the head field.
 325      * <pre>
 326      *      +------+  prev +-----+       +-----+
 327      * head |      | <---- |     | <---- |     |  tail
 328      *      +------+       +-----+       +-----+
 329      * </pre>
 330      *
 331      * <p>Insertion into a CLH queue requires only a single atomic
 332      * operation on "tail", so there is a simple atomic point of
 333      * demarcation from unqueued to queued. Similarly, dequeuing
 334      * involves only updating the "head". However, it takes a bit
 335      * more work for nodes to determine who their successors are,
 336      * in part to deal with possible cancellation due to timeouts
 337      * and interrupts.
 338      *
 339      * <p>The "prev" links (not used in original CLH locks), are mainly
 340      * needed to handle cancellation. If a node is cancelled, its
 341      * successor is (normally) relinked to a non-cancelled
 342      * predecessor. For explanation of similar mechanics in the case
 343      * of spin locks, see the papers by Scott and Scherer at
 344      * http://www.cs.rochester.edu/u/scott/synchronization/
 345      *
 346      * <p>We also use "next" links to implement blocking mechanics.
 347      * The thread id for each node is kept in its own node, so a
 348      * predecessor signals the next node to wake up by traversing
 349      * next link to determine which thread it is.  Determination of
 350      * successor must avoid races with newly queued nodes to set
 351      * the "next" fields of their predecessors.  This is solved
 352      * when necessary by checking backwards from the atomically
 353      * updated "tail" when a node's successor appears to be null.
 354      * (Or, said differently, the next-links are an optimization
 355      * so that we don't usually need a backward scan.)
 356      *
 357      * <p>Cancellation introduces some conservatism to the basic
 358      * algorithms.  Since we must poll for cancellation of other
 359      * nodes, we can miss noticing whether a cancelled node is
 360      * ahead or behind us. This is dealt with by always unparking
 361      * successors upon cancellation, allowing them to stabilize on
 362      * a new predecessor, unless we can identify an uncancelled
 363      * predecessor who will carry this responsibility.
 364      *
 365      * <p>CLH queues need a dummy header node to get started. But
 366      * we don't create them on construction, because it would be wasted
 367      * effort if there is never contention. Instead, the node
 368      * is constructed and head and tail pointers are set upon first
 369      * contention.
 370      *
 371      * <p>Threads waiting on Conditions use the same nodes, but
 372      * use an additional link. Conditions only need to link nodes
 373      * in simple (non-concurrent) linked queues because they are
 374      * only accessed when exclusively held.  Upon await, a node is
 375      * inserted into a condition queue.  Upon signal, the node is
 376      * transferred to the main queue.  A special value of status
 377      * field is used to mark which queue a node is on.
 378      *
 379      * <p>Thanks go to Dave Dice, Mark Moir, Victor Luchangco, Bill
 380      * Scherer and Michael Scott, along with members of JSR-166
 381      * expert group, for helpful ideas, discussions, and critiques
 382      * on the design of this class.
 383      */
 384     static final class Node {
 385         /** Marker to indicate a node is waiting in shared mode */
 386         static final Node SHARED = new Node();
 387         /** Marker to indicate a node is waiting in exclusive mode */
 388         static final Node EXCLUSIVE = null;
 389 
 390         /** waitStatus value to indicate thread has cancelled */
 391         static final int CANCELLED =  1;
 392         /** waitStatus value to indicate successor's thread needs unparking */
 393         static final int SIGNAL    = -1;
 394         /** waitStatus value to indicate thread is waiting on condition */
 395         static final int CONDITION = -2;
 396         /**
 397          * waitStatus value to indicate the next acquireShared should
 398          * unconditionally propagate
 399          */
 400         static final int PROPAGATE = -3;
 401 
 402         /**
 403          * Status field, taking on only the values:
 404          *   SIGNAL:     The successor of this node is (or will soon be)
 405          *               blocked (via park), so the current node must
 406          *               unpark its successor when it releases or
 407          *               cancels. To avoid races, acquire methods must
 408          *               first indicate they need a signal,
 409          *               then retry the atomic acquire, and then,
 410          *               on failure, block.
 411          *   CANCELLED:  This node is cancelled due to timeout or interrupt.
 412          *               Nodes never leave this state. In particular,
 413          *               a thread with cancelled node never again blocks.
 414          *   CONDITION:  This node is currently on a condition queue.
 415          *               It will not be used as a sync queue node
 416          *               until transferred, at which time the status
 417          *               will be set to 0. (Use of this value here has
 418          *               nothing to do with the other uses of the
 419          *               field, but simplifies mechanics.)
 420          *   PROPAGATE:  A releaseShared should be propagated to other
 421          *               nodes. This is set (for head node only) in
 422          *               doReleaseShared to ensure propagation
 423          *               continues, even if other operations have
 424          *               since intervened.
 425          *   0:          None of the above
 426          *
 427          * The values are arranged numerically to simplify use.
 428          * Non-negative values mean that a node doesn't need to
 429          * signal. So, most code doesn't need to check for particular
 430          * values, just for sign.
 431          *
 432          * The field is initialized to 0 for normal sync nodes, and
	   

您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • # 0.相關確定 本教程使用的版本號為專業版PyCharm 2022.3.2,如果您是初學者,為了更好的學習本教程,避免不必要的麻煩,請您下載使用與本教程一致的版本號。 # 1.PyCharm的下載 官網下載:https://www.jetbrains.com/pycharm/download/ot ...
  • Servlet是web體系裡面最重要的部分,下麵羅列幾道常見的面試題,小伙伴們一定要好好記住哈。 1.Servlet是單例的嗎,如何證明? Servlet一般都是單例的,並且是多線程的。如何證明Servlet是單例模式呢?很簡單,重寫Servlet的init方法,或者添加一個構造方法。然後,在web ...
  • Rocksdb作為當下nosql中性能的代表被各個存儲組件(mysql、tikv、pmdk、bluestore)作為存儲引擎底座,其基於LSM tree的核心存儲結構(將隨機寫通過數據結構轉化為順序寫)來提供高性能的寫吞吐時保證了讀性能。同時大量的併發性配置來降低compaction的影響。 ...
  • 本篇為[用go設計開發一個自己的輕量級登錄庫/框架吧]的封禁業務篇,會講講封禁業務的實現,給庫/框架增加新的功能。源碼:https://github.com/weloe/token-go ...
  • 哈嘍大家好,我是鹹魚 幾天前,IBM 工程師 Martin Heinz 發文表示 python 3.12 版本回引入"Per-Interpreter GIL”,有了這個 Per-Interpreter 全局解釋器鎖,python 就能實現真正意義上的並行/併發 我們知道,python 的多線程/進程 ...
  • ## 1. ThreadLocal 是什麼 JDK 對`ThreadLocal`的描述為: > 此類提供線程局部變數。這些變數與普通變數的不同之處在於,每個訪問一個變數的線程(通過其get或set方法)都有自己的、獨立初始化的變數副本。ThreadLocal 實例通常是類中的私有靜態欄位,這些欄位希 ...
  • # 三、Java8的CompletableFuture,Java的多線程開發 ## 1、CompletableFuture的常用方法 - 以後用到再加 ```properties runAsync() :開啟非同步(創建線程執行任務),無返回值 supplyAsync() :開啟非同步(創建線程執行任務 ...
  • ​ # Maven的核心解壓與配置 @[toc] ## 1. Maven 官網地址 首頁:[Maven – Welcome to Apache Maven(opens new window)](https://maven.apache.org/) ![在這裡插入圖片描述](https://img20 ...
一周排行
    -Advertisement-
    Play Games
  • 1. 說明 /* Performs operations on System.String instances that contain file or directory path information. These operations are performed in a cross-pla ...
  • 視頻地址:【WebApi+Vue3從0到1搭建《許可權管理系統》系列視頻:搭建JWT系統鑒權-嗶哩嗶哩】 https://b23.tv/R6cOcDO qq群:801913255 一、在appsettings.json中設置鑒權屬性 /*jwt鑒權*/ "JwtSetting": { "Issuer" ...
  • 引言 集成測試可在包含應用支持基礎結構(如資料庫、文件系統和網路)的級別上確保應用組件功能正常。 ASP.NET Core 通過將單元測試框架與測試 Web 主機和記憶體中測試伺服器結合使用來支持集成測試。 簡介 集成測試與單元測試相比,能夠在更廣泛的級別上評估應用的組件,確認多個組件一起工作以生成預 ...
  • 在.NET Emit編程中,我們探討了運算操作指令的重要性和應用。這些指令包括各種數學運算、位操作和比較操作,能夠在動態生成的代碼中實現對數據的處理和操作。通過這些指令,開發人員可以靈活地進行算術運算、邏輯運算和比較操作,從而實現各種複雜的演算法和邏輯......本篇之後,將進入第七部分:實戰項目 ...
  • 前言 多表頭表格是一個常見的業務需求,然而WPF中卻沒有預設實現這個功能,得益於WPF強大的控制項模板設計,我們可以通過修改控制項模板的方式自己實現它。 一、需求分析 下圖為一個典型的統計表格,統計1-12月的數據。 此時我們有一個需求,需要將月份按季度劃分,以便能夠直觀地看到季度統計數據,以下為該需求 ...
  • 如何將 ASP.NET Core MVC 項目的視圖分離到另一個項目 在當下這個年代 SPA 已是主流,人們早已忘記了 MVC 以及 Razor 的故事。但是在某些場景下 SSR 還是有意想不到效果。比如某些靜態頁面,比如追求首屏載入速度的時候。最近在項目中回歸傳統效果還是不錯。 有的時候我們希望將 ...
  • System.AggregateException: 發生一個或多個錯誤。 > Microsoft.WebTools.Shared.Exceptions.WebToolsException: 生成失敗。檢查輸出視窗瞭解更多詳細信息。 內部異常堆棧跟蹤的結尾 > (內部異常 #0) Microsoft ...
  • 引言 在上一章節我們實戰了在Asp.Net Core中的項目實戰,這一章節講解一下如何測試Asp.Net Core的中間件。 TestServer 還記得我們在集成測試中提供的TestServer嗎? TestServer 是由 Microsoft.AspNetCore.TestHost 包提供的。 ...
  • 在發現結果為真的WHEN子句時,CASE表達式的真假值判斷會終止,剩餘的WHEN子句會被忽略: CASE WHEN col_1 IN ('a', 'b') THEN '第一' WHEN col_1 IN ('a') THEN '第二' ELSE '其他' END 註意: 統一各分支返回的數據類型. ...
  • 在C#編程世界中,語法的精妙之處往往體現在那些看似微小卻極具影響力的符號與結構之中。其中,“_ =” 這一組合突然出現還真不知道什麼意思。本文將深入剖析“_ =” 的含義、工作原理及其在實際編程中的廣泛應用,揭示其作為C#語法奇兵的重要角色。 一、下劃線 _:神秘的棄元符號 下劃線 _ 在C#中並非 ...