JVM之线程安全与锁优化

谁践踏了优雅 2021-08-29 14:43 420阅读 0赞

### 线程安全与锁优化 ###

*  1. 线程安全
 *   *  1.1 Java 语言中的线程安全
     *   *  1.1.1 不可变
         *  1.1.2 绝对线程安全
         *  1.1.3 相对线程安全
         *  1.1.4 线程兼容
         *  1.1.5 线程对立
     *  1.2 线程安全的实现方法
     *   *  1.2.1 互斥同步
         *  1.2.2 非阻塞同步
         *  1.2.3 无同步方案
 *  2. 锁优化
 *   *  2.1 自旋锁与自适应自旋
     *  2.2 锁消除
     *  2.3 锁粗化
     *  2.4 轻量级锁
     *  2.5 偏向锁

# 1. 线程安全 #

当多个线程访问同一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那这个对象是线程安全的。

## 1.1 Java 语言中的线程安全 ##

按照线程安全的“安全程度”由强到弱排序，可以将`Java`语言中各种操作共享的数据分为以下五类：不可变、绝对线程安全、相对线程安全、线程兼容和线程对立。

### 1.1.1 不可变 ###

在`Java`语言里面，不可变的对象一定是线程安全的。

如果共享数据是一个基本数据类型对象，那么只要在定义时使用`final`关键字修饰它就可以保证它是不可变的。

如果共享数据是一个对象，那么需要保证对象的行为对其不会产生任何影响才行。如调用`String`的`subString()`等不会影响原来的值。

### 1.1.2 绝对线程安全 ###

不管运行时环境如何，调用者都不需要任何额外的同步措施。

在`Java`中，标注为线程安全的类，并不意味着其绝对的线程安全。即使这个类所有方法都被修饰为synchronized，也不意味着调用它的时候永远都不需要同步。

private static Vector<Integer> vector = new Vector();
    
        public static void main(String[] args) { 
            while (true){ 
                for (int i = 0; i < 10; i++) { 
                    vector.add(i);
                }
    
                Thread removeThread = new Thread(new Runnable() { 
                    public void run() { 
                        for (int i = 0; i < vector.size(); i++) { 
                            vector.remove(i);
                        }
                    }
                });
    
                Thread printThread = new Thread(new Runnable() { 
                    public void run() { 
                        for (int i = 0; i < vector.size(); i++) { 
                            System.out.println(vector.get(i));
                        }
                    }
                });
    
                removeThread.start();
                printThread.start();
            }
        }

如果一个线程恰好在错误的时间里删除了一个元素，导致序号`i`已经不再可用，在用`i`访问数组访问会抛出一个`ArrayIndexOfBoundsException`。

### 1.1.3 相对线程安全 ###

即我们通常意义上所讲的线程安全，需要保证对这个对象的单独操作是线程安全的，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。

`Java`中，大部分线程安全的类都属于相对线程安全，如`Vector`、`HashTable`、`Collections`的`synchronizedColleaction()`方法包装的集合等。

### 1.1.4 线程兼容 ###

线程兼容指对象本身不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用。

`Java`中大部分的类都属于线程兼容，如`ArrayList`和`HashMap`。

### 1.1.5 线程对立 ###

无论调用端是否采取了同步措施，都无法在多线程环境中并发的使用代码。

常见的线程对立操作有`System.setIn()`、`System.setOut()`和`System.runFinalizersOnExit()`等。

## 1.2 线程安全的实现方法 ##

### 1.2.1 互斥同步 ###

同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一条（或者一些，当使用信号量的时候）线程使用。

互斥是实现同步的一种手段，常见实现互斥的方式有临界区、互斥量和信号量等。

在`Java`里面，最基本的互斥同步手段就是`synchronized`关键字。`synchronized`经过编译后，会在同步块的前后分别形成`monitorenter`和`monitorexit`这两个字节码指令，这两个字节码都需要一个`reference`类型的参数来指定要锁定和解锁的对象。

