我的创作纪念日——多线程进阶分享

多线程-进阶

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 破坏死锁

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

5. Callable 接口

Callable 的用法

Callable是一个接口，相当于对于线程进行了一个返回值的封装，与Runnable接口不同之处在于：

• Runnable接口更关注过程，所以返回值是void
• Callable接口更关注结果，所以返回值与创建时的泛型参数相同

Callable的运行结果需要借助FutureTask进行get得到。

import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.FutureTask;

public class test1 {
    public static void main(String[] args) throws ExecutionException, InterruptedException {
        Callable<Integer> callable = new Callable<Integer>() {
            @Override
            public Integer call() throws Exception {
                // 计算从1加到1000的值
                int ret = 0;
                for (int i = 1; i <= 1000; i++) {
                    ret += i;
                }
                return ret;
            }
        };

        // 使用FutureTask对于Callable与Thread进行“粘合”
        FutureTask<Integer> futureTask = new FutureTask<>(callable);
        Thread thread = new Thread(futureTask);
        thread.start();
        System.out.println(futureTask.get());
    }
}

运行结果:

几点说明:

1. 不用手动实现线程同步的代码
2. 需要使用FutureTask对于Thread和Callable进行“粘合”
3. FutureTask 用来保存 Callable 的返回结果

6. JUC(java.util.concurrent) 的常见类

6.1 ReentrantLock

• ReentrantLock是可重入互斥锁
• 提供了三种方法：
  • try lock()：尝试加锁，如果加不上，就不加，不会进行死等
  • lock()：加锁
  • unlock()：解锁
• ReentrantLock的加锁方式容易让人忘记释放锁（可能在unlock前进行return或者触发异常），所以正确使用方式：在finally中进行unlock()

与synchronized的区别：

相同点：

• synchronized 和 ReentrantLock 都是 Java 中提供的可重入锁

不同点：

• 用法不同：synchronized 可以用来修饰普通方法、静态方法和代码块；ReentrantLock 只能用于代码块；
• 获取和释放锁的机制不同：进入synchronized 块自动加锁和执行完后自动释放锁； ReentrantLock 需要显示的手动加锁和释
• 锁；
• 锁类型不同：synchronized 是非公平锁； ReentrantLock 默认为非公平锁，也可以手动指定为公平锁；
• 响应中断不同：synchronized 不能响应中断；ReentrantLock 可以响应中断，可用于解决死锁的问题；
• 底层实现不同：synchronized 是 JVM 层面通过监视器实现的；ReentrantLock 是基于 AQS 实现的。

6.2 信号量 Semaphore

本质上是一个计数器

用一个信号表示当前还有多少可用资源，有两个操作：

• p操作，表示申请资源（accquire）——会进行阻塞
• v操作，表示释放资源（release）

public class test2 {
    public static void main(String[] args) throws InterruptedException {
        // 表明当前还有4个可用资源
        Semaphore semaphore = new Semaphore(2);

        // 进行获取资源
        semaphore.acquire();
        System.out.println("已成功申请资源");

        semaphore.release();
        System.out.println("已成功释放资源");


        // 阻塞
        semaphore.acquire();
        System.out.println("进行第一次资源申请");
        semaphore.acquire();
        System.out.println("进行第二次资源申请");
        semaphore.acquire();
        System.out.println("进行第三次资源申请");// 会进行阻塞，因为总共只有2个可用资源
    }
}

运行结果:

---

6.3 CountDownLatch

同时等待N个线程执行结束后，通过await()方法，执行后续代码。

import java.util.concurrent.CountDownLatch;

public class test3 {
    public static void main(String[] args) {
        final int threadNum = 10;
        // 表示有10个线程任务需要完成
        CountDownLatch countDownLatch = new CountDownLatch(threadNum);

        Runnable runnable = new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(1000);
                    // 每次执行完之后countDown
                    countDownLatch.countDown();
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
            }
        };

        // 创建10个线程
        for (int i = 0; i < 10; i++) {
            Thread thread = new Thread(runnable);
            thread.start();
            System.out.println(i);
        }

        // 起到分界线的作用，在countdownLatch中预定的线程未执行完时不会进行
        try {
            countDownLatch.await();
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }

        System.out.println("线程全部执行完毕");
    }
}

7. 线程安全的集合类

Stack、Vector、Hashtable都是线程安全的。

7.1 多线程中使用ArrayLIst

1） 使用Collections.synchronizedList()进行封装

public class test4 {
    public static void main(String[] args) {
        // 实现一个带有线程同步的ArrayList
        Collections.synchronizedList(new ArrayList<>());
    }
}`

2） 使用

7.2 多线程使用队列

1. ArrayBlockingQueue 基于数组实现的阻塞队列

2. LinkedBlockingQueue 基于链表实现的阻塞队列

3. PriorityBlockingQueue 基于堆实现的带优先级的阻塞队列

4. TransferQueue 最多只包含一个元素的阻塞队列

7.3 多线程使用哈希表

1） Hashtable

• 只是在关键方法上加上synchronized，效率低
• 一旦触发扩容，整个Hashtable都需要竞争等待，会造成暂时的卡顿，也即“不稳定”
• size属性通过synchronized进行控制，效率低

因为整个对象都是一把锁，所以即使是访问同一哈希表上不同链表的时候也会造成锁竞争。

所以需要进行锁粗化，引出“ConcurrentHashMap”。

2）ConcurrentHashMap

• 锁粗化后，Hashtable上的每个链表各自占有一把锁，降低锁冲突的概率

• size属性利用CAS操作进行维护，提高效率

• 针对扩容进行优化，采用**“化整为零”**思想（CopyOnWrite）

  Hashtable会将整个数组进行拷贝，但是每次只会复制一些，分步完成，不会造成像Hashtable一样的暂时卡顿现象。

  但是，会造成两个同时存在的数组:

  • 查找、删除操作需要在两个数组中都操作
  • 插入只需要在复制出来的新表上操作