AQS源碼解讀----AbstractQueuedSynchronizer

  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