多线程-进阶

1. 锁的策略

1.1 乐观锁&悲观锁

1. 乐观锁

   • 预计在线程中数据大概率不会被其他线程拿去修改

   • 对于加锁所作的准备较少。只有当修改的操作真正发生了，才会进行加锁操作

   所以乐观锁适用于多读少写的情况，可以降低加锁频率，提升效率。

2. 悲观锁

   • 预计在线程中数据大概率会被其他线程拿走做修改操作
   • 加锁前的准备工作比较多

   所以悲观锁适用于对于线程安全要求高的场景。

1.2 轻量级锁&重量级锁

1. 轻量级锁

   • 对应于乐观锁
   • 加锁前的操作占用的资源少，造成的阻塞情况少
   • 较少进行内核态和用户态的切换
   • 较少进程之间的调度

2. 重量级锁

   • 对应于悲观锁
   • 加锁前的准备工作多，容易造成线程阻塞
   • 大量内核态和用户态的切换
   • 易引发进程之间的调度

   乐观和悲观是对于未加锁结果的一种猜想

   重量轻量是对于加锁后资源消耗的一种评价

   从这个角度说，这两组概念都是在描述加锁的工作对于资源的消耗。乐观就是消耗的资源较少，悲观反之。

1.3 自旋锁&挂起等待锁

1. 自旋锁

   • 重复、快速地进行锁的获取（称为自旋“）

   • 会增大cpu的消耗，可能会造成“忙等”

   • 适用于乐观、轻量的策略（虽然一直不停地在获取锁，但是过不了多久就能够真正获取到锁）

   • 伪代码：

     while(抢锁失败) {
         加锁...
     }
     

   优点：

   1. 在锁竞争平缓的情况下能够降低资源消耗，加快运行速度，避免线程之间因为简单的任务而阻塞。

   2. 其他线程一旦把锁释放，就会第一时间拿到锁

   缺点：

   1. 如果遇到锁竞争激烈的情况，会有其他线程竞争不到锁的情况。
   2. 竞争不到锁，但是还会一直进行获取锁，造成cpu的资源浪费

2. 挂起等待锁

   • 遇到锁竞争的情况就挂起等待

   • 适用于锁竞争激烈的情况

   • 与悲观、重量相对应

   • 伪代码：

     while(抢锁失败) {
         wait();
     }
     

   优点：

   避免了cpu资源浪费

   缺点：
   不能第一时间抢到锁，什么时候能加锁，由系统决定

1.4 普通互斥锁&读写锁

1. 普通互斥锁

   • 类似于synchronized，在一个线程对于同一个对象进行加锁的时候另一个线程不能对于这个对象的锁进行获取

2. 读写锁

   • 读锁

     • 给读操作加锁，读的过程中其他线程只能再读，不能写

     读的操作并没有线程安全问题，但是只局限于读，如果读的过程中，把正在读取的值拿走进行修改，那么就会产生读到“脏值”的情况。

   • 写锁

     • 给写操作加锁，在一个线程写的时候其他线程不能读，也不能写

     写就是修改，修改就会有线程安全问题，如果在修改的过程中读就可能会读到“脏值”，如果在修改的过程中继续修改就可能会引起数据的混乱。

1.5 公平锁&非公平锁

1. 公平锁

   • 基于前人发明的、前人规定的规则，“先来后到”就是公平
   • “先来后到”：一个线程拥有锁的时间越长，那就越应该下一个获取到锁
   • 有效避免了线程饿死

2. 非公平锁

   • 在释放锁之后，随机等概率竞争锁的情况
   • mutex锁就是非公平锁，synchronized是封装mutex的锁，故而也是非公平锁

   这里的“公平”和“非公平”只是基于前人发明的角度上，其实，在“等概率竞争锁”的情况下也是一种“公平“。

1.6 可重入锁&不可重入锁

1. 可重入锁

   • 可以重复加锁

   • synchronized就是可重入锁

   • 伪代码:

     lock();// 第一次加锁之后继续加锁
     lock();// 第二次加锁>
     

2. 不可重入锁

   • 不可重复加锁
   • c++中的mutex就是不可重入锁
   • 不可重入锁在进行重复加锁的时候会出现死锁现象

---

结论：

1. 乐观锁-轻量级锁-自旋锁都是对应的

2. 悲观锁-重量级锁-挂起等待锁是对应的

3. 乐观：认为自己的家不会被偷，那就在家被偷或者被贼盯上的时候再去给门上锁

   悲观：认为自己的家已经被贼盯上了，一直上着锁

4. 轻量级锁：只给家门上一个容易打开的锁，开锁的时候消耗自己的时间精力也会较少，乐观地认为贼不会偷有锁的家

   重量级锁：给家门上一个不容易打开的防盗锁，，开锁的时候消耗自己的时间精力会增加，悲观地认为一直有贼盯上我的房子

5. 自旋锁： 乐观地认为没有多少贼盯上了自己的家，所以每天都去看看自己的家有没有被偷，优点是家一被偷就能够知道，就能立马上锁，缺点是费时费力

   挂起等待锁：悲观地认为有很多贼已经盯上了自己的家，所以上一把不容易打开的锁，当有人敲门的时候再去检查是谁来，如果是贼那就不开门，让锁挂起等待，自己继续在家里玩游戏。好处是减少了自己的任务量，可以有效防止多个贼同时顶上自己家的情况，缺点是这把锁自己也不容易打开

