线程安全的实现方法之互斥同步

2020-04-22 本文已影响0人 iamayden

互斥同步（Mutual Exclusion & Synvhronization）

synchronized是一种块结构（Block Structured）的同步语法，经过Javac编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令。这两个字节码指令都需要一个reference类型的参数来指明要锁定和解锁的对象。
reference来源，Java源码中的synchroniaed明确指定了的对象参数，如没有明确指定则根据synchronized修饰的方法类型（实列方法或类方法）来决定是取代码所在的对象实例还是取类型对应的Class对象。

根据《Java虚拟机规范》的要求，在执行monitorenter指令时，首先去尝试获取对象的锁。如果对象没有被锁定，或者当前线程已经持有了那个对象的锁，就把锁的计算器的值增加一，
而在执行monitorexit指令时会将锁计算器的值减少一。一旦计算器的值为零，锁随即就被释放了。
如获取对象锁失败，则当前线程就应当被阻塞等待，指导请求的对象被持有它的线程释放为之。

根据以上行为描述得出直接结论：

被synchronized修饰的同步代码块对同一个线程来说是可重入的。这意味着同一线程反复进入同步代码块也不会出现把自己锁死的情况。
被synchronized修饰的同步代码块持有锁的线程执行完毕并释放锁之前，会无条件地阻塞后面其他线程的进入。这意味着无法像处理某些数据库中锁那样，强制已获取锁的线程释放锁，也无法强制正在等待锁的线程中断等待或者超时退出。

Java的线程是映射到操作系统的原生内核线程之上的，如果要阻塞或者唤醒一条线程，则需要操作系统来帮忙完成，这就不可避免的陷入用户态到核心态的转换中，进行这种转换需要耗费很多的处理时间。尤其是对于代码块特别简单的同步块（譬如被synchronized修饰的getter()或者setter方法），状态转换消耗的时间甚至比用户代码执行的时间还要长。
结论：synchronized持有锁是语言中一个重量级的操作。

从Java6开始，虚拟机对synchronized做了多方面的优化，减少“重量级锁”的使用次数，并最终减少线程上下文切换的频率。其中主要做了以下几个优化：锁自旋，轻量级锁，偏向锁。

锁自旋

自旋就是让线程等待一段时间，不会被立即挂起，看当前持有锁的线程是否会很快释放锁，等待即是执行一段无意义的循环。
Java1.4就引入了自旋，默认关闭，可以用参数-XX:UseSpinning开启，而从Java6之后就默认开启。自旋次数的默认值是十次，也可以使用参数-XX: PreBlockSpin来自行更改。
JDK6中对自旋锁的优化，引入了自适应的自旋。自旋时间不在固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。

自旋锁也存在一定的缺陷：自旋锁要占用CPU，如果锁竞争的时间比较长，那么自旋通常不能获得锁，只会白白浪费自旋占用的CPU时间。在锁持有时间长，且竞争激烈的场景中，应当主动禁止自旋锁。

轻量级锁
对于一块同步代码，虽然有多个不同线程会去执行，但是这些线程是在不同的时间段交替请求这把锁对象，也就是不存在锁竞争的情况。在这种情况下，锁会保持在轻量级锁的状态，从而避免重量级锁的阻塞和唤醒操作。

偏向锁

轻量级锁是在没有锁竞争情况下的锁状态，但是在有些时候锁不仅存在多线程的竞争，而且总是由同一个线程获得。因此为了让线程获得锁的代价更低引入了偏向锁的概念。
偏向锁的意思是如果一个线程获得了一个偏向锁，如果在接下来的一段时间中没有其他线程来竞争锁，那么持有偏向锁的线程再次进入或者退出同一个同步代码块，不需要再次进行抢占锁和释放锁的操作。偏向锁可以通过-XX:+UseBiasedLocking开启或者关闭。

其实偏向锁并不适合所有应用场景,因为一旦出现锁竞争，偏向锁会被撤销，并膨胀成轻量级锁，而撤销操作（revoke）是比较重的行为，只有当存在较多不会真正竞争的synchronized块时，才能体现出明显改善；因此实践中，还是需要考虑具体业务场景，并测试后，再决定是否开启/关闭偏向锁。

阅读笔记以加深印象。

参考：