在执行`monitorenter`指令时，首先要去尝试获取对象的锁。如果这个的对象没被锁定，或者当前线程已经持有了哪个对象的锁，就把锁的计数器的值加一，而在执行`monitorexit`指令时会将计数器的值减一。一旦计数器的值为零，锁随机就被释放了。如果获取对象锁失败，那当前线程就应当被阻塞等待，直到请求锁定的对象被持有它的线程释放为止。

自`JDK 1.5`起，`Java`类库中新提供了`java.util.concurrent`包，其中的`java.util.concurrent.locks.Lock`接口便成了`Java`的另一种全新的互斥同步手段。

重入锁`ReentrantLock`是`Lock`接口最常见的一种实现，其同样是可重入的。相比与`synchronized`，其更加灵活。同时其增加了一些高级功能，主要有以下三项：等待可中断、可实现公平锁及锁可以绑定多个条件。

*  **等待可中断**：指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情。
 *  **公平锁**：指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来一次获得锁。

非公平锁在锁被释放时，任何一个等待锁的线程都有机会获得锁。  
              ReentrantLock默认情况下也是非公平的，但可以通过带布尔值的构造函数要求使用公平锁。

*  **锁绑定多个条件**：指一个`ReetrantLock`对象可以同时绑定多个`Confition`对象。

在`synchronized`中，锁对象的`wait()`和`notify()`或`notifyall()`方法可以实现一个隐含的条件。如果要和多于一个的条件关联时，就不得不额外地添加一个锁。

`ReentrantLock`只需要多次调用 `newCondition()`方法即可。

### 1.2.2 非阻塞同步 ###

**互斥同步**：属于悲观锁，总是认为会出现线程安全问题，所以无论是否数据冲突，都进行加锁。

**非阻塞同步**：基于冲突检测的乐观锁，先进行操作，如果没有其他线程争用共享数据，那么操作就成功了。如果共享数据有争用，产生了冲突，那就再争取其他的补救措施（通常时不断重试，直到成功为止）。

`Java`采用`CAS`指令，在硬件的支持下，保证同步。

`CAS`指令有 3 个操作数，分别是内存位置（变量的内存地址，用`V`表示）、旧的预期值（用`A`表示）和准备设置的新值（用`B`表示）。`CAS`指令执行时，当前仅当`V`所在内存的值等于`A`时，处理器才会用`B`更新`V`所在内存的值，否则就不执行更新。但是，不管是否更新了`V`的值，都会返回`V`的旧值，上述的处理过程是一个原子操作，执行期间不会被其他线程中断。

`CAS`存在的逻辑漏洞：如果一个变量`V`初次读取的时候是`A`值，并且再准备赋值的时候检查到它依然是`A`值，那么并不能判断到它的值被其他线程改变过。有可能再这期间它的值被改成`B`，又修改回`A`。这种情况被称为“`ABA`”问题，大部分情况`ABA`问题不会影响程序并发的正确性。

### 1.2.3 无同步方案 ###

如果能让一个方法本来就不涉及共享数据，那它就自然不需要任何同步措施去保证其正确性，因此会有一些diamagnetic天生就是线程安全的。

*  **可重入代码**

可以在代码执行的任何时刻中断它，转而去执行另外一段代码。而在控制权返回后，原来的程序不会出现任何错误。所有可重入的代码都是线程安全的。

**可重入代码的特征**：不依赖存储在堆上的数据和公用的系统资源、用到的状态量都由参数传入、不调用非可重入的方法等。

如果一个方法返回结果是可以预测的，只要输入了相同的数据，都能返回相同的结果，那么其满足可重入要求，并且是线程安全的。

*  **线程本地存储**

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

# 2. 锁优化 #

在主流`Java`虚拟机实现中，`Java`的线程是映射到操作系统的原生内核线程之上，如果要阻塞或唤醒一条线程，则需要操作系统来帮忙完成，这就不可避免的在用户态和内核态来回切换，并且这种切换非常浪费资源。为此，通过锁优化技术，可以使线程之间更高效地共享数据及解决竞争问题，提高程序的执行效率。

## 2.1 自旋锁与自适应自旋 ##

让线程执行一个忙循环（自旋）。

这样线程就不需要通过内核态被挂起和恢复，系统的并发性能压力大大降低。

