多线程学习笔记：8.线程安全和锁优化

线程安全的实现方法

1.互斥同步

互斥同步（Mutual Exclusion & Synchronization）是常见的一种并发正确性保障手段。同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一个（或者是一些，使用信号量的时候）线程使用。而互斥是实现同步的一种手段，临界区（Critical Section）、互斥量（MuTex）和信号量（Semaphore）都是主要的互斥实现方式。因此，在这四个字里面，互斥是因，同步是果；互斥是方法，同步是目的。

在Java中，最基本的互斥同步手段是synchronized关键字，synchronized关键字经过编译后，会在同步代码块的前后分别形成monitorenter和monitorexit这两个字节码指令，这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象。如果程序中synchronized指明了对象参数，那就是这个对象的reference；如果没有指明，那就根据synchronized修饰的是实例方法还是类方法，去取对应的对象实例或Class对象来作为锁对象。

虚拟机规范要求，在执行monitorenter指令时，首先尝试获取对象的锁。如果对象没有被锁定或者当前线程已经拥有了那么对象的锁，把锁的计数器加1，执行monitorexit时，将锁计数减1，当锁计数器为0时，锁被释放。如果获取对象锁失败，当前线程将阻塞等待。

虚拟机对monitorenter和monitorexit行为描述中，注意两点：synchronized同步块对同一条线程来说是可重入的，不会出现自己把自己锁死的问题；同步块在已进入线程执行完之前，会阻塞后面其他线程的进入。

还可以使用java.util.concurrent（以下称JUC）包中的重入锁（ReentrantLock）来实现同步。相比synchronized，ReentrantLock增加了一些高级功能，主要以下3项：等待可中断、可实现公平锁，以及锁可以绑定多个条件。

等待可中断：当持有的锁的线程长期不释放锁时，正在等待的线程可以选择放弃等待，改为处理其他事情，对处理执行时间长的同步块很有帮助。

公平锁：多个线程等待同一锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平锁不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized中的锁是非公平的，ReentrantLock默认也是非公平，但可以通过构造函数要求使用公平锁。

绑定多个条件：一个ReentrantLock对象可以同时绑定多个Condition对象，而synchronized中，锁对象的wait()和notify()或notifyAll()可以实现一个隐含的条件，如果要和多于一个的条件关联时，就不得不额外添加一个锁，而ReentrantLock则无须这样，只要多次调用newCondition()即可。

之前学过，Java的线程是映射到操作系统的原生线程之上的，如果要阻塞和唤醒一个线程，都需要操作系统来帮忙完成，这就需要从用户态转换到核心态中，这种状态切换非常耗时，甚至会比执行同步代码块中的时间还长，隐藏同步代码块是java中一个重量级的操作，对应的锁称为重量级锁。

2.非阻塞同步

互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步（Blocking Synchronized）。处理问题方式上，互斥同步属于一种悲观的并发策略，总是认为只要不去做正确的同步措施（例如加锁），那肯定会出现问题，无论共享数据是否真的出现竞争，它都要进行加锁（这里讨论的是概念模型，实际上虚拟机会优化很大一部分不必要的加锁）、用户态核心态转换、维护锁计数器和检查是否有阻塞的线程需要等待唤醒等操作。

随着硬件指令集的发展，有了另外一种选择：基于冲突检测的乐观并发策略，就是先进性操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争，产生了冲突，那就再采取其他的补偿措施（最常见的补偿措施就是不断地重试，直到成功为止），这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步称为非阻塞同步（Non-Blocking Synchronization）。

我们需要操作和冲突检测这两个步骤具备原子性，只能靠硬件来完成，硬件保证一个从语义上看起来需要多次操作的行为只通过一条处理器指令就能完成，这类执行常用的有：

测试并设置（Test and Set）。

获取并增加（Fetch and Increment）。

交换（Swap）。

比较并交换（Compare and Swap，以下称CAS）。

加载链接/条件存储（Load Linked/Store Conditional，以下称LL/SC）。

其中CAS指令比较常用，是java中Atomic原子类的实现原理，CAS指令需要3个操作数，分别是内存位置V，旧的预期值A和新值B。当且仅当V的值是预期值A时，才用新值B更新V的值，否则不更新。这个操作在硬件上是个原子操作。

3.无同步方案

