首先要先了解Java中的锁，这就不得不提synchronized关键字和concurrent 包中的ReentrantLock。
synchronized关键字
synchronized 可以用来修饰以下 3 个层面：
1、修饰实例方法：锁对象是当前实例对象。不同实例对象是不互斥的。
2、修饰静态类方法：锁对象是当前类的 Class 对象。因此即使在不同线程中调用不同实例对象，也会有互斥效果。
3、修饰代码块：synchronized 作用于代码块时，锁对象就是跟在后面括号中的对象。任何 Object 对象都可以当作锁对象。
ReentrantLock
ReentrantLock 的使用同 synchronized 有点不同，它的加锁和解锁操作都需要手动完成。
//lock为ReentrantLock的实例对象
lock.lock();
lock.unlock();
synchronized和ReentrantLock的区别
说到他们的区别，首先先要看看我们用了synchronized关键字的字节码是什么样子的。代码如下：
图1 synchronized修饰代码块
使用javap -v xxx.class查看字节码，如下：
图2 synchronized修饰代码块对应字节码
可以看出在字节码中加入了1个monitorenter和2个monitorexit。这是因为虚拟机需要保证当异常发生时也能释放锁。因此 2 个 monitorexit 一个是代码正常执行结束后释放锁，一个是在代码执行异常时释放锁。
因此在使用synchronized关键字时，虚拟机会自动在同步代码块的开始和结束（或异常）位置添加 monitorenter 和 monitorexit 指令。
而在ReentrantLock的使用中，应该将 unlock 操作放在 finally 代码块中。这是因为 ReentrantLock 与 synchronized 不同，当异常发生时 synchronized 会自动释放锁，但是 ReentrantLock 并不会自动释放锁。因此好的方式是将 unlock 操作放在 finally 代码块中，保证任何时候锁都能够被正常释放掉。
ReentrantLock还可以实现公平锁（ReentrantLock初始化时传入Boolean值），读写锁（ReentrantReadWriteLock）
公平锁：通过同步队列来实现多个线程按照申请锁的顺序获取锁。
读写锁：写操作开始到结束之间，不能再有其他读操作进来，并且写操作完成之后的更新数据需要对后续的读操作可见。ReentrantReadWriteLock在读操作时获取读锁，写操作时获取写锁。当写锁被获取到时，后续的读写锁都会被阻塞，写锁释放之后，所有操作继续执行。
synchronized实现原理——对象头和 Monitor
1、对象头
Java 对象在内存中的布局分为 3 部分：对象头、实例数据、对齐填充。当我们在 Java 代码中，使用 new 创建一个对象的时候，JVM 会在堆中创建一个 instanceOopDesc 对象，这个对象中包含了对象头以及实例数据。
其中 _mark 和 _metadata 一起组成了对象头。_mark 是 markOop 类型数据，一般称它为标记字段（Mark Word），其中主要存储了对象的 hashCode、分代年龄、锁标志位，是否偏向锁等。用一张图来表示 32 位 Java 虚拟机的 Mark Word 的存储结构如下：
图3 Java 虚拟机的 Mark Word 的存储结构
从图中可以看出，根据"锁标志位”以及"是否为偏向锁"，Java 中的锁可以分为以下几种状态
图4
在 Java 6 之前，并没有轻量级锁和偏向锁，只有重量级锁，也就是通常所说 synchronized 的对象锁，锁标志位为 10。从图3中的描述可以看出：当锁是重量级锁时，对象头中 Mark Word 会用 30 bit 来指向一个“互斥量”，而这个互斥量就是 Monitor。
Monitor
Monitor 可以把它理解为一个同步工具，也可以描述为一种同步机制。实际上，它是一个保存在对象头中的一个对象。markOop代码中， monitor() 方法创建一个 ObjectMonitor 对象，而 ObjectMonitor 就是 Java 虚拟机中的 Monitor 的具体实现。因此 Java 中每个对象都会有一个对应的 ObjectMonitor 对象，这也是 Java 中所有的 Object 都可以作为锁对象的原因。
其中比较重要的属性如下图：
图5
Java 虚拟机对 synchronized 的优化
从 Java 6 开始，虚拟机对 synchronized 关键字做了多方面的优化，主要目的就是，避免 ObjectMonitor 的访问，减少“重量级锁”的使用次数，并最终减少线程上下文切换的频率 。其中主要做了以下几个优化： 锁自旋、轻量级锁、偏向锁。
锁自旋
线程的阻塞和唤醒需要 CPU 从用户态转为核心态，频繁的阻塞和唤醒对 CPU 来说是一件负担很重的工作，势必会给系统的并发性能带来很大的压力，所以 Java 引入了自旋锁的操作。实际上自旋锁在 Java 1.4 就被引入了，默认关闭，但是可以使用参数 -XX:+UseSpinning 将其开启。但是从 Java 6 之后默认开启。
所谓自旋，就是让该线程等待一段时间，不会被立即挂起，看当前持有锁的线程是否会很快释放锁。而所谓的等待就是执行一段无意义的循环即可（自旋）。
自旋锁也存在一定的缺陷：自旋锁要占用 CPU，如果锁竞争的时间比较长，那么自旋通常不能获得锁，白白浪费了自旋占用的 CPU 时间。这通常发生在锁持有时间长，且竞争激烈的场景中，此时应主动禁用自旋锁。
轻量级锁
有时候 Java 虚拟机中会存在这种情形：对于一块同步代码，虽然有多个不同线程会去执行，但是这些线程是在不同的时间段交替请求这把锁对象，也就是不存在锁竞争的情况。在这种情况下，锁会保持在轻量级锁的状态，从而避免重量级锁的阻塞和唤醒操作。
当线程执行某同步代码时，Java 虚拟机会在当前线程的栈帧中开辟一块空间（Lock Record）作为该锁的记录，然后 Java 虚拟机会尝试使用 CAS（Compare And Swap）操作，将锁对象的 Mark Word 拷贝到这块空间中，并且将锁记录中的 owner 指向 Mark Word。
当线程再次执行此同步代码块时，判断当前对象的 Mark Word 是否指向当前线程的栈帧，如果是则表示当前线程已经持有当前对象的锁，则直接执行同步代码块；否则只能说明该锁对象已经被其他线程抢占了，这时轻量级锁需要膨胀为重量级锁。
轻量级锁所适应的场景是线程交替执行同步块的场合，如果存在同一时间访问同一锁的场合，就会导致轻量级锁膨胀为重量级锁。
偏向锁
轻量级锁是在没有锁竞争情况下的锁状态，但是在有些时候锁不仅存在多线程的竞争，而且总是由同一个线程获得。因此为了让线程获得锁的代价更低引入了偏向锁的概念。偏向锁的意思是如果一个线程获得了一个偏向锁，如果在接下来的一段时间中没有其他线程来竞争锁，那么持有偏向锁的线程再次进入或者退出同一个同步代码块，不需要再次进行抢占锁和释放锁的操作。偏向锁可以通过 -XX:+UseBiasedLocking 开启或者关闭。
偏向锁的具体实现就是在锁对象的对象头中有个 ThreadId 字段，默认情况下这个字段是空的，当第一次获取锁的时候，就将自身的 ThreadId 写入锁对象的 Mark Word 中的 ThreadId 字段内，将是否偏向锁的状态置为 01。这样下次获取锁的时候，直接检查 ThreadId 是否和自身线程 Id 一致，如果一致，则认为当前线程已经获取了锁，因此不需再次获取锁，略过了轻量级锁和重量级锁的加锁阶段。提高了效率。
其实偏向锁并不适合所有应用场景, 因为一旦出现锁竞争，偏向锁会被撤销，并膨胀成轻量级锁，而撤销操作（revoke）是比较重的行为，只有当存在较多不会真正竞争的 synchronized 块时，才能体现出明显改善；因此实践中，还是需要考虑具体业务场景，并测试后，再决定是否开启/关闭偏向锁。
对于锁的几种状态转换的源码分析，可以参考：源码分析Java虚拟机中锁膨胀的过程
总结
首先说了Java 中两个实现同步的方式 synchronized 和 ReentrantLock。其中 synchronized使用更简单，加锁和释放锁都是由虚拟机自动完成，而 ReentrantLock 需要开发者手动去完成。但是很显然 ReentrantLock 的使用场景更多，公平锁还有读写锁都可以在复杂场景中发挥重要作用。
另外，还介绍了Java 中锁的几种状态，其中偏向锁和轻量级锁都是通过自旋等技术避免真正的加锁，而重量级锁才是获取锁和释放锁，重量级锁通过对象内部的监视器（ObjectMonitor）实现，其本质是依赖于底层操作系统的 Mutex Lock（互斥锁） 实现，操作系统实现线程之间的切换需要从用户态到内核态的切换，成本非常高。实际上Java对锁的优化还有”锁消除“，但是”锁消除“是基于Java对象逃逸分析的。
网友评论