自旋等待本身虽然避免了线程切换的开销，但它要占用处理器时间，因此如果锁被占用的时间很短，自旋等待的效果就会非常好。反之，如果锁被占用的时间很长，那么自旋的线程只会浪费处理器资源，不会做任何有用的工作。

自旋等待的时间必须要有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程。自旋次数的默认值是10次，用户可以使用`-XX:PreBlockSpin`来更改。

自适应锁：自旋的时间不在固定，而是由前一次在同一个锁上的自旋时间及锁的拥有着的状态来决定。

## 2.2 锁消除 ##

虚拟机在即时编译器运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。

锁消除的主要判断依据来源于逃逸分析的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去。从而被其他线程访问到，那么就可以把他们当作栈上数据对待，认为他们是线程私有的。

## 2.3 锁粗化 ##

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

public String concatString(String a1,String a2,String a3){ 
        StringBuffer sb = new StringBuffer();
        sb.append(s1);
        sb.append(s2);
        sb.append(s3);
        return sb.toString();
    }

如果虚拟机探测到有这样一串零碎操作都是对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列外部，即在第一个append()操作之前直至最后一个`append()`操作之后，只需要加锁一次。

## 2.4 轻量级锁 ##

轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。

轻量级锁和偏向锁的实现依赖于对象头的`Mark Word`部分，其结构如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70]

**轻量级锁的工作过程**：

1.  在代码即将进入同步块的时候，如果此同步对象没有被锁定（锁标志位为“`01`”状态），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（`Lock Record`）的空间，用于存储锁对象`Mark Workd`的拷贝，这时候线程堆栈于对象头的状态如下所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 1]

1.  虚拟机使用`CAS`操作尝试把对象的`Mark Word`更新为指向`Lock Record`的指针。如果这个更新动作成功，则线程拥有了这个对象的锁，并且对象`Mark Word`的锁标志位将转变为"`00`"，表示此对象处于轻量级锁定状态。此时线程堆栈与对象头的状态如图所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 2]

1.  如果更新操作失败，则意外着至少存在一条线程与当前线程竞争获取该对象的锁。虚拟机首先会检查对象对象的`Mark Word`是否指向当前线程的栈帧，如果是，则说明当前线程已经拥有了这个对象的锁，直接进入同步块继续执行即可，否则就说明这个锁对象已经被其他线程抢占了。如果出现两个以上的线程争用一个锁，锁标志位变为“`10`”，此时`Mark Word`中存储的就是重量级锁，豆面等待锁的线程必须进入阻塞状态。
2.  轻量级锁的解锁过程同样是通过`CAS`操作进行的，如果对象的`Mark Word`仍然指向线程的锁记录，那就用`CAS`操作把对象当前的`Mark Word`和线程复制的`Displaced Mark Word`替换回来。假如能够成功替换，那整个同步过程就顺利完成；如果替换失败，则说明有其他线程尝试过获取该锁，就要在释放锁的同时，唤醒被挂起的线程。

## 2.5 偏向锁 ##

轻量级锁实在无竞争的情况下使用`CAS`操作去除同步使用的互斥量，而偏向锁就是在无竞争的情况下把整个同步都消除掉，连`CAS`操作都不去做了。

偏向锁指：这个锁会偏向第一个获得它的线程，如果在接下的执行过程中，该锁没有被其他线程获取，则持有偏向锁的线程永远不需要再进行同步。

假设当前虚拟机启用了偏向锁，当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设为“`01`”，即偏向模式。同时使用`CAS`操作把获取到这个锁的线程的`ID`记录在对象的`Mark Word`之中。如果`CAS`操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都不会进行任何同步操作。

当有另外一个线程去尝试获取这个锁时，偏向模式就宣告结束。根据锁对象目前是否处于被锁定的状态，**撤销偏向（Revoke Bias）后恢复到未锁定（标志位位 “`01`”）或轻量级锁顶（标志位为“`00`”）的状态**，后续的同步操作就如同上面介绍的轻量级锁那样执行。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 3]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200529204724737.png?/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200529205219247.png?x-oss-pge/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200529205723957.png?/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200529212109299.png?/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18=,size_16,color_FFFFFF,t_70