要保证线程安全，并不是一定就要进行同步，两者并没有因果关系。同步只是保证共享数据争用时正确性的手段，如果一个方法本来就不涉及共享数据，自然就无须任何同步措施去保证正确定。因此会有一些代码天生就是线程安全的。

java可以通过java.lang.ThreadLocal类来实现线程本地存储的功能。将变量变成当前线程独享的数据，每一个线程的Thread对象中都有一个ThreadLcoalMap对象，该对象存储了一组易ThreadLocal.threadLocalHashCode为键，以本地线程变量为值得K-V键值对，ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口，每一个ThreadLocal对象都包含了一个独一无二的threadLocalHashCode值，使用这个值就可以在线程K-V键值对中找回对应的本地线程变量。

锁优化

自旋锁与自适应自旋

在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得如果物理机器上有一个以上的处理器，我们可以让后面申请锁的那个线程“稍等一下”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，只需让线程执行一个忙循环（自旋），就项技术就是所谓的自旋锁。

自旋等待不能代替阻塞，且先不说对处理器量的要求，自旋等待本身虽然避免了线程切换的开销，但它要占用处理器的时间，因此，如果锁被占用的时间短，自旋等待效果好，反之，自旋的线程只会白白消耗处理器资源，而不做任何有用工作，带来性能上的浪费。因此，自旋等待的时间必须要有一定的限度，如果自旋超过了限定的次数仍然没有获得锁，就应当使用传统的方式挂起线程。自旋次数的默认值是10次，用户可以使用参数 -XX:PerBlockSpin 来修改。

JDK1.6引入了自适应的自旋锁。自旋的时间是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就认为这次自旋也很可能成功，进而它将允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功获得，在以后获得这个锁时将可能省略自旋过程，以避免浪费处理器资源。有了自适应自旋，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越准确，虚拟机就变得越来越“聪明”了。

锁消除

是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除主要判定依据来源于逃逸分析的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去，从而被其他线程访问到，那就可以把它们当做栈上数据对待，认为它们是线程私有的，同步加锁自然无须进行。

许多同步措施并不是程序员自己加入的，同步的代码在Java程序中的普遍程度也许超过我们的想象。

public String concatString(String s1, String s2, String s3){
        return s1 + s2 + s3;
    }

由于String是一个不可变类，对字符串的连接操作总是通过生成新的String对象来进行，因此Javac编译器会对String连接做自动优化。在JDK1.5前，会转换为StringBuffer对象的append()操作，在JDK1.5及以后版本，会转换为StringBuilder对象的连续append()操作。上段代码可能会变成下面的样子。​

public String concatString(String s1, String s2, String s3){
        StringBuilder sb = new StringBuilder();
        sb.append(s1);
        sb.append(s2);
        sb.append(s3);
        return sb.toString();
    }

每个StringBuilder.append()中都有一个同步块，锁是sb对象。虚拟机观察变量sb，很快就会发现它的动态作用域被限制在concatString()的内部。也就是sb的所有引用永远不会“逃逸”到concatString()外，其他线程无法访问到它，所以虽然这里有锁，但是可以被安全地消除掉，在即时编译后，这段代码会忽略所有的同步而直接执行。

锁粗化

大部分情况下，我们在编写代码时，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域才进行同步，如果存在锁竞争，那等待锁的线程也可能尽快拿到锁。

但是如果一系列的连续操作都是对同一对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。

上段代码连续的append()就属于这种情况。如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部，以上段代码为例，就是扩展到第一个append()之前直至最后一个append()之后，这样只需要加锁一次就可以了。

java偏向锁、轻量级锁、重量级锁

这里所说的锁针对的是互斥同步中使用synchronized加的锁，锁的状态总共有四种：无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁（但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级）。

首先复习下java对象在内存中的对象头Mark Word

在运行期间，对象头内Mark Word内存储的数据会随着锁标志位的变化而变化，具体分为以下4种（基于32位虚拟机）：

　偏向锁

在实际应用运行过程中发现，“锁总是同一个线程持有，很少发生竞争”，也就是说锁总是被第一个占用他的线程拥有，这个线程就是锁的偏向线程。

 那么只需要在锁第一次被拥有的时候，记录下偏向线程ID。这样偏向线程就一直持有着锁，直到竞争发生才释放锁。以后每次同步，检查锁的偏向线程ID与当前线程ID是否一致，如果一致直接进入同步，退出同步。无需每次加锁解锁。

