synchronized
synchronized 关键字经过编译之后，会在同步块前后分别形成 monitorenter 和 monitorexit 这两个字节码指令，这两个字节码都需要一个 reference 类型的参数来指明要锁定和解锁的对象；如果程序中的 synchronized 明确指定了对象参数，那就是这个对象的 reference；如果没有指定，就根据 synchronized 修饰的是实例方法还是类方法，去取对应的对象实例或 Class 对象来作为锁对象
synchronized 的本质都是获取、占有、释放 monitor 锁对象实现互斥
在执行 monitorenter 指令时，首先要尝试获取对象的锁。如果该对象没被锁定，或者当前线程已经拥有了那个对象的锁，把锁的计数器加 1，相应的，在执行 monitorexit 指令时会将锁计数器减 1，当锁计数器为 0 时，锁就被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到对象锁被另一个线程释放
Java 的线程是映射到操作系统的原生线程之上的，如果要阻塞或唤醒一个线程，都需要操作系统来帮忙，这就需要从用户态转换到核心态中，因此状态转换需要很多的 CPU 时间。所以 synchronized 是 Java 语言中的一个重量级操作
ReentrantLock
ReentrantLock 与 synchronized 基本用法很相似，都具备一样的线程重入特性。只是代码写法上有区别：一个是 API 层面的互斥锁（lock() 和 unlock() 方法配合 try/finally 语句块来完成），另一个表现为原生语法层面的互斥锁
相比 synchronized，ReentrantLock 增加了一些高级功能：
等待可中断：当持有锁的线程长期不释放锁时，正在等待的线程可以选择放弃等待，改为处理其他事情，可中断特性对处理执行时间很长的同步块很有帮助。调用方法：boolean tryLock()、boolean tryLock(long timeout)
公平锁：多个线程在等待同一个锁时，必须按申请锁的时间顺序来依次获得锁；而非公平锁不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized 中的锁是非公平的，ReentrantLock 默认情况下也是非公平的，但可以通过带布尔值的构造函数要求使用公平锁
锁绑定多个条件：一个 ReentrantLock 对象可以同时绑定多个 Condition 对象，而在 synchronized 中，锁对象的 wait() 和 notify() 或 notifyAll() 方法可以实现一个隐含的条件，如果要和多于一个的条件关联的时候，就不得不额外添加一个锁，而 ReentrantLock 无须这样，只需多次调用 newCondition() 方法即可
此外，还可以使用 ReentrantReadWriteLock 类实现读写锁：
lock.readLock().lock()
lock.writeLock().lock()
锁优化
JDK 1.6 以后 synchronized 与 ReentrantLock 性能基本持平，这是因为 1.6 中实现了各种锁优化技术
自旋锁与适应性自旋
互斥同步对性能最大的影响是阻塞的实现，挂起线程和回复线程的操作都需要转入内核态中完成，这些操作给系统的并发性能带来了很大压力
在许多应用上，共享数据的锁定状态只会持续很短时间，为了这段时间去挂起和恢复线程并不值得
如果有两个或以上线程同时并行执行，就可以让后面请求锁的那个线程 “稍等一下”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，只需让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁
自旋等待不能代替阻塞，且先不说对处理器数量的要求（注意上面的并行），因为自旋等待本身虽然避免了线程切换的开销，但它是要占有处理器时间的，因此如果锁被占用的时间很短，自旋等待的效果就很好。否则，自旋的线程只会白白消耗处理器资源。所以自旋等待的时间必须要有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，就应该使用传统的方式去挂起线程了
JDK 1.6 引入了自适应的自旋锁。自适应意味着自旋的时间不再固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者状态来决定。如果在同一个锁对象上，自旋刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而它将允许自旋等待持续更长的时间。另外如果对于某个锁，自旋很少成功获得过，那在以后获取这个锁时将可能省略自旋过程，以避免浪费处理器资源
锁消除
锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析技术。如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行
public static String concatString(String s1, String s2, String s3) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
sb.append(s3);
return sb.toString();
}
每个 StringBuffer.append() 方法中都有一个同步块，锁就是 sb 对象。虚拟机观察变量 sb，很快就会发现它的动态作用域被限制在 concatString() 方法内部。也就是说，sb 的所有引用永远不会 “逃逸” 到 concatString() 方法之外，其他线程无法访问到它，因此，虽然这里有锁，但是可以被安全地消除掉，在即时编译之后，这段代码就会忽略掉所有的同步而直接执行了
锁粗化
原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待锁的线程也能尽快拿到锁
大部分情况下，上面的原则都是正确的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗
上面代码中连续的 append() 方法就属于这类情况。如果虚拟机探测到有这样的一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部，以上面的代码为例，就是扩展到第一个 append() 操作之前直至最后一个 append() 操作之后，这样只需要加锁一次就可以了
对象头
synchronized 用的锁是存在对象头里的。如果对象是数组类型，则虚拟机用 3 字宽（Word）存储对象头，如果对象是非数组类型，则用 2 字宽存储对象头。在 32 位虚拟机中，1 字宽等于 4 字节，即 32bit
| 长度 | 内容 | 说明 |
|---|---|---|
| 32/64 bit | Mark Word | 存储对象的 HashCode 或锁信息等 |
| 32/64 bit | Class Metadata Address | 存储到对象类型数据的指针 |
| 32/64 bit | Array length | 数组长度（如果当前对象是数组） |
对象头信息是与对象自身定义的数据无关的额外储存成本，考虑到虚拟机空间效率，Mark Word 被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。各状态下对象的存储内容如下：
轻量级锁
轻量级，是相对于使用操作系统互斥量（monitor 锁）的重量级锁而言的，因此传统锁机制就称为 “重量级”锁。轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗
线程发生竞争锁的时候，不会直接进入阻塞状态，而是先尝试做 CAS 修改操作，进入自旋，这个过程避免了线程状态切换的开销，不过要消耗 CPU 资源。详细过程：
在线程进入同步块之前，如果此同步对象没被锁定（锁标志位为 “01” 标志），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，并将锁对象头中的 Mark Word 的拷贝到锁记录中，官方称该拷贝为 Displaced Mark Word
然后 JVM 尝试使用 CAS 操作将对象头中的 Mark Word 更新为指向锁记录的指针。如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且 Mark Word 的锁标志位将转变为 “00”，即表示此对象属于轻量级锁定状态。如果这个更新操作失败了，JVM 首先会检查对象的 Mark Word 是否指向当前线程栈帧的 “锁记录”，如果是说明当前线程已经拥有了这个对象的锁，直接重入即可；否则说明这个锁对象已经被其他线程抢占了，当前线程便尝试使用自旋来获得锁。若自旋失败，那轻量级锁就不再有效，要膨胀为重量级锁，锁标志的状态值变为 “10”，Mark Word 中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态
解锁时，如果对象的 Mark Word 仍然指向线程的锁记录，那就用 CAS 操作把对象当前的 Mark Word 和线程中复制的 Displaced Mark Word 替换回来，如果替换成功，整个同步过程就完成了。如果替换失败，说明有其他线程尝试过获取该锁（此时锁已膨胀），那就要在释放锁的同时，唤醒被挂起的线程
轻量级锁能提升程序同步性能的依据是：对于大部分锁，在整个同步周期内都是不存在竞争的。如果没有竞争，轻量级锁使用 CAS 操作避免了使用互斥量的开销，但如果存在锁竞争，除了互斥量的开销外，还额外发生了 CAS，因此有竞争的情况下，轻量级锁会比传统重量级锁更慢
偏向锁
偏向锁也是 JDK 1.6 中引入的一项锁优化，它的目的是消除数据在无竞争情况下的同步原语，进一步提高程序运行性能。如果说轻量级锁是在无竞争情况下使用 CAS 操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除，连 CAS 都不做
偏向锁的 “偏”，是偏心的 “偏”，它的意思是这个锁会偏向第一个获得它的线程，如果在接下来的执行过程中，该锁没有被其他线程获取，则持有偏向锁的线程将永远不需要再进行同步
假设当前虚拟机启用了偏向锁，那么当锁对象第一次被线程获取的时候，虚拟机将会把锁对象头中的标志位设为 “01”，即偏向模式。同时使用 CAS 操作把获取到这个锁的线程 ID 记录在对象的 Mark Word 之中，如果 CAS 操作成功，以后该线程在进入和退出同步块时不需要进行 CAS 操作来加锁和解锁，只需简单的比较线程 ID 即可。如果比较成功，表示线程已经获得锁；如果比较失败，则需要再看一下 Mark Word 中偏向锁的标识是否设置成 “01”：如果没有设置，则使用 CAS 竞争锁；如果设置了，则尝试使用 CAS 将对象头的偏向锁指向当前线程
偏向锁使用了一种直到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有正在执行的字节码）。它会首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着：
- 如果线程已执行完，将对象头设置成无锁状态，标志位为 “01”
- 如果线程还在持有该锁，则锁升级为轻量级锁，标志位为 “00”，后续的同步操作就如上面介绍的轻量级锁那样执行
偏向锁、轻量级锁的状态转化及对象 Mark Word 的关系如下：
偏向锁可以提高带有同步但无竞争的程序性能。它同样是一个带有效益权衡（Trade Off）性质的优化，也就是说，它并不一定总是对程序运行有利，如果程序中大多数的锁总是被多个不同的线程访问，那偏向模式就是多余的
锁的升级
在 Java 1.6 中，锁一共有 4 种状态，级别从低到高：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态。这几个状态会随着竞争情况逐渐升级。锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁
锁的优缺点对比
| 锁 | 优点 | 缺点 | 试用场景 |
|---|---|---|---|
| 偏向锁 | 加锁和解锁不需要额外消耗，和执行非同步方法相比仅存在纳米级差距 | 如果线程间存在锁竞争，会带来额外的锁撤销的消耗 | 适用于只有一个线程访问同步块的场景 |
| 轻量级锁 | 竞争的线程不会阻塞，提高了响应速度 | 如果有始终得不到锁竞争的线程，使用自旋会消耗 CPU | 追求响应时间、同步块执行速度非常快 |
| 重量级锁 | 线程竞争不使用自旋，不会消耗 CPU | 线程阻塞，响应时间缓慢 | 追求吞吐量、同步块执行速度较长 |