前言
我相信，很多人一说到Java中的锁，就会想到Synchronizeed关键字，Synchronized关键字是对象锁，可以加在方法上，可以放在代码块上等等用法。还有你可能会想到重量级锁、非公平锁、悲观索等等内容。今天从它的各个名称入手，我们来分析它的一些偏原理方面的内容。
各个名称介绍
名称一：悲观锁
说起人的悲观，那肯定是对于某一方面很悲观，比如我觉得我的Java基础很不好，找不到工作。我觉得我今天会倒霉……等等。那Java中的悲观是对于哪一方面？当然是共享变量或代码块。悲观锁认为，这个共享变量一定会发生争抢，所以每次使用的时候，我都要先对共享变量加锁，一直到我使用完成之后，才释放锁别人用。
说完了悲观锁，那必须得说说乐观锁，同样的，乐观锁认为，这个共享变量或代码块不会轻易的产生并发冲突，即便产生了冲突，我也只需要等一会就可以操作这个共享变量或代码块。典型的例子就是CAS（CompareAndSet）操作。
名称二： 偏向锁/轻量级锁/重量级锁
在JDK 6 以前，并没有对Synchronized做优化，其背后一直是依赖着操作系统底层的一些命令实现。因此称其为重量级锁。在JDK 6 之后，Synchronized被优化了，之后他的性能其实不必Lock低。
名称三：非公平锁
首先，我们来看下什么是公平锁和非公平锁，公平锁指的是按照线程请求的顺序，来分配锁；而非公平锁指的是不完全按照请求的顺序，在一定情况下，可以允许插队。但需要注意这里的非公平并不是指完全的随机，不是说线程可以任意插队，而是仅仅“在合适的时机”插队。
那么什么时候是合适的时机呢？假设当前线程在请求获取锁的时候，恰巧前一个持有锁的线程释放了这把锁，那么当前申请锁的线程就可以不顾已经等待的线程而选择立刻插队。但是如果当前线程请求的时候，前一个线程并没有在那一时刻释放锁，那么当前线程还是一样会进入等待队列。
为了能够更好的理解公平锁和非公平锁，我们举一个生活中的例子，假设我们还在学校读书，去食堂排队买饭，我排在队列的第二个，我前面还有一位同学，但此时我脑子里想的不是午饭，而是上午的一道数学题并陷入深思，所以当前面的同学打完饭之后轮到我时我走神了，并也没注意到现在轮到我了，此时前面的同学突然又回来插队，说“不好意思，阿姨麻烦给我加个鸡腿”，像这样的行为就可以类比我们的公平锁和非公平锁。
看到这里，你可能不解，为什么要设置非公平策略呢，而且非公平还是 ReentrantLock的默认策略，如果我们不加以设置的话默认就是非公平的，难道我的这些排队的时间都白白浪费了吗，为什么别人比我有优先权呢？毕竟公平是一种很好的行为，而非公平是一种不好的行为。
让我们考虑一种情况，假设线程 A 持有一把锁，线程 B 请求这把锁，由于线程 A 已经持有这把锁了，所以线程 B 会陷入等待，在等待的时候线程 B 会被挂起，也就是进入阻塞状态，那么当线程 A 释放锁的时候，本该轮到线程 B 苏醒获取锁，但如果此时突然有一个线程 C 插队请求这把锁，那么根据非公平的策略，会把这把锁给线程 C，这是因为唤醒线程 B 是需要很大开销的，很有可能在唤醒之前，线程 C 已经拿到了这把锁并且执行完任务释放了这把锁。相比于等待唤醒线程 B 的漫长过程，插队的行为会让线程 C 本身跳过陷入阻塞的过程，如果在锁代码中执行的内容不多的话，线程 C 就可以很快完成任务，并且在线程 B 被完全唤醒之前，就把这个锁交出去，这样是一个双赢的局面，对于线程 C 而言，不需要等待提高了它的效率，而对于线程 B 而言，它获得锁的时间并没有推迟，因为等它被唤醒的时候，线程 C 早就释放锁了，因为线程 C 的执行速度相比于线程 B 的唤醒速度，是很快的，所以 Java 设计者设计非公平锁，是为了提高整体的运行效率。
对比公平和非公平的优缺点
我们接下来对比公平和非公平的优缺点，如表格所示。
公平锁的优点在于各个线程公平平等，每个线程等待一段时间后，都有执行的机会，而它的缺点就在于整体执行速度更慢，吞吐量更小，相反非公平锁的优势就在于整体执行速度更快，吞吐量更大，但同时也可能产生线程饥饿问题，也就是说如果一直有线程插队，那么在等待队列中的线程可能长时间得不到运行。
名称四：可重入锁
当某个线程A已经持有了一个锁,当线程B尝试进入被这个锁保护的代码段的时候.就会被阻塞.
可重入 就是说某个线程已经获得某个锁，可以再次获取锁而不会出现死锁。
而锁的操作粒度是”线程”,而不是调用.。同一个线程再次进入同步代码的时候.可以使用自己已经获取到的锁,这就是可重入锁。
名称五：对象锁
Synchronized又称之为对象锁，因为其是依赖于每个对象都关联的一个Monitor对象。
大概功能与下图类似。
EntryList中存放着阻塞等待Monitor的线程。 （BLOCKED状态）
WaitSet中存放着获取过Monitor但是不满足执行条件的线程 。（WAITING状态）（wait方法）
BLOCKER状态的线程会在Owner线程释放锁时唤醒。
WAITING线程会在Owner线程调用notify或notifyAll时唤醒，但是唤醒后并不意味着立刻获取锁，会进入EntryList重新竞争。
这下你该知道，为什么有些方法（wait、notify）放在了Object类中了吧
如何看到synchronized 背后的 monitor 锁。
获取和释放 monitor 锁的时机
我们都知道，最简单的同步方式就是利用 synchronized 关键字来修饰代码块或者修饰一个方法，那么这部分被保护的代码，在同一时刻就最多只有一个线程可以运行，而 synchronized 的背后正是利用 monitor 锁实现的。所以首先我们来看下获取和释放 monitor 锁的时机，每个 Java 对象都可以用作一个实现同步的锁，这个锁也被称为内置锁或 monitor 锁，获得 monitor 锁的唯一途径就是进入由这个锁保护的同步代码块或同步方法，线程在进入被 synchronized 保护的代码块之前，会自动获取锁，并且无论是正常路径退出，还是通过抛出异常退出，在退出的时候都会自动释放锁。
我们首先来看一个 synchronized 修饰方法的代码的例子：
public synchronized void method() {
method body
}
我们看到 method() 方法是被 synchronized 修饰的，为了方便理解其背后的原理，我们把上面这段代码改写为下面这种等价形式的伪代码。
public void method() {
this.intrinsicLock.lock();
try{
method body
}
finally {
this.intrinsicLock.unlock();
}
}
在这种写法中，进入 method 方法后，立刻添加内置锁，并且用 try 代码块把方法保护起来，最后用 finally 释放这把锁，这里的 intrinsicLock 就是 monitor 锁。经过这样的伪代码展开之后，相信你对 synchronized 的理解就更加清晰了。
用 javap 命令查看反汇编的结果
JVM 实现 synchronized 方法和 synchronized 代码块的细节是不一样的，下面我们就分别来看一下两者的实现。
同步代码块
首先我们来看下同步代码块的实现，如代码所示。
public class SynTest {
public void synBlock() {
synchronized (this) {
System.out.println("lagou");
}
}
}
在 SynTest 类中的 synBlock 方法，包含一个同步代码块，synchronized 代码块中有一行代码打印了 lagou 字符串，下面我们来通过命令看下 synchronized 关键字到底做了什么事情：首先用 cd 命令切换到 SynTest.java 类所在的路径，然后执行 javac SynTest.java，于是就会产生一个名为 SynTest.class 的字节码文件，然后我们执行 javap -verbose SynTest.class，就可以看到对应的反汇编内容。
关键信息如下：
public void synBlock();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=2, locals=3, args_size=1
0: aload_0
1: dup
2: astore_1
3: monitorenter
4: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
7: ldc #3 // String lagou
9: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
12: aload_1
13: monitorexit
14: goto 22
17: astore_2
18: aload_1
19: monitorexit
20: aload_2
21: athrow
22: return
从里面可以看出，synchronized 代码块实际上多了 monitorenter 和 monitorexit 指令，标红的第3、13、19行指令分别对应的是 monitorenter 和 monitorexit。这里有一个 monitorenter，却有两个 monitorexit 指令的原因是，JVM 要保证每个 monitorenter 必须有与之对应的 monitorexit，monitorenter 指令被插入到同步代码块的开始位置，而 monitorexit 需要插入到方法正常结束处和异常处两个地方，这样就可以保证抛异常的情况下也能释放锁
可以把执行 monitorenter 理解为加锁，执行 monitorexit 理解为释放锁，每个对象维护着一个记录着被锁次数的计数器。未被锁定的对象的该计数器为 0，我们来具体看一下 monitorenter 和 monitorexit 的含义：
monitorenter
执行 monitorenter 的线程尝试获得 monitor 的所有权，会发生以下这三种情况之一：
a. 如果该 monitor 的计数为 0，则线程获得该 monitor 并将其计数设置为 1。然后，该线程就是这个 monitor 的所有者。
b. 如果线程已经拥有了这个 monitor ，则它将重新进入，并且累加计数。
c. 如果其他线程已经拥有了这个 monitor，那个这个线程就会被阻塞，直到这个 monitor 的计数变成为 0，代表这个 monitor 已经被释放了，于是当前这个线程就会再次尝试获取这个 monitor。
monitorexit
monitorexit 的作用是将 monitor 的计数器减 1，直到减为 0 为止。代表这个 monitor 已经被释放了，已经没有任何线程拥有它了，也就代表着解锁，所以，其他正在等待这个 monitor 的线程，此时便可以再次尝试获取这个 monitor 的所有权。
同步方法
从上面可以看出，同步代码块是使用 monitorenter 和 monitorexit 指令实现的。而对于 synchronized 方法，并不是依靠 monitorenter 和 monitorexit 指令实现的，被 javap 反汇编后可以看到，synchronized 方法和普通方法大部分是一样的，不同在于，这个方法会有一个叫作 ACC_SYNCHRONIZED 的 flag 修饰符，来表明它是同步方法。
同步方法的代码如下所示。
public synchronized void synMethod() {
}
对应的反汇编指令如下所示。
public synchronized void synMethod();
descriptor: ()V
flags: ACC_PUBLIC, ACC_SYNCHRONIZED
Code:
stack=0, locals=1, args_size=1
0: return
LineNumberTable:
line 16: 0
总结
- Synchronized关键字是一个种锁，其有很多名字，例如重量级锁、悲观锁、可重入锁、、非公平、对象锁等等。
- Synchronized其实是被优化过的对象，存在着从 无锁-> 偏向锁 -> 轻量级锁 -> 重量级锁的升级过程，只有升级到了重量级锁，才会去依赖Monitor对象。关于锁是否是只能升级不能降级，网上有很多说法，这里我认为是可以降级的，大家感兴趣可以去搜一下。
- Synchronized关键字底层实现是依赖于每一个对象独有的Monitor对象，Monitor对象是采用C++编写的一个对象，它直接调用操作系统的指令，
monitorenter和monitorexit指令，其中monitorenter指令指向同步代码块的开始位置，monitorexit指令则指明同步代码块的结束位置。 - 我们想看到Java在何处调用该指令 可以采用
javap命令对编译后的 .class文件执行。
