Java多线程synchronized关键字引出的多种锁

前言

Java 中的 synchronized关键字能够在多线程环境下用来做为线程安全的同步锁。本文不讨论 synchronized 的具体使用，而是研究下synchronized底层的锁机制，以及这些锁分别的优缺点。

1、synchronized机制

synchronized关键字是JAVA中经常使用的同步功能，提供了简单易用的锁功能。 synchronized有三种用法，分别为:

• 用在普通方法上，可以锁住当前对象。
• 用在静态方法上，可以锁住类
• 用在代码块上，锁住的是synchronized()里的对象

在JDK6以前，synchronized使用的是重量级锁制，在以后synchronized加入了锁膨胀机制，显著提高了synchronized关键字的效率。

基于synchronized关键字，咱们来了解下几种类别的锁，而且讲解synchronized的锁膨胀机制。

synchronized锁是非公平锁。而且一个被synchronized锁住的对象或类，就是一把锁。

另一提，全部锁都是存储在Java对象头里的，Java对象头里的Mark Word里默认存储对象的HashCode，分代年龄和锁标记位。也就是说Mark Word记录了锁的状态

2、锁膨胀机制与几类锁

锁膨胀是不可逆的

2.1 偏向锁

synchronized在JDK1.6之后默认开启偏向锁，synchronized最初都是偏向锁

表现：一个线程获取锁成功后，会在对象头里记录线程ID，之后该线程获取和释放锁都没有任何花费。（由于该锁已经被绑定在该线程上了，且在膨胀前不会改变），若是其余线程尝试获取这个锁，偏向锁将会膨胀为轻量锁。

优势：在只有一个线程使用锁的时候获取和退出锁没有任何花费

缺点：锁竞争激烈会很快升级为轻量锁，那么维持偏向锁的过程就是在浪费计算机资源。（不过由于偏向锁自己就很轻量，所以浪费的资源并很少）

小结：只有一个线程使用锁的状况下，synchronized使用的锁为偏向锁。 若是锁竞争激烈，能够经过配置JDK禁用偏向锁。

2.2 轻量锁

一把锁不止一个线程使用，则偏向锁膨胀为轻量锁

表现：线程获取轻量锁时，会直接用CAS修改对象头里锁的记录，若是修改失败，表明此时锁存在多个线程的竞争，轻量锁将会膨胀为重量锁。

优势：在线程之间使用锁不存在竞争时，一次CAS操做就能获取和退出锁

缺点：与偏向锁相似

小结：只要一把锁不止一个线程获取过，偏向锁就会膨胀为轻量锁。

2.3 重量锁

一把锁存在多线程竞争，则轻量锁开始自旋，自旋必定次数后仍没获取锁，则膨胀为重量锁(存在竞争时，轻量锁虽然会先自旋，可是最终每每都会膨胀为重量锁)

表现：线程获取重量锁时，若是获取失败（即锁已被其余线程获取），则使用自适应自旋锁,自旋必定次数后仍没获取锁，则进入阻塞队列等待。

优势：未获取到的锁进入阻塞队列，节约CPU资源。（好吧感受实际上是没有啥优势）

缺点：重量锁是经过对象内部的监视器（monitor）实现，其中monitor的本质是依赖于底层操做系统的Mutex Lock实现，操做系统实现线程之间的切换须要从用户态到内核态的切换，切换成本很是高。

小结：只要一把锁存在多线程竞争，轻量锁就会膨胀为重量锁。

自旋锁

synchronized的轻量锁，重量锁，使用了自适应自旋锁进行性能优化

首先介绍自旋锁

表现：线程获取锁失败后，不会进入阻塞等待，而是再次尝试去获取锁，如此反复，直到获取到锁，或者自旋结束那么会阻塞等待。

解决问题：在某些场景下，线程持有锁的时间很是短。在线程获取锁失败后，若是线程进入阻塞将会带来线程上下文的切换，上下文切换的时间可能反而高于线程反复尝试获取锁的时间。 此时线程原地等待去重复获取锁。反而在性能上更有优点。

缺点：

1. 单核CPU没有线程并行，反复尝试会致使进程没法继续运行。
2. 重复尝试致使了CPU的占用，若是CPU资源紧张的话反而会性能降低
3. 若是锁的竞争时间过长，不只没有性能提高，还浪费了大量CPU资源。

优化：使用自适应自旋锁。自适应自旋锁会根据以前的锁获取记录，优化调整自旋时间，避免形成没必要要的自旋。

3、具体synchronized流程

点关注，不迷路，这是一个程序都想要关注的公众号