1、偏向锁获取过程：

　　（1）访问Mark Word中偏向锁的标识是否设置成1，锁标志位是否为01——确认为可偏向状态。

　　（2）如果为可偏向状态，则测试线程ID是否指向当前线程，如果是，进入步骤（5），否则进入步骤（3）。

　　（3）如果线程ID并未指向当前线程，则通过CAS操作竞争锁。如果竞争成功，则将Mark Word中线程ID设置为当前线程ID，然后执行（5）；如果竞争失败，执行（4）。

　　（4）如果CAS获取偏向锁失败，则表示有竞争。当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码。

　　（5）执行同步代码。

2、偏向锁的释放：

　　偏向锁的撤销在上述第四步骤中有提到。偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程不会主动去释放偏向锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态，撤销偏向锁后恢复到未锁定（标志位为“01”）或轻量级锁（标志位为“00”）的状态。

3.偏向锁的批量再偏向（Bulk Rebias）机制
偏向锁这个机制很特殊， 别的锁在执行完同步代码块后， 都会有释放锁的操作， 而偏向锁并没有直观意义上的“释放锁”操作。那么作为开发人员， 很自然会产生的一个问题就是， 如果一个对象先偏向于某个线程， 执行完同步代码后， 另一个线程就不能直接重新获得偏向锁吗？ 答案是可以， JVM 提供了批量再偏向机制（Bulk Rebias）机制

该机制的主要工作原理如下：

引入一个概念 epoch, 其本质是一个时间戳 ， 代表了偏向锁的有效性
从前文描述的对象头结构中可以看到， epoch 存储在可偏向对象的 MarkWord 中。
除了对象中的 epoch, 对象所属的类 class 信息中， 也会保存一个 epoch 值
每当遇到一个全局安全点时， 如果要对 class C 进行批量再偏向， 则首先对 class C 中保存的 epoch 进行增加操作， 得到一个新的 epoch_new
然后扫描所有持有 class C 实例的线程栈， 根据线程栈的信息判断出该线程是否锁定了该对象， 仅将 epoch_new 的值赋给被锁定的对象中。
退出安全点后， 当有线程需要尝试获取偏向锁时， 直接检查 class C 中存储的 epoch 值是否与目标对象中存储的 epoch 值相等， 如果不相等， 则说明该对象的偏向锁已经失效了， 可以直接通过 CAS 操作尝试再次将该对象再次偏向于请求获得锁的线程。

加锁流程

轻量级锁

之前提过，重量级锁涉及到底层用户态和内核态切换，性能消耗大。当存在线程竞争，但同步代码块执行很快时，为了避免状态切换带来的资源消耗，让等待的线程自旋，自旋超过一定次数后任未获得锁，则切换状态，升级为重量级锁。所以轻量级锁本质就是自旋锁。

1.加锁

 如果对象处于无锁状态（偏向锁标志位为”0”，锁标志位为”01”），会在线程的栈中开辟个锁记录空间（Lock Record），将Mark Word拷贝一份到Lock Record中，称为Displaced Mark Word，在Lock Record中保存对象头的指针（owner）。 

接下来CAS更新MarkWord，将MarkWord指向当前线程，owner指向MarkWord，如果失败了，则意味着出现了另一个线程竞争锁，先通过自旋获取锁，自旋还失败的话，转换为重量级锁。

2.解锁

 用CAS操作锁置为无锁状态（偏向锁位为”0”，锁标识位为”01”），若CAS操作失败则是出现了竞争，锁已膨胀为重量级锁了，此时需要释放锁（持有重量级锁线程的指针位为”0”，锁标识位为”10”）并唤醒重量锁的线程。

轻量锁与偏向锁不同的是： 
1. 轻量级锁每次退出同步块都需要释放锁，而偏向锁是在竞争发生时才释放锁 
2. 每次进入退出同步块都需要CAS更新对象头 
3. 争夺轻量级锁失败时，自旋尝试抢占锁

重量级锁

重量锁会导致未获得锁的线程阻塞。

各种锁的比较

加锁流程： 

 

目前水平有限，只能了解到这种程度。

参考资料：《深入理解JVM》

                   https://blog.csdn.net/noble510520/article/details/78834224