Java加锁的优缺点_synchronized（偏向锁和轻量级锁）（TODO）

synchronized

JDK1.6对synchronized进行了各种优化，性能已经和ReentrantLock差不多了。

Java中的每一个对象都可以作为锁。具体表现为以下3种形式。

对于普通同步方法，锁是当前实例对象。

对于静态同步方法，锁是当前类的Class对象。

对于同步方法块，锁是Synchonized括号里配置的对象。

JVM基于进入和退出Monitor对象来实现方法同步和代码块同步，但两者的实现细节不一样。

代码块同步是使用monitorenter和monitorexit指令实现的，而方法同步是使用另外一种方式实现的，细节在JVM规范里并没有详细说明。

但是，方法的同步同样可以使用这两个指令来实现。

Java对象头

如果对象是数组类型，则虚拟机用3个字宽(Word)存储对象头，如果对象是非数组类型，则用2字宽存储对象头。在32位虚拟机中，1字宽等于4字节，即32bit。

Java对象头的长度

Java对象头里的Mark Word里默认存储对象的HashCode、分代年龄和锁标记位。

Mark Word的存储结构

Mark Word的状态变化

在64位虚拟机下，Mark Word是64bit大小

64bit的Mark Word的存储结构

锁升级与对比

JDK1.6为了减少获得锁和释放锁带来的性能消耗，引入了“偏向锁”和“轻量级锁”。

锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态会随着竞争情况逐渐升级，锁可以升级但不能降级。

偏向锁

当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出

同步块时不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否

存储着指向当前线程的偏向锁。如果测试成功，表示线程已经获得了锁。如果测试失败，则需

要再测试一下Mark Word中偏向锁的标识是否设置成1(表示当前是偏向锁)：如果没有设置，则

使用CAS竞争锁；如果设置了，则尝试使用CAS将对象头的偏向锁指向当前线程。

偏向锁撤销

偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，

持有偏向锁的线程才会释放锁。偏向锁的撤销，需要等待全局安全点(在这个时间点上没有正

在执行的字节码)。它会首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着，

如果线程不处于活动状态，则将对象头设置成无锁状态；如果线程仍然活着，拥有偏向锁的栈

会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word要么重新偏向于其他

线程，要么恢复到无锁或者标记对象不适合作为偏向锁，最后唤醒暂停的线程。

偏向锁初始化

书上说了一大堆，简单来说就是分两种场景，一种是有竞争，一种是无竞争

无竞争：

无竞争的场景可以假设是一个单线程请求synchronized锁，当第一次请求锁时，锁的对象头中的偏向锁线程ID是空，状态是0。

锁请求成功后，JVM会将这个线程ID写入对象头，偏向锁线程ID不为空，状态是1，然后该线程执行完同步代码后释放锁，接着又继续请求获取锁。

然后判断锁的请求头中的偏向锁状态是否为1，为1则再判断偏向锁的线程ID是否是该线程ID，如果是则直接进入临界区执行同步代码，无需加锁和解锁的操作。

有竞争：

有竞争的场景的第一个请求锁的线程同无竞争场景一样，假设线程A请求锁成功，设置偏向锁状态为1，记录偏向锁线程ID，但由于存在锁竞争，第二个线程B请求锁时，发现偏向锁状态是1，

但是锁的对象头中偏向锁记录的线程ID并不是自己，这时就需要撤销偏向锁，撤销之前必须要检查线程A是不是还活着，因为此时线程A可能正在临界区内执行同步代码，也可能线程A活的很滋润，

在另外一把锁的临界区内执行同步代码，也可能代码执行完毕已经释放锁然后线程池中等待复用，也可能代码执行完毕且线程已经死亡。

所以线程B请求锁时发现偏向锁的线程ID不是自己，JVM会暂停对象头中记录的偏向锁ID。

如果线程A暂停失败说明线程死亡，线程B直接将对象头设置成无锁状态

