[多线程] Synchronized 关键字

时间 2019-11-18

原文原文链接

Synchronized是Java中很是重要的一个关键字。java

1. 起源数据库

事务的产生老是会有特定的缘由，下面这段代码就做为引出Synchronized的引子编程

public class SynchronizedDemo implements Runnable {
    private static int count = 0;

    public static void main(String[] args) {
        for (int i = 0; i < 10; i++) {
            Thread thread = new Thread(new SynchronizedDemo());
            thread.start();
        }
        try {
            Thread.sleep(500);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("result: " + count);
    }

    @Override
    public void run() {
        for (int i = 0; i < 1000000; i++)
            count++;
    }
}

　10个线程同时操做count，每一个线程作一百万次count自增操做，最后出来的结果不必定是一千万，并且每次运行的结果还不同。安全

2. Synchronized实现原理多线程

实现原理：JVM经过进入、退出对象监视器（Monitor）来实现对方法、同步块的同步。并发

看下面一段代码ide

public class SynchronizedDemo {
    public static void main(String[] args) {
        synchronized (SynchronizedDemo.class) {
        }
        method();
    }

    private static void method() {
    }
}

编译以后，用javap -v SynchronizedDemo.class 查看字节码文件：post

如图，上面用黄色高亮的部分就是须要注意的部分了，这也是添Synchronized关键字以后独有的。执行同步代码块后首先要先执行 monitorenter指令，退出的时候 monitorexit指令。经过分析以后能够看出，使用Synchronized进行同步，其关键就是必需要对对象的监视器monitor进行获取，当线程获取monitor后才能继续往下执行，不然就只能等待。而这个获取的过程是互斥的，即同一时刻只有一个线程可以获取到monitor。上面的demo中在执行完同步代码块以后紧接着再会去执行一个静态同步方法，而这个方法锁的对象依然就这个类对象，那么这个正在执行的线程还须要获取该锁吗？答案是没必要的，从上图中就能够看出来，执行静态同步方法的时候就只有一条monitorexit指令，并无monitorenter获取锁的指令。这就是 锁的重入性，即在同一锁程中，线程不须要再次获取同一把锁。Synchronized先天具备重入性。 每一个对象拥有一个计数器，当线程获取该对象锁后，计数器就会加一，释放锁后就会将计数器减一。

任意一个对象都拥有本身的监视器，当这个对象由同步块或者这个对象的同步方法调用时，执行方法的线程必须先获取该对象的监视器才能进入同步块和同步方法，若是没有获取到监视器的线程将会被阻塞在同步块和同步方法的入口处，进入到BLOCKED状态。

下图表现了对象，对象监视器，同步队列以及执行线程状态之间的关系：

该图能够看出，任意线程对Object的访问，首先要得到Object的监视器，若是获取失败，该线程就进入同步状态，线程状态变为BLOCKED，当Object的监视器占有者释放后，在同步队列中得线程就会有机会从新获取该监视器。性能

3. 锁获取和锁释放的内存语义

public class MonitorDemo {
    private int a = 0;

    public synchronized void writer() {     // 1
        a++;                                // 2
    }                                       // 3

