前面两章分析了"公平锁的获取和释放机制"，这一章开始对“非公平锁”的获取锁/释放锁的过程进行分析。内容包括：
参考代码
获取非公平锁(基于JDK1.7.0_40)
释放非公平锁(基于JDK1.7.0_40)
关于锁的使用示例请参考“Java多线程系列--“JUC锁”02之 互斥锁ReentrantLock”。
转载请注明出处：http://www.cnblogs.com/skywang12345/p/3496651.html
参考代码
下面给出Java1.7.0_40版本中，ReentrantLock和AQS的
源码，仅供参考！
ReentranLock.java
复制代码
1 /*
2 * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
3 *
4 *
5 *
6 *
7 *
8 *
9 *
10 *
11 *
12 *
13 *
14 *
15 *
16 *
17 *
18 *
19 *
20 *
21 *
22 *
23 */
24
25 /*
26 *
27 *
28 *
29 *
30 *
31 * Written by Doug Lea with assistance from members of JCP JSR-166
32 * Expert Group and released to the public domain, as explained at
33 * http://creativecommons.org/publicdomain/zero/1.0/
34 */
35
36 package java.util.concurrent.locks;
37 import java.util.*;
38 import java.util.concurrent.*;
39 import java.util.concurrent.atomic.*;
40
41 /**
42 * A reentrant mutual exclusion {@link Lock} with the same basic
43 * behavior and semantics as the implicit monitor lock accessed using
44 * {@code synchronized} methods and statements, but with extended
45 * capabilities.
46 *
47 *
A {@code ReentrantLock} is owned by the thread last
48 * successfully locking, but not yet unlocking it. A thread invoking
50 * the lock is not owned by another thread. The method will return
51 * immediately if the current thread already owns the lock. This can
52 * be checked using methods {@link #isHeldByCurrentThread}, and {@link
53 * #getHoldCount}.
54 *
55 *
The constructor for this class accepts an optional
56 * fairness parameter. When set {@code true}, under
57 * contention, locks favor granting access to the longest-waiting
58 * thread. Otherwise this lock does not guarantee any particular
59 * access order. Programs using fair locks accessed by many threads
60 * may display lower overall throughput (i.e., are slower; often much
61 * slower) than those using the default setting, but have smaller
62 * variances in times to obtain locks and guarantee lack of
63 * starvation. Note however, that fairness of locks does not guarantee
64 * fairness of thread scheduling. Thus, one of many threads using a
65 * fair lock may obtain it multiple times in succession while other
66 * active threads are not progressing and not currently holding the
67 * lock.
68 * Also note that the untimed {@link #tryLock() tryLock} method does not
69 * honor the fairness setting. It will succeed if the lock
70 * is available even if other threads are waiting.
71 *
72 *
It is recommended practice to always immediately
73 * follow a call to {@code lock} with a {@code try} block, most
74 * typically in a before/after construction such as:
75 *
76 *
77 * class X {
78 * private final ReentrantLock lock = new ReentrantLock();
79 * // ...
80 *
81 * public void m() {
82 * lock.lock(); // block until condition holds
83 * try {
84 * // ... method body
85 * } finally {
86 * lock.unlock()
87 * }
88 * }
89 * }
90 *
91 *
92 *
In additio