6. 普通互斥锁：

2. CAS

乐观锁的常用实现算法是CAS算法，全称是CompareAndSwap（比较和交换），这个也是cpu中存在的一条cas指令。

伪代码：

boolen cas(address, expectedValue, swapValue) {
    if (&address == expectedValue) {
        &address = swapValue;
        return true;
    }
    return false;
}

address表示内存，expectedValue和swapValue是两个寄存器。

如果内存中的值与交换前所期望的值相等，那就与准备交换的值进行交换（说是交换，其实就是赋值）。

expectedValue就是内存中值的”旧值“，通过与这个”旧值“进行比较，就能够发现此值在修改前是否进行了改动，防止读到”脏值“。

---

3. synchronized 原理

3.1 锁的升级

synchronized锁是一把自适应锁，当一个线程执行到synchronized的时候，如果这个线程还未加上锁，那么synchronized就会经理以下过程：

1. 偏向锁阶段

   核心思想就是”懒汉模式”，非必要不加锁（升级成轻量级锁就是必要的时候）。

   • 在这个阶段并不会真正地加上锁，但是会对于有加锁可能性的对象在对象头进行标记，标记这个对象属于哪个线程
   • 如果后续没有线程竞争这把锁，那就不再真正的进行加锁，就省下了加锁的消耗
   • 如果一旦发生线程安全问题，立马升级为轻量级锁

   感觉有点像占着茅坑不拉屎，一旦有人来了就蹲下拉屎，没人来也就占着。（学校的占座不就是这样吗🐶）

2. 轻量级锁阶段

   • 随着线程之间少量的锁竞争，偏向锁状态被消除（并不是解锁了），进入轻量级锁阶段，这个阶段由自旋锁进行实现

   • synchronized内部会统计当前这个锁对象有多少个线程想要竞争，如果数量多，那么还会升级为重量级锁

     因为锁的竞争大的话，对于自旋锁来说大量的线程都在自旋，这样不能提高效率，反而会带来更多的cpu消耗。

3. 重量级锁阶段

   • 随着线程之间大量的锁竞争，轻量级锁升级为重量级锁
   • 此时不会对于锁竞争发生自旋，而是进入阻塞等待状态，就会有大部分的线程让出cpu
   • 当目前占有锁的线程执行完毕以后就会释放锁，剩余线程等概率竞争锁

3.2 锁的工作原理

1. synchronized锁是:

   1. 对于以下锁的状态自适应：
      1. 乐观、悲观锁
      2. 自旋、挂起等待锁
      3. 轻量级、重量级
   2. 不是读写锁
   3. 非公平锁
   4. 可重入锁

2. 系统原生mutex锁是：

   1. 悲观锁
   2. 重量级锁
   3. 挂起等待锁
   4. 互斥锁
   5. 非公平锁
   6. 不可重入锁

   4. 其他的优化操作

   4.1 锁消除

   当编译器发现加锁的这一部分代码中，并未涉及变量修改的部分，那么就会自动将锁去掉。

   使用线程安全的StringBuffer举个例子:

   StringBuffer sb = new StringBuffer();
   sb.append("a");
   sb.append("b");
   sb.append("c");
   sb.append("d");
   

   这段代码中虽然每个append 都有加锁解锁的操作，但是jvm+编译器都发现这段代码并没有真正的线程安全问题，所以就不会进行加锁和解锁，避免了资源的无谓消耗。

   4.2 锁粗化

   与锁粗化关系密切的一个重要概念是锁的粒度。

   锁的粒度就像吃的牛肉粒一样，每次加一个锁就是一个牛肉粒，有两种策略吃:

   1. 每次剥开一个牛肉粒就吃一个
   2. 每次剥开不吃，等到攒成一个大牛肉粒再吃

   两种伪代码分别对应这两种情况：

   for() {
       synchronized(locker) {
       	// TODO
       }
   }
   

   将锁粗化：

   synchronized(locker) {
       for() {
       	// TODO
       }
   }
   

4. 死锁

4.1 死锁的成因有4个：

1. 循环等待

   当锁A唤醒需要锁B先释放，锁B唤醒需要锁A先释放，就构成了循环等待。

2. 请求和保持

   当一个线程获取新锁的同时，它会继续对于当前已有的锁进行占有。

3. 互斥使用

   资源被一个线程占有时，其他的线程不能同时使用。

4. 不可抢占

   资源被一个线程占有时，其他线程不能抢占使用，只能等待当前占有者主动释放。

---

其中，3和4是锁的特性无法改变，但是1和2可以通过代码结构进行破坏。

比较著名的是“哲学家就餐问题”：

当这5名哲学家都需要吃饭的时候，餐桌上拥有的筷子数量肯定是不够用的，但是如果给哲学家加上拿筷子的顺序，那么就只会有一名哲学家在“阻塞等待”。

比如：规定每名哲学家只能先拿起编号小的筷子，那么就是0号老铁先吃

1号老铁进行阻塞等待，等到0号老铁吃完以后再先拿起编号小的1号筷子+2号筷子吃

2，3，4老铁同理。

4.2 破坏死锁

就是调整代码结构，破除循环等待这个条件。