    public synchronized void reader() {    // 4
        int i = a;                         // 5
    }                                      // 6
}

从上图能够看出，线程A会首先先从主内存中读取共享变量a=0的值而后将该变量拷贝到本身的本地内存，进行加一操做后，再将该值刷新到主内存，整个过程即为线程A 加锁-->执行临界区代码-->释放锁相对应的内存语义。测试

线程B获取锁的时候一样会从主内存中共享变量a的值，这个时候就是最新的值1,而后将该值拷贝到线程B的工做内存中去，释放锁的时候一样会重写到主内存中。

从总体上来看，线程A的执行结果（a=1）对线程B是可见的，实现原理为：释放锁的时候会将值刷新到主内存中，其余线程获取锁时会强制从主内存中获取最新的值。

从横向来看，这就像线程A经过主内存中的共享变量和线程B进行通讯，A 告诉 B 咱们俩的共享数据如今为1啦，这种线程间的通讯机制正好吻合java的内存模型正好是共享内存的并发模型结构。

4. Synchronized的优化

　　经过上面的讨论如今咱们对Synchronized应该有所印象了，它最大的特征就是在同一时刻只有一个线程可以得到对象的监视器（monitor），从而进入到同步代码块或者同步方法之中，即表现为 互斥性（排它性）。这种方式确定效率低下，每次只能经过一个线程，既然每次只能经过一个，这种形式不能改变的话，那么咱们能不能让每次经过的速度变快一点了。打个比方，去收银台付款，以前的方式是，你们都去排队，而后去纸币付款收银员找零，有的时候付款的时候在包里拿出钱包再去拿出钱，这个过程是比较耗时的，而后，支付宝解放了你们去钱包找钱的过程，如今只须要扫描下就能够完成付款了，也省去了收银员跟你找零的时间的了。一样是须要排队，但整个付款的时间大大缩短，是否是总体的效率变高速率变快了？这种优化方式一样能够引伸到锁优化上，缩短获取锁的时间。

4.1 CAS操做

3.1.1 什么是CAS?

使用锁时，线程获取锁是一种悲观锁策略，即假设每一次执行临界区代码都会产生冲突，因此当前线程获取到锁的时候同时也会阻塞其余线程获取该锁。而CAS操做（又称为无锁操做）是一种乐观锁策略，它假设全部线程访问共享资源的时候不会出现冲突，既然不会出现冲突天然而然就不会阻塞其余线程的操做。所以，线程就不会出现阻塞停顿的状态。那么，若是出现冲突了怎么办？无锁操做是使用**CAS(compare and swap)**又叫作比较交换来鉴别线程是否出现冲突，出现冲突就重试当前操做直到没有冲突为止。

3.1.2 CAS的操做过程

CAS比较交换的过程能够通俗的理解为CAS(V,O,N)，包含三个值分别为：V 内存地址存放的实际值；O 预期的值（旧值）；N 更新的新值。当V和O相同时，也就是说旧值和内存中实际的值相同代表该值没有被其余线程更改过，即该旧值O就是目前来讲最新的值了，天然而然能够将新值N赋值给V。反之，V和O不相同，代表该值已经被其余线程改过了则该旧值O不是最新版本的值了，因此不能将新值N赋给V，返回V便可。当多个线程使用CAS操做一个变量是，只有一个线程会成功，并成功更新，其他会失败。失败的线程会从新尝试，固然也能够选择挂起线程

CAS的实现须要硬件指令集的支撑，在JDK1.5后虚拟机才可使用处理器提供的CMPXCHG指令实现。

元老级的Synchronized(未优化前)最主要的问题是：在存在线程竞争的状况下会出现线程阻塞和唤醒锁带来的性能问题，由于这是一种互斥同步（阻塞同步）。而CAS并非武断的间线程挂起，当CAS操做失败后会进行必定的尝试，而非进行耗时的挂起唤醒的操做，所以也叫作非阻塞同步。这是二者主要的区别。

3.1.3 CAS的问题

1. ABA问题 由于CAS会检查旧值有没有变化，这里存在这样一个有意思的问题。好比一个旧值A变为了成B，而后再变成A，恰好在作CAS时检查发现旧值并无变化依然为A，可是实际上的确发生了变化。解决方案能够沿袭数据库中经常使用的乐观锁方式，添加一个版本号能够解决。原来的变化路径A->B->A就变成了1A->2B->3C。java这么优秀的语言，固然在java 1.5后的atomic包中提供了AtomicStampedReference来解决ABA问题，解决思路就是这样的。

2. 自旋时间过长

使用CAS时非阻塞同步，也就是说不会将线程挂起，会自旋（无非就是一个死循环）进行下一次尝试，若是这里自旋时间过长对性能是很大的消耗。若是JVM能支持处理器提供的pause指令，那么在效率上会有必定的提高。

3. 只能保证一个共享变量的原子操做

当对一个共享变量执行操做时CAS能保证其原子性，若是对多个共享变量进行操做,CAS就不能保证其原子性。有一个解决方案是利用对象整合多个共享变量，即一个类中的成员变量就是这几个共享变量。而后将这个对象作CAS操做就能够保证其原子性。atomic中提供了AtomicReference来保证引用对象之间的原子性。

3.2 Java对象头

在同步的时候是获取对象的monitor,即获取到对象的锁。那么对象的锁怎么理解？无非就是相似对对象的一个标志，那么这个标志就是存放在Java对象的对象头。Java对象头里的Mark Word里默认的存放的对象的Hashcode,分代年龄和锁标记位。32为JVM Mark Word默认存储结构为（注:java对象头以及下面的锁状态变化摘自《java并发编程的艺术》一书，该书我认为写的足够好，就没在本身组织语言班门弄斧了）：

如图在Mark Word会默认存放hasdcode，年龄值以及锁标志位等信息。

Java SE 1.6中，锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态会随着竞争状况逐渐升级。锁能够升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提升得到锁和释放锁的效率。对象的MarkWord变化为下图：

3.2 偏向锁

HotSpot的做者通过研究发现，大多数状况下，锁不只不存在多线程竞争，并且老是由同一线程屡次得到，为了让线程得到锁的代价更低而引入了偏向锁。

偏向锁的获取

当一个线程访问同步块并获取锁时，会在 对象头和 栈帧中的锁记录里存储锁偏向的线程ID，之后该线程在进入和退出同步块时不须要进行CAS操做来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。若是测试成功，表示线程已经得到了锁。若是测试失败，则须要再测试一下Mark Word中偏向锁的标识是否设置成1（表示当前是偏向锁）：若是没有设置，则使用CAS竞争锁；若是设置了，则尝试使用CAS将对象头的偏向锁指向当前线程

偏向锁的撤销

偏向锁使用了一种等到竞争出现才释放锁的机制，因此当其余线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。

如图，偏向锁的撤销，须要等待 全局安全点（在这个时间点上没有正在执行的字节码）。它会首先暂停拥有偏向锁的线程，而后检查持有偏向锁的线程是否活着，若是线程不处于活动状态，则将对象头设置成无锁状态；若是线程仍然活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word 要么从新偏向于其余线程，要么恢复到无锁或者标记对象不适合做为偏向锁，最后唤醒暂停的线程。

下图线程1展现了偏向锁获取的过程，线程2展现了偏向锁撤销的过程。

如何关闭偏向锁

偏向锁在Java 6和Java 7里是默认启用的，可是它在应用程序启动几秒钟以后才激活，若有必要可使用JVM参数来关闭延迟： -XX:BiasedLockingStartupDelay=0。若是你肯定应用程序里全部的锁一般状况下处于竞争状态，能够经过JVM参数关闭偏向锁： -XX:-UseBiasedLocking=false，那么程序默认会进入轻量级锁状态。

3.3 轻量级锁

加锁

线程在执行同步块以前，JVM会先在当前线程的栈桢中 建立用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中，官方称为 Displaced Mark Word。而后线程尝试使用CAS 将对象头中的Mark Word替换为指向锁记录的指针。若是成功，当前线程得到锁，若是失败，表示其余线程竞争锁，当前线程便尝试使用自旋来获取锁。

解锁

轻量级解锁时，会使用原子的CAS操做将Displaced Mark Word替换回到对象头，若是成功，则表示没有竞争发生。若是失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。下图是两个线程同时争夺锁，致使锁膨胀的流程图。

由于自旋会消耗CPU，为了不无用的自旋（好比得到锁的线程被阻塞住了），一旦锁升级成重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其余线程试图获取锁时，都会被阻塞住，当持有锁的线程释放锁以后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争。

3.5 各类锁的比较

做者：你听___ 连接：https://juejin.im/post/5ae6dc04f265da0ba351d3ff