synchronized锁实现原理
Java对象头：
synchronized是悲观锁，在操作同步资源之前需要给同步资源先加锁，这把锁就是存在Java对象头里的，而Java对象头又是什么呢？
我们以Hotspot虚拟机为例，Hotspot的对象头主要包括两部分数据：Mark Word（标记字段）、Klass Pointer（类型指针），数组长度（只有数组对象才有）。
Mark Word
：默认存储对象的HashCode，分代年龄和锁标志位信息。这些信息都是与对象自身定义无关的数据，所以Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据。它会根据对象的状态复用自己的存储空间，也就是说在运行期间Mark Word里存储的数据会随着锁标志位的变化而变化。
JVM一般是这样使用锁和Mark Word的：
1，当没有被当成锁时，这就是一个普通的对象，Mark Word记录对象的HashCode，锁标志位是01，是否偏向锁那一位是0。
2，当对象被当做同步锁并有一个线程A抢到了锁时，锁标志位还是01，但是否偏向锁那一位改成1，前23bit记录抢到锁的线程id，表示进入偏向锁状态。
3，当线程A再次试图来获得锁时，JVM发现同步锁对象的标志位是01，是否偏向锁是1，也就是偏向状态，Mark Word中记录的线程id就是线程A自己的id，表示线程A已经获得了这个偏向锁，可以执行同步锁的代码。
4，当线程B试图获得这个锁时，JVM发现同步锁处于偏向状态，但是Mark Word中的线程id记录的不是B，那么线程B会先用CAS操作试图获得锁，这里的获得锁操作是有可能成功的，因为线程A一般不会自动释放偏向锁。如果抢锁成功，就把Mark Word里的线程id改为线程B的id，代表线程B获得了这个偏向锁，可以执行同步锁代码。如果抢锁失败，则继续执行步骤5。
5，偏向锁状态抢锁失败，代表当前锁有一定的竞争，偏向锁将升级为轻量级锁。JVM会在当前线程的线程栈中开辟一块单独的空间，里面保存指向对象锁Mark Word的指针，同时在对象锁Mark Word中保存指向这片空间的指针。上述两个保存操作都是CAS操作，如果保存成功，代表线程抢到了同步锁，就把Mark Word中的锁标志位改成00，可以执行同步锁代码。如果保存失败，表示抢锁失败，竞争太激烈，继续执行步骤6。
6，轻量级锁抢锁失败，JVM会使用自旋锁，自旋锁不是一个锁状态，只是代表不断的重试，尝试抢锁。从JDK1.7开始，自旋锁默认启用，自旋次数由JVM决定。如果抢锁成功则执行同步锁代码，如果失败则继续执行步骤7。
7，自旋锁重试之后如果抢锁依然失败，同步锁会升级至重量级锁，锁标志位改为10。在这个状态下，未抢到锁的线程都会被阻塞，这个操作需要转入内核态进行，这样做会带来很大的性能开销。
Klass Point
：对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例，Java对象的类数据保存在方法区。。
Monitor
Mark Word 有一个字段指向 monitor 对象。
monitor 中记录了锁的持有线程，等待的线程队列等信息。前面说的每个对象都有一个锁和一个等待队列，就是在这里实现的。 monitor 对象由 C++ 实现。其中有三个关键字段：
_owner 记录当前持有锁的线程
_EntryList 是一个队列，记录所有阻塞等待锁的线程
_WaitSet 也是一个队列，记录调用 wait() 方法并还未被通知的线程。
Monitor的操作机制如下：
多个线程竞争锁时，会先进入 EntryList 队列。竞争成功的线程被标记为 Owner。其他线程继续在此队列中阻塞等待。
如果 Owner 线程调用 wait() 方法，则其释放对象锁并进入 WaitSet 中等待被唤醒。Owner 被置空，EntryList 中的线程再次竞争锁。
如果 Owner 线程执行完了，便会释放锁，Owner 被置空，EntryList 中的线程再次竞争锁。
JVM 对 synchronized 的处理
上面了解了 monitor 的机制，那虚拟机是如何将 synchronized 和 monitor 关联起来的呢？分两种情况：
如果同步的是代码块，编译时会直接在同步代码块前加上 monitorenter 指令，代码块后加上 monitorexit 指令。这称为显示同步。
如果同步的是方法，虚拟机会为方法设置 ACC_SYNCHRONIZED 标志。调用的时候 JVM 根据这个标志判断是否是同步方法。
JVM 对 synchronized 的优化：自旋锁与自适应自旋
在许多应用中，锁定状态只会持续很短的时间，为了这么一点时间去挂起恢复线程，不值得。我们可以让等待线程执行一定次数的循环，在循环中去获取锁。这项技术称为自旋锁，它可以节省系统切换线程的消耗，但仍然要占用处理器。在 JDK1.4.2 中，自选的次数可以通过参数来控制。 JDK 1.6又引入了自适应的自旋锁，不再通过次数来限制，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。
锁消除
虚拟机在运行时，如果发现一段被锁住的代码中不可能存在共享数据，就会将这个锁清除。
锁粗化
当虚拟机检测到有一串零碎的操作都对同一个对象加锁时，会把锁扩展到整个操作序列外部。如 StringBuffer 的 append 操作。
轻量级锁
对绝大部分的锁来说，在整个同步周期内都不存在竞争。如果没有竞争，轻量级锁可以使用 CAS 操作避免使用互斥量的开销。
偏向锁
偏向锁的核心思想是，如果一个线程获得了锁，那么锁就进入偏向模式，当这个线程再次请求锁时，无需再做任何同步操作，即可获取锁。
synchronized 是重量级锁，由于消耗太大，虚拟机对其做了一些优化。
CAS
操作模型
CAS 是 compare and swap 的简写，即比较并交换。它是指一种操作机制，而不是某个具体的类或方法。在 Java 平台上对这种操作进行了包装。在 Unsafe 类中，调用代码如下：
unsafe.compareAndSwapInt(this, valueOffset, expect, update);
代码
它需要三个参数，分别是内存位置 V，旧的预期值 A 和新的值 B。操作时，先从内存位置读取到值，然后和预期值A（自己线程保存的值）比较。如果相等，则将此内存位置的值改为新值 B，返回 true。如果不相等，说明和其他线程冲突了，则不做任何改变，返回 false。
这种机制在不阻塞其他线程的情况下避免了并发冲突，比独占锁的性能高很多。 CAS 在 Java 的原子类和并发包中有大量使用。
重试机制（循环 CAS）
有很多文章说，CAS 操作失败后会一直重试直到成功，这种说法很不严谨。
第一，CAS 本身并未实现失败后的处理机制，它只负责返回成功或失败的布尔值，后续由调用者自行处理。只不过我们最常用的处理方式是重试而已。
第二，这句话很容易理解错，被理解成重新比较并交换。实际上失败的时候，原值已经被修改，如果不更改期望值，再怎么比较都会失败。而新值同样需要修改。
所以正确的方法是，使用一个死循环进行 CAS 操作，成功了就结束循环返回，失败了就重新从内存读取值和计算新值，再调用 CAS。看下 AtomicInteger 的源码就什么都懂了：
public final int incrementAndGet () {
for (;;) {
int current = get();
int next = current + 1;
if (compareAndSet(current, next))
return next; }}底层实现
CAS 主要分三步，读取-比较-修改。其中比较是在检测是否有冲突，如果检测到没有冲突后，其他线程还能修改这个值，那么 CAS 还是无法保证正确性。所以最关键的是要保证比较-修改这两步操作的原子性。
CAS 底层是靠调用 CPU 指令集的 cmpxchg 完成的，它是 x86 和 Intel 架构中的 compare and exchange 指令。在多核的情况下，这个指令也不能保证原子性，需要在前面加上 lock 指令。lock 指令可以保证一个 CPU 核心在操作期间独占一片内存区域。那么 这又是如何实现的呢？
在处理器中，一般有两种方式来实现上述效果：**总线锁和缓存锁。**在多核处理器的结构中，CPU 核心并不能直接访问内存，而是统一通过一条总线访问。总线锁就是锁住这条总线，使其他核心无法访问内存。这种方式代价太大了，会导致其他核心停止工作。而缓存锁并不锁定总线，只是锁定某部分内存区域。当一个 CPU 核心将内存区域的数据读取到自己的缓存区后，它会锁定缓存对应的内存区域。锁住期间，其他核心无法操作这块内存区域。关于总线锁和缓存锁的详细可以看下这篇文章：
CAS 就是通过这种方式实现比较和交换操作的原子性的。 值得注意的是， CAS 只是保证了操作的原子性，并不保证变量的可见性，因此变量需要加上 volatile 关键字。
CAS的ABA 问题
上面提到，CAS 保证了比较和交换的原子性。但是从读取到开始比较这段期间，其他核心仍然是可以修改这个值的。如果核心将 A 修改为 B，CAS 可以判断出来。但是如果核心将 A 修改为 B 再修改回 A。那么 CAS 会认为这个值并没有被改变，从而继续操作。这是和实际情况不符的。解决方案是加一个版本号。
聚个例子：
我们假设一个提款机的例子。假设有一个遵循CAS原理的提款机，小灰有100元存款，要用这个提款机来提款50元。
由于提款机硬件出了点问题，小灰的提款操作被同时提交了两次，开启了两个线程，两个线程都是获取当前值100元，要更新成50元。
理想情况下，应该一个线程更新成功，一个线程更新失败，小灰的存款值被扣一次。
线程1首先执行成功，把余额从100改成50.线程2因为某种原因阻塞。这时，小灰的妈妈刚好给小灰汇款50元
线程2仍然是阻塞状态，线程3执行成功，把余额从50改成了100。
线程2恢复运行，由于阻塞之前获得了“当前值”100，并且经过compare检测，此时存款实际值也是100，所以会成功把变量值100更新成50。
原本线程2应当提交失败，小灰的正确余额应该保持100元，结果由于ABA问题提交成功了。
怎么解决呢，一个是每次操作通过一个版本号进行对比而不是实际值，如Java提供了两种带版本戳的原子引用类型：
AtomicStampedReference：带版本戳的原子引用类型，版本戳为int类型。
AtomicMarkableReference：带版本戳的原子引用类型，版本戳为boolean类型。
示例：
同步代码块：
我们在代码块加上synchronized关键字
public void synSay() {
synchronized (object) {
System.out.println("synSay----" + Thread.currentThread().getName());
}
}编译之后，我们利用反编译命令javap -v xxx.class查看对应的字节码，这里为了减少篇幅，我就只粘贴对应的方法的字节码。
public void synSay();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=3, locals=3, args_size=1
0: aload_0
1: getfield #2 // Field object:Ljava/lang/String;
4: dup
5: astore_1
6: monitorenter
7: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
10: new #4 // class java/lang/StringBuilder
13: dup
14: invokespecial #5 // Method java/lang/StringBuilder."<init>":()V
17: ldc #6 // String synSay----
19: invokevirtual #7 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
22: invokestatic #8 // Method java/lang/Thread.currentThread:()Ljava/lang/Thread;
25: invokevirtual #9 // Method java/lang/Thread.getName:()Ljava/lang/String;
28: invokevirtual #7 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
31: invokevirtual #10 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
34: invokevirtual #11 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
37: aload_1
38: monitorexit
39: goto 47
42: astore_2
43: aload_1
44: monitorexit
45: aload_2
46: athrow
47: return
Exception table:
from to target type
7 39 42 any
42 45 42 any
LineNumberTable:
line 21: 0
line 22: 7
line 23: 37
line 24: 47
LocalVariableTable:
Start Length Slot Name Signature
0 48 0 this Lcn/T1;
StackMapTable: number_of_entries = 2
frame_type = 255 /* full_frame */
offset_delta = 42
locals = [ class cn/T1, class java/lang/Object ]
stack = [ class java/lang/Throwable ]
frame_type = 250 /* chop */
offset_delta = 4可以发现synchronized同步代码块是通过加monitorenter和monitorexit指令实现的。
每个对象都有个**监视器锁(monitor) **，当monitor被占用的时候就代表对象处于锁定状态，而monitorenter指令的作用就是获取monitor的所有权，monitorexit的作用是释放monitor的所有权，这两者的工作流程如下：
monitorenter：
如果monitor的进入数为0，则线程进入到monitor，然后将进入数设置为1，该线程称为monitor的所有者。
如果是线程已经拥有此monitor(即monitor进入数不为0)，然后该线程又重新进入monitor，则将monitor的进入数+1，这个即为锁的重入。
如果其他线程已经占用了monitor，则该线程进入到阻塞状态，直到monitor的进入数为0，该线程再去重新尝试获取monitor的所有权。
monitorexit：执行该指令的线程必须是monitor的所有者，指令执行时，monitor进入数-1，如果-1后进入数为0，那么线程退出monitor，不再是这个monitor的所有者。这个时候其它阻塞的线程可以尝试获取monitor的所有权。
同步方法
在方法上加上synchronized关键字
synchronized public void synSay() {
System.out.println("synSay----" + Thread.currentThread().getName());
}编译之后，我们利用反编译命令javap -v xxx.class查看对应的字节码，
public synchronized void synSay();
descriptor: ()V
flags: ACC_PUBLIC, ACC_SYNCHRONIZED
Code:
stack=3, locals=1, args_size=1
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: new #3 // class java/lang/StringBuilder
6: dup
7: invokespecial #4 // Method java/lang/StringBuilder."<init>":()V
10: ldc #5 // String synSay----
12: invokevirtual #6 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
15: invokestatic #7 // Method java/lang/Thread.currentThread:()Ljava/lang/Thread;
18: invokevirtual #8 // Method java/lang/Thread.getName:()Ljava/lang/String;
21: invokevirtual #6 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
24: invokevirtual #9 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
27: invokevirtual #10 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
30: return
LineNumberTable:
line 20: 0
line 21: 30
LocalVariableTable:
Start Length Slot Name Signature
0 31 0 this Lcn/T1;从字节码上看，加有synchronized关键字的方法，常量池中比普通的方法多了个ACC_SYNCHRONIZED标识，JVM就是根据这个标识来实现方法的同步。
当调用方法的时候，调用指令会检查方法是否有ACC_SYNCHRONIZED标识，有的话线程需要先获取monitor，获取成功才能继续执行方法，方法执行完毕之后，线程再释放monitor，同一个monitor同一时刻只能被一个线程拥有。
两种同步方式区别
synchronized同步代码块的时候通过加入字节码monitorenter和monitorexit指令来实现monitor的获取和释放，也就是需要JVM通过字节码显式的去获取和释放monitor实现同步，而synchronized同步方法的时候，没有使用这两个指令，而是检查方法的ACC_SYNCHRONIZED标志是否被设置，如果设置了则线程需要先去获取monitor，执行完毕了线程再释放monitor，也就是不需要JVM去显式的实现。
这两个同步方式实际都是通过获取monitor和释放monitor来实现同步的，而monitor的实现依赖于底层操作系统的mutex互斥原语，而操作系统实现线程之间的切换的时候需要从用户态转到内核态，这个转成过程开销比较大。
线程获取、释放monitor的过程如下：
线程尝试获取monitor的所有权，如果获取失败说明monitor被其他线程占用，则将线程加入到的同步队列中，等待其他线程释放monitor，当其他线程释放monitor后，有可能刚好有线程来获取monitor的所有权，那么系统会将monitor的所有权给这个线程，而不会去唤醒同步队列的第一个节点去获取，所以synchronized是非公平锁。如果线程获取monitor成功则进入到monitor中，并且将其进入数+1。
java的内置锁以及代码实现
好的，再说下java的内置锁：每个java对象都可以用做一个实现同步的锁，这些锁成为内置锁。线程进入同步代码块或方法的时候会自动获得该锁，在退出同步代码块或方法时会释放该锁。获得内置锁的唯一途径就是进入这个锁的保护的同步代码块或方法。
java内置锁是一个互斥锁，这就是意味着最多只有一个线程能够获得该锁，当线程A尝试去获得线程B持有的内置锁时，线程A必须等待或者阻塞，知道线程B释放这个锁，如果B线程不释放这个锁，那么A线程将永远等待下去。
java的对象锁和类锁：java的对象锁和类锁在锁的概念上基本上和内置锁是一致的，但是，两个锁实际是有很大的区别的，对象锁是用于对象实例方法，或者一个对象实例上的，类锁是用于类的静态方法或者一个类的class对象上的。我们知道，类的对象实例可以有很多个，但是每个类只有一个class对象，所以不同对象实例的对象锁是互不干扰的，但是每个类只有一个类锁。但是有一点必须注意的是，其实类锁只是一个概念上的东西，并不是真实存在的，它只是用来帮助我们理解锁定实例方法和静态方法的区别的
synchronized的用法：synchronized修饰方法和synchronized修饰代码块。
下面分别分析这两种用法在对象锁和类锁上的效果。
对象锁的synchronized修饰方法和代码块：
public class TestSynchronized {
public void test1() {
synchronized (this) {
int i = 5;
while (i-- > 0) {
System.out.println(Thread.currentThread().getName() + " : " + i);
try {
Thread.sleep(500);
} catch (InterruptedException ie) {
}
}
}
}
public synchronized void test2() {
int i = 5;
while (i-- > 0) {
System.out.println(Thread.currentThread().getName() + " : " + i);
try {
Thread.sleep(500);
} catch (InterruptedException ie) {
}
}
}
public static void main(String[] args) {
final TestSynchronized myt2 = new TestSynchronized();
Thread test1 = new Thread(new Runnable() {
public void run() {
myt2.test1();
}
}, "test1");
Thread test2 = new Thread(new Runnable() {
public void run() {
myt2.test2();
}
}, "test2");
test1.start();
test2.start();
// TestRunnable tr=new TestRunnable();
// Thread test3=new Thread(tr);
// test3.start();
}
}结果：
1. test2 : 4
2. test2 : 3
3. test2 : 2
4. test2 : 1
5. test2 : 0
6. test1 : 4
7. test1 : 3
8. test1 : 2
9. test1 : 1
10. test1 : 0上述的代码，第一个方法时用了同步代码块的方式进行同步，传入的对象实例是this，表明是当前对象，当然，如果需要同步其他对象实例，也不可传入其他对象的实例；第二个方法是修饰方法的方式进行同步。因为第一个同步代码块传入的this，所以两个同步代码所需要获得的对象锁都是同一个对象锁，下面main方法时分别开启两个线程，分别调用test1和test2方法，那么两个线程都需要获得该对象锁，另一个线程必须等待。上面也给出了运行的结果可以看到：直到test2线程执行完毕，释放掉锁，test1线程才开始执行。（可能这个结果有人会有疑问，代码里面明明是先开启test1线程，为什么先执行的是test2呢？这是因为java编译器在编译成字节码的时候，会对代码进行一个重排序，也就是说，编译器会根据实际情况对代码进行一个合理的排序，编译前代码写在前面，在编译后的字节码不一定排在前面，所以这种运行结果是正常的， 这里是题外话，最主要是检验synchronized的用法的正确性）
如果我们把test2方法的synchronized关键字去掉，执行结果会如何呢？
1.test1 : 4
2.test2 : 4
3.test2 : 3
4.test1 : 3
5.test1 : 2
6.test2 : 2
7.test2 : 1
8.test1 : 1
9.test2 : 0
10.test1 : 0上面是执行结果，我们可以看到，结果输出是交替着进行输出的，这是因为，某个线程得到了对象锁，但是另一个线程还是可以访问没有进行同步的方法或者代码。进行了同步的方法（加锁方法）和没有进行同步的方法（普通方法）是互不影响的，一个线程进入了同步方法，得到了对象锁，其他线程还是可以访问那些没有同步的方法（普通方法）。这里涉及到内置锁的一个概念（此概念出自java并发编程实战第二章）：对象的内置锁和对象的状态之间是没有内在的关联的，虽然大多数类都将内置锁用做一种有效的加锁机制，但对象的域并不一定通过内置锁来保护。当获取到与对象关联的内置锁时，并不能阻止其他线程访问该对象，当某个线程获得对象的锁之后，只能阻止其他线程获得同一个锁。之所以每个对象都有一个内置锁，是为了免去显式地创建锁对象。
所以synchronized只是一个内置锁的加锁机制，当某个方法加上synchronized关键字后，就表明要获得该内置锁才能执行，并不能阻止其他线程访问不需要获得该内置锁的方法。
类锁的修饰（静态）方法和代码块：
public class TestSynchronized {
public void test1() {
synchronized (TestSynchronized.class) {
int i = 5;
while (i-- > 0) {
System.out.println(Thread.currentThread().getName() + " : " + i);
try {
Thread.sleep(500);
} catch (InterruptedException ie) {
}
}
}
}
public static synchronized void test2() {
int i = 5;
while (i-- > 0) {
System.out.println(Thread.currentThread().getName() + " : " + i);
try {
Thread.sleep(500);
} catch (InterruptedException ie) {
}
}
}
public static void main(String[] args) {
final TestSynchronized myt2 = new TestSynchronized();
Thread test1 = new Thread(new Runnable() {
public void run() {
myt2.test1();
}
}, "test1");
Thread test2 = new Thread(new Runnable() {
public void run() {
TestSynchronized.test2();
}
}, "test2");
test1.start();
test2.start();
// TestRunnable tr=new TestRunnable();
// Thread test3=new Thread(tr);
// test3.start();
}
}结果：
1.test1 : 4
2.test1 : 3
3.test1 : 2
4.test1 : 1
5.test1 : 0
6.test2 : 4
7.test2 : 3
8.test2 : 2
9.test2 : 1
10.test2 : 0其实，类锁修饰方法和代码块的效果和对象锁是一样的，因为类锁只是一个抽象出来的概念，只是为了区别静态方法的特点，因为静态方法是所有对象实例共用的，所以对应着synchronized修饰的静态方法的锁也是唯一的，所以抽象出来个类锁。其实这里的重点在下面这块代码，synchronized同时修饰静态和非静态方法
public class TestSynchronized {
public synchronized void test1() {
int i = 5;
while (i-- > 0) {
System.out.println(Thread.currentThread().getName() + " : " + i);
try {
Thread.sleep(500);
} catch (InterruptedException ie) {
}
}
}
public static synchronized void test2() {
int i = 5;
while (i-- > 0) {
System.out.println(Thread.currentThread().getName() + " : " + i);
try {
Thread.sleep(500);
} catch (InterruptedException ie) {
}
}
}
public static void main(String[] args) {
final TestSynchronized myt2 = new TestSynchronized();
Thread test1 = new Thread(new Runnable() {
public void run() {
myt2.test1();
}
}, "test1");
Thread test2 = new Thread(new Runnable() {
public void run() {
TestSynchronized.test2();
}
}, "test2");
test1.start();
test2.start();
// TestRunnable tr=new TestRunnable();
// Thread test3=new Thread(tr);
// test3.start();
}
}1.test1 : 4
2.test2 : 4
3.test1 : 3
4.test2 : 3
5.test2 : 2
6.test1 : 2
7.test2 : 1
8.test1 : 1
9.test1 : 0
10.test2 : 0上面代码synchronized同时修饰静态方法和实例方法，但是运行结果是交替进行的，这证明了类锁和对象锁是两个不一样的锁，控制着不同的区域，它们是互不干扰的。同样，线程获得对象锁的同时，也可以获得该类锁，即同时获得两个锁，这是允许的。
到这里，对synchronized的用法已经有了一定的了解。这时有一个疑问，既然有了synchronized修饰方法的同步方式，为什么还需要synchronized修饰同步代码块的方式呢？而这个问题也是synchronized的缺陷所在
synchronized的缺陷
当某个线程进入同步方法获得对象锁，那么其他线程访问这里对象的同步方法时，必须等待或者阻塞，这对高并发的系统是致命的，这很容易导致系统的崩溃。如果某个线程在同步方法里面发生了死循环，那么它就永远不会释放这个对象锁，那么其他线程就要永远的等待。这是一个致命的问题。当然同步方法和同步代码块都会有这样的缺陷，只要用了synchronized关键字就会有这样的风险和缺陷。既然避免不了这种缺陷，那么就应该将风险降到最低。这也是同步代码块在某种情况下要优于同步方法的方面。
Class Test(){
public SynObject so = new SynObject();
//synchronized修饰，那么当某个线程进入了这个方法之后，Test对象其他同步方法都不能给其他线程访问了
public void synchronized function(){
so.testsy();
}
//synchronized来修饰代码块，这对其他同步方法时没有影响的，因为他们持有的锁不一样，为不同对象的锁。
synchronized（so）{
so.testsy();
}
}
------------------------------------------------
Class SynObject (){
public void testsy(){
//
}
}例如在Test类的方法里面：这个类里面声明了一个对象实例，SynObject so=new SynObject()；在某个方法里面调用了这个实例的方法so.testsy();但是调用这个方法需要进行同步，不能同时有多个线程同时执行调用这个方法。
这时如果直接用synchronized修饰调用了so.testsy()代码的方法，那么当某个线程进入了这个方法之后，这个对象其他同步方法都不能给其他线程访问了。假如这个方法需要执行的时间很长，那么其他线程会一直阻塞，影响到系统的性能。
如果这时用synchronized来修饰代码块：synchronized（so）{so.testsy();}，那么这个方法加锁的对象是so这个对象，跟执行这行代码的对象没有关系，当一个线程执行这个方法时，这对其他同步方法时没有影响的，因为他们持有的锁都完全不一样。
不过这里还有一种特例，就是上面演示的第一个例子，对象锁synchronized同时修饰方法和代码块，这时也可以体现到同步代码块的优越性，如果test1方法同步代码块后面有非常多没有同步的代码，而且有一个100000的循环，这导致test1方法会执行时间非常长，那么如果直接用synchronized修饰方法，那么在方法没执行完之前，其他线程是不可以访问test2方法的，但是如果用了同步代码块，那么当退出代码块时就已经释放了对象锁，当线程还在执行test1的那个100000的循环时，其他线程就已经可以访问test2方法了。这就让阻塞的机会或者线程更少。让系统的性能更优越。
一个类的对象锁和另一个类的对象锁是没有关联的，当一个线程获得A类的对象锁时，它同时也可以获得B类的对象锁。
可能上面只有理论和代码，对刚接触的人比较难理解，下面举一个例子，
打个比方：一个object就像一个大房子，大门永远打开。房子里有 很多房间（也就是方法）。
这些房间有上锁的（synchronized方法）， 和不上锁之分（普通方法）。房门口放着一把钥匙（key），这把钥匙可以打开所有上锁的房间。
另外我把所有想调用该对象方法的线程比喻成想进入这房子某个 房间的人。所有的东西就这么多了，下面我们看看这些东西之间如何作用的。
在此我们先来明确一下我们的前提条件。该对象至少有一个synchronized方法，否则这个key还有啥意义。当然也就不会有我们的这个主题了。
一个人想进入某间上了锁的房间，他来到房子门口，看见钥匙在那儿（说明暂时还没有其他人要使用上锁的 房间）。于是他走上去拿到了钥匙，并且按照自己 的计划使用那些房间。注意一点，他每次使用完一次上锁的房间后会马上把钥匙还回去。即使他要连续使用两间上锁的房间，中间他也要把钥匙还回去，再取回来。
因此，普通情况下钥匙的使用原则是：“随用随借，用完即还。”
这时其他人可以不受限制的使用那些不上锁的房间，一个人用一间可以，两个人用一间也可以，没限制。但是如果当某个人想要进入上锁的房间，他就要跑到大门口去看看了。有钥匙当然拿了就走，没有的话，就只能等了。
要是很多人在等这把钥匙，等钥匙还回来以后，谁会优先得到钥匙？Not guaranteed。象前面例子里那个想连续使用两个上锁房间的家伙，他中间还钥匙的时候如果还有其他人在等钥匙，那么没有任何保证这家伙能再次拿到。 （JAVA规范在很多地方都明确说明不保证，像Thread.sleep()休息后多久会返回运行，相同优先权的线程那个首先被执行，当要访问对象的锁被 释放后处于等待池的多个线程哪个会优先得到，等等。我想最终的决定权是在JVM，之所以不保证，就是因为JVM在做出上述决定的时候，绝不是简简单单根据 一个条件来做出判断，而是根据很多条。而由于判断条件太多，如果说出来可能会影响JAVA的推广，也可能是因为知识产权保护的原因吧。SUN给了个不保证 就混过去了。无可厚非。但我相信这些不确定，并非完全不确定。因为计算机这东西本身就是按指令运行的。即使看起来很随机的现象，其实都是有规律可寻。学过 计算机的都知道，计算机里随机数的学名是伪随机数，是人运用一定的方法写出来的，看上去随机罢了。另外，或许是因为要想弄的确太费事，也没多大意义，所 以不确定就不确定了吧。）
再来看看同步代码块。和同步方法有小小的不同。
1.从尺寸上讲，同步代码块比同步方法小。你可以把同步代码块看成是没上锁房间里的一块用带锁的屏风隔开的空间。
2.同步代码块还可以人为的指定获得某个其它对象的key。就像是指定用哪一把钥匙才能开这个屏风的锁，你可以用本房的钥匙；你也可以指定用另一个房子的钥匙才能开，这样的话，你要跑到另一栋房子那儿把那个钥匙拿来，并用那个房子的钥匙来打开这个房子的带锁的屏风。
记住你获得的那另一栋房子的钥匙，并不影响其他人进入那栋房子没有锁的房间。
为什么要使用同步代码块呢？我想应该是这样的：首先对程序来讲同步的部分很影响运行效率，而一个方法通常是先创建一些局部变量，再对这些变量做一些 操作，如运算，显示等等；而同步所覆盖的代码越多，对效率的影响就越严重。因此我们通常尽量缩小其影响范围。
如何做？同步代码块。我们只把一个方法中该同 步的地方同步，比如运算。
另外，同步代码块可以指定钥匙这一特点有个额外的好处，是可以在一定时期内霸占某个对象的key。还记得前面说过普通情况下钥匙的使用原则吗。现在不是普通情况了。你所取得的那把钥匙不是永远不还，而是在退出同步代码块时才还。
还用前面那个想连续用两个上锁房间的家伙打比方。怎样才能在用完一间以后，继续使用另一间呢。用同步代码块吧。先创建另外一个线程，做一个同步代码块，把那个代码块的锁指向这个房子的钥匙。然后启动那个线程。只要你能在进入那个代码块时抓到这房子的钥匙，你就可以一直保留到退出那个代码块。也就是说 你甚至可以对本房内所有上锁的房间遍历，甚至再sleep(10601000)，而房门口却还有1000个线程在等这把钥匙呢。很过瘾吧。
synchronized作用于静态方法和非静态方法的区别:
- 非静态方法:
- 给对象加锁(可以理解为给这个对象的内存上锁,注意 只是这块内存,其他同类对象都会有各自的内存锁),这时候
- 在其他一个以上线程中执行该对象的这个同步方法(注意:是该对象)就会产生互斥
- 静态方法:
- 相当于在类上加锁(*.class 位于代码区,静态方法位于静态区域,这个类产生的对象公用这个静态方法,所以这块
- 内存，N个对象来竞争), 这时候,只要是这个类产生的对象,在调用这个静态方法时都会产生互斥
最后锁的分类以及扩展可以看这篇博客：不可不说的Java“锁”事
Lock锁
ReentrantLock 使用代码实现了和 synchronized 一样的语义，包括可重入，保证内存可见性和解决竞态条件问题等。相比 synchronized，它还有如下好处：
支持以非阻塞方式获取锁
可以响应中断
可以限时
支持了公平锁和非公平锁
ReentrantLock 和 synchronized 的区别：
ReentrantLock是一个可重入的互斥锁，具有与使用 synchronized 方法和语句所访问的隐式监视器锁定相同的基本行为和语义
1）与synchronized相比，ReentrantLock提供了获取锁的扩展功能，例如可中断的锁，快速失败的非等待锁，以及制定时间的锁。
2）ReentrantLock提供了条件Condition，对线程的等待、唤醒操作更加详细和灵活，在多条件变量和高度竞争的环境下，ReentrantLock提供了更高的性能。（Condition相关放在后续整理）
3）ReentrantLock提供了可轮询的锁请求，它会尝试去获取锁，成功则继续，失败则等待下次继续处理。而synchronized一旦进入锁请求要么成功要么阻塞，更容易行成死锁。
4）ReentrantLock支持更加灵活的同步代码块，synchronized只能在同一个结构快中处理。此处注意：ReentrantLock的锁释放一定要在finally中处理，否则很可能产生严重的后果。
5）ReentrantLock支持中断处理，由于内部使用了很多CAS无锁操作，所以性能较好。
6）ReentrantLock的锁和获取需要代码显示的声明和执行，synchronized则是JVM保证了每一个monitorenter都对应一个monitorexit。
基本用法如下：
public class Counter {
private final Lock lock = new ReentrantLock();
private volatile int count;
public void incr() {
lock.lock();
try {
count++;
} finally {
lock.unlock();
}
}
public int getCount()
{
return count;
}
}ReentrantLock 类的结构关系：
AQS 全称 AbstractQueuedSynchronizer。AQS 中有两个重要的成员：
成员变量 state。用于表示锁现在的状态，用 volatile 修饰，保证内存一致性。同时所用对 state 的操作都是使用 CAS 进行的。state 为0表示没有任何线程持有这个锁，线程持有该锁后将 state 加1，释放时减1。多次持有释放则多次加减。
AQS 还有一个双向链表，链表除了头结点外，每一个节点都记录了线程的信息，代表一个等待线程。这是一个 FIFO 的链表。
ReentrantLock和AbstractQueuedSynchronizer的关系
ReentrantLock源码：
构造器和内部静态类：默认是非公平锁
（ReentrantLock 内部有两个内部类，分别是 FairSync 和 NoFairSync，对应公平锁和非公平锁。他们都继承自 Sync。Sync 又继承自AQS。）
/**
默认构造器
*/
public ReentrantLock() {
sync = new NonfairSync();
}
/**
根据参数进行构造
*/
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
/**
内部静态类公平锁
*/
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);
}
/**
* Fair version of tryAcquire. Don't grant access unless
* recursive call or no waiters or is first.
*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
}
/**
内部静态类非公平锁
*/
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
/**
* Performs lock. Try immediate barge, backing up to normal
* acquire on failure.
*/
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}ReentrantLock获取锁的几种方式：
ReentrantLock共有4中获取锁的方式：1、lock 2、lockInterruptibly() throws InterruptedException 3、tryLock 4、tryLock(long timeout, TimeUnit unit) throws InterruptedException，如下：
public void lock() {
sync.lock();
}
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
public boolean tryLock() {
return sync.nonfairTryAcquire(1);
}
public boolean tryLock(long timeout, TimeUnit unit)
throws InterruptedException {
return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}先简单介绍：
lock()
最简单的获取锁方式，尝试获取锁。
1）如果当前锁没有被其他线程持有，则当前线程会立即获取锁并返回，并且设置lock count 为1。
2）如果当前线程已经持有该锁，那么会直接返回，并且 lock count +1。
3）如果锁被其他线程持有，则当前线程在线程调度的状态会变成不可用，然后会被设置为休眠状态，直到线程获取到锁，在获取锁的同时 lock count 置为1。
lockInterruptibly() throws InterruptedException
整体逻辑和lock() 一样，但是该锁是可以被打断的，被打断后，会抛出 InterruptedException。
tryLock()
非阻塞的获取锁。
只有在当前锁没有被其他线程持有的时候，才会获取锁并且马上返回true。
否则会返回false。
源码可以看到，该方法的底层是直接调用的nonfairTryAcquire(1)。
所以说，不管当前重入锁声明的是什么策略，都不会影响该方法的行为。
PS：如果想使用公平锁的策略，并且使用非阻塞的tryLock()，那么可以使用下面的带有过期时间的 tryLock();
tryLock(long timeout, TimeUnit unit) throws InterruptedException
有过期时间的 tryLock()。
在指定时间之内没有获取到锁的话，就会返回false。
在这个时间内获取锁的策略，是支持公平和非公平的。
【需要注意的是】：如果使用的是公平锁的策略，那么即使该锁当前是可用的，也会在队列后面排队。（也就是公平锁策略，排队等待，而不是抢占式）
lock方法：
abstract void lock();
//公平锁实现：
final void lock() {
acquire(1);
}
//非公平锁实现
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}非公平锁的实现包含了公平锁：所以我们先讲非公平锁的过程：
请求锁时有三种可能：
1、如果没有线程持有锁，则请求成功，当前线程直接获取到锁。
2、如果当前线程已经持有锁，则使用 CAS 将 state 值加1，表示自己再次申请了锁，释放锁时减1。这就是可重入性的实现。
3、如果由其他线程持有锁，那么将自己添加进等待队列。
final void lock() {
//如果该锁被其他线程持有，则state值为1，compareAndSetState(0, 1)即想将state的值从0改成1，但可惜已经是1了，所以返回fasle
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread()); //没有线程持有锁时，直接获取锁
else
acquire(1);
}compareAndSetState(0, 1)进行了cas比较，进入方法：
protected final boolean compareAndSetState(int expect, int update) {
// See below for intrinsics setup to support this
return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
再进入
setExclusiveOwnerThread方法：该方法是**AbstractOwnableSynchronizer类下的方法**，
```bash
protected final void setExclusiveOwnerThread(Thread thread) {
exclusiveOwnerThread = thread;
}前面是if条件下的（没有线程持有锁时，直接获取锁），然后我们看下else 的acquire方法：AbstractQueuedSynchronizer下的方法：代表公平锁和非公平锁都走这个大的父类方法，俩个内部类没有重写
public final void acquire(int arg) {
//在此方法中会判断当前持有线程是否等于自己，arg入参为1，代表锁被其他线程持有。
//tryAcquire(arg)当为false时，代表再次获取锁失败，进入下面一个判断
//如果由其他线程持有锁，那么将自己添加进等待队列。
if (!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();//自旋
}acquire这里干了三件事情：
tryAcquire：会尝试再次通过CAS获取一次锁。
addWaiter：将当前线程加入上面锁的双向链表（等待队列）中
acquireQueued：通过自旋，判断当前队列节点是否可以获取锁。
三个方法详细：
tryAcquire：
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
final boolean nonfairTryAcquire(int acquires) {//参数传进来的时候为1,代表上锁了
//拿到当前线程和持锁线程进行比较判断
final Thread current = Thread.currentThread();
//这个state是父类AQS 的private volatile int state，当为0时代表没有上锁
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
//如果上锁则获取上锁的线程，判断是否和当前线程为同一个
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;//1+state，可重入叠加，释放锁也就是对AQS中的状态值State进行回改
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}addWaiter：
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
//这个tail是AQS的 private transient volatile Node tail;双向链表的尾结点，新建节点加入尾结点并返回该节点
Node pred = tail;
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
enq(node);
return node;
}acquireQueued：参数node为add返回的节点，arg为1表示锁被其他线程持有
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
/*
前面addWaiter已经创建 Node 节点并加入链表
如果没竞争到锁，这时候就要进入等待队列。队列是默认有一个 head 节点的，并且不包含线程信息。
上面情况3中，addWaiter 会创建一个 Node，并添加到链表的末尾，Node 中持有当前线程的引用。
同时还有一个成员变量 waitStatus，表示线程的等待状态，初始值为0。我们还需要关注两个值：
CANCELLED，值为1，表示取消状态，就是说我不要这个锁了，请你把我移出去。
SINGAL，值为-1，表示下一个节点正在挂起等待，注意是下一个节点，不是当前节点。
同时，加到链表末尾的操作使用了 CAS+死循环的模式
*/
private Node enq(final Node node) {
for (;;) {//死循环
//不断循环拿到该节点的前一个节点，判断是否锁的获取马上到自己了
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}可以看到，在死循环里调用了 CAS 的方法。如果多个线程同时调用该方法，那么每次循环都只有一个线程执行成功，其他线程进入下一次循环，重新调用。N个线程就会循环N次。这样就在无锁的模式下实现了并发模型。
挂起等待
如果此节点的上一个节点是头部节点，则再次尝试获取锁，获取到了就移除并返回。获取不到就进入下一步；
判断前一个节点的 waitStatus，如果是 SINGAL，则返回 true，并调用 LockSupport.park() 将线程挂起；
如果是 CANCELLED，则将前一个节点移除；
如果是其他值，则将前一个节点的 waitStatus 标记为 SINGAL，进入下一次循环。
可以看到，一个线程最多有两次机会，还竞争不到就去挂起等待。
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
//同时还有一个成员变量 waitStatus，表示线程的等待状态，初始值为0
int ws = pred.waitStatus;
//SINGAL，值为-1，表示下一个节点正在挂起等待
if (ws == Node.SIGNAL)
/*
* This node has already set status asking a release
* to signal it, so it can safely park.
*/
return true;
if (ws > 0) {
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
/*
* waitStatus must be 0 or PROPAGATE. Indicate that we
* need a signal, but don't park yet. Caller will need to
* retry to make sure it cannot acquire before parking.
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}AbstractQueuedSynchronizer会把所有的请求线程构成一个CLH队列，当一个线程执行完毕（lock.unlock()）时会激活自己的后继节点，但正在执行的线程并不在队列中，而那些等待执行的线程全部处于阻塞状态，经过调查线程的显式阻塞是通过调用LockSupport.park()完成，而LockSupport.park()则调用 sun.misc.Unsafe.park()本地方法
公平锁如何实现
上面分析的是非公平锁，那公平锁呢？很简单，在竞争锁之前判断一下等待队列中有没有线程在等待就行了。
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
}
--------------------------------对比前面的非公平锁的方法------------------------：
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}这里可以看到
NonfairSync的 tryAcquire() 调用的还是 Sync的非公平获取。
FairSync 自己实现了公平的方式的 tryAcquire()。但其实通过代码可以发现，公平锁的 tryAcquire()对比Sync的 nonfairTryAcquire() 几乎一模一样，只是多了一个判断条件：!hasQueuedPredecessors()，加了个非号，也就是判断当前线程是否在CLH同步队列的第一个，如果是则往下走CAS获取锁，否则走重入逻辑。
lockInterruptibly() throws InterruptedException
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
public final void acquireInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
//tryAcquire(arg)可以是公平锁也可是非公平锁，根据内部实现类决定
if (!tryAcquire(arg))
doAcquireInterruptibly(arg);
}
//这个方法和前面lock里的enq(final Node node)方法一样，只不过多了抛异常这个动作
private void doAcquireInterruptibly(int arg)
throws InterruptedException {
final Node node = addWaiter(Node.EXCLUSIVE);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}整体逻辑和lock() 一样，但是该锁是可以被打断的，被打断后，会抛出 InterruptedException。
tryLock()
public boolean tryLock() {
return sync.nonfairTryAcquire(1);
}
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}trylock方法直接调用非公平锁的方法，如上讲过，不讲了
tryLock(long timeout, TimeUnit unit) throws InterruptedException
public boolean tryLock(long timeout, TimeUnit unit)
throws InterruptedException {
return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}
public final boolean tryAcquireNanos(int arg, long nanosTimeout)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
return tryAcquire(arg) ||
doAcquireNanos(arg, nanosTimeout);
}
//可以看到，和tryLock比较起来，多了时间判断一步，其他没区别
private boolean doAcquireNanos(int arg, long nanosTimeout)
throws InterruptedException {
if (nanosTimeout <= 0L)
return false;
final long deadline = System.nanoTime() + nanosTimeout;
final Node node = addWaiter(Node.EXCLUSIVE);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return true;
}
//如果超时，则直接return出来
nanosTimeout = deadline - System.nanoTime();
if (nanosTimeout <= 0L)
return false;
if (shouldParkAfterFailedAcquire(p, node) &&
nanosTimeout > spinForTimeoutThreshold)
LockSupport.parkNanos(this, nanosTimeout);
if (Thread.interrupted())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}简述总结：
总体来讲线程获取锁要经历以下过程(非公平)：
1、调用lock方法，会先进行cas操作看下可否设置同步状态1成功，如果成功执行临界区代码
2、如果不成功获取同步状态，如果状态是0那么cas设置为1.
3、如果同步状态既不是0也不是自身线程持有会把当前线程构造成一个节点。
4、把当前线程节点CAS的方式放入队列中，行为上线程阻塞，内部自旋获取状态。
（acquireQueued的主要作用是把已经追加到队列的线程节点进行阻塞，但阻塞前又通过tryAccquire重试是否能获得锁，如果重试成功能则无需阻塞，直接返回。）
5、线程释放锁，唤醒队列第一个节点，参与竞争。重复上述。