如果线程A暂停成功说明线程A活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word要么重新偏向于其他线程，

要么锁状态恢复到无锁(锁不升级)或者标记锁对象不适合作为偏向锁(升级为轻量级锁)，最后唤醒暂停的线程。

这里有个疑惑，TODO 一下，什么情况锁不升级，什么情况锁才升级？

我的想法是，由于锁只能升级不能降级，那么盲目升级锁势必会增大锁开销而降低性能。所以线程B发现锁的偏向线程ID不是自己还需要一些判断再决定是否需要升级锁。

即如果线程A活着，但是线程A处于挂起状态或者当前线程A在活动中且栈信息中的锁信息不是线程B请求的锁，则锁状态置位无效，不升级锁

如果线程A正在锁的临界区执行同步代码，则需要锁升级，升级为轻量级锁。

所以总结下来，偏向锁请求过程如下：(这里只说偏向锁的请求，即所标志为=01的情况)

判断锁对象的对象头中的Mark Word是否为无锁状态(锁状态=0)

a.是，CAS设置锁状态为1，偏向锁ID为当前线程ID

b.否：判断锁状态是否为1

a.是，继续判断偏向锁ID是否为当前请求线程ID

a.是，无需加锁和解锁，直接进入临界区执行同步代码

b.否，判断偏向锁ID对应的线程是否存活

a.是，暂停线程，判断线程栈中的锁对象信息是否为当前请求的锁对象信息

a.是，存在竞争，当前线程请求的锁已被其他线程占用且正在临界区执行同步代码，锁升级为轻量级锁，在暂停的线程栈中创建用于存储锁记录的空间，并将对象头中的Mark Word复制到　　　　　　　　　　　　　　　　　锁记录中，使用CAS将对象头中的Mark Word替换为指向锁记录的指针，恢复之前暂停的线程

b.否，没有线程在当前锁对象的临界区内，修改锁的偏向线程ID为当前线程或重置为无锁状态，CAS设置锁状态为1，偏向锁ID为当前线程ID。恢复之前暂停的线程

b.否，锁已升级，不使用偏向锁

轻量级锁

1)加锁

线程在执行同步块之前，JVM会先在当前线程的栈桢中创建用于存储锁记录的空间，并

将对象头中的Mark Word复制到锁记录中，官方称为Displaced Mark Word。然后线程尝试使用

CAS将对象头中的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失

败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。

2)解锁

轻量级解锁时，会使用原子的CAS操作将Displaced Mark Word替换回到对象头，如果成

功，则表示没有竞争发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。

锁膨胀流程

因为自旋会消耗CPU，为了避免无用的自旋(比如获得锁的线程被阻塞住了)，一旦锁升级

成重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其他线程试图获取锁时，

都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就会进行新一轮

的夺锁之争。

总结轻量级锁请求过程：

判断锁对象的对象头中的Mark Word是否为无锁状态(锁状态=0)

a.是，在栈帧中创建锁记录空间，复制锁对象头的Mark Word到锁记录中，CAS将锁对象的对象头中的Mark Word替换为指向锁记录的指针。

a.替换成功，则加锁成功，执行同步代码，执行完毕后CAS操作将Displaced Mark Word替换回到对象头进行解锁

a.解锁成功，此时锁状态为无锁状态

b.解锁失败，说明当前线程在执行同步代码的时候有其他线程来请求锁资源，且请求失败将锁升级为重量级锁

b.替换失败

自旋，走下面的自旋流程

b.否，检查对象的Mark Word是否指向当前线程的栈帧的锁记录

a.是，说明当前线程已持有锁，直接进入同步代码

b.否，自旋，空循环自旋一段时间

a.自旋成功，获取锁成功

b.自旋失败，升级锁为重量级锁，修改锁对象的Mark Word指针指向重量级锁

锁的优缺点对比

参考：

《Java编发变成艺术》