java并发设计模式

发表于 更新于 分类于 阅读次数： Waline： 本文字数： 5.2k 阅读时长 ≈ 5 分钟

多线程设计模式是前人解决并发问题的经验总结，当我们试图解决一个并发问题时，首选方案往往是使用匹配的设计模式，这样能避免走弯路。
大家都熟悉设计模式，所以使用设计模式还能提升方案和代码的可理解性。

避免共享的设计模式
Immutability 模式、Copy-on-Write 模式 和 线程本地存储模式 本质上都是为了避免共享，只是实现手段不同而已。

多线程版本IF的设计模式
Guarded Suspension 模式 和 Balking 模式 都可以简单地理解为“多线程版本的 if”，但它们的区别在于前者会等待 if 条件变为真，而后者则不需要等待。

三种最简单的分工模式
Thread-Per-Message模式 、 Worker Thread 模式 和 生产者-消费者模式 是三种最简单实用的多线程分工方法

(1) Immutability Pattern 不变性模式

解决并发问题，其实最简单的办法就是让共享变量只有读操作，而没有写操作。

不变性（Immutability）模式。所谓不变性，简单来讲，就是对象一旦被创建之后，状态就不再发生变化。换句话说，就是变量一旦被赋值，就不允许修改了（没有写操作）；没有修改操作，也就是保持了不变性。

Java SDK 里很多类都具备不可变性。例如经常用到的 String 和 Long、Integer、Double 等基础类型的包装类都具备不可变性，这些对象的线程安全性都是靠不可变性来保证的。仔细翻看这些类的声明、属性和方法，你会发现它们都严格遵守不可变类的三点要求：类和属性都是 final 的，所有方法均是只读的。

Java所有的基础类型的包装类都不适合做锁，因为它们内部用到了享元模式，这会导致看上去私有的锁，其实是共有的。

使用 Immutability 模式的注意事项在使用 Immutability 模式的时候，需要注意以下两点：

  1. 对象的所有属性都是 final 的，并不能保证不可变性；
  2. 不可变对象也需要正确发布。

在使用 Immutability 模式的时候一定要确认保持不变性的边界在哪里，是否要求属性对象也具备不可变性。
Foo对象是不变的，但是Foo对象的属性是可以变化的

class Foo{
 int age=0;
 int name="abc";
}
final class Bar {
 final Foo foo;
 void setAge(int a){
   foo.age=a;
 }
}

不可变对象虽然是线程安全的，但是并不意味着引用这些不可变对象的对象就是线程安全的。

//Foo线程安全
final class Foo{
 final int age=0;
 final int name="abc";
}
//Bar线程不安全
class Bar {
 Foo foo;
 void setFoo(Foo f){
   this.foo=f;
 }
}

(2) Copy-on-Write Parrent 写时复制模式

Java 里 String 这个类在实现 replace() 方法的时候，并没有更改原字符串里面 value[]数组的内容，而是创建了一个新字符串，这种方法在解决不可变对象的修改问题时经常用到。
Copy-on-Write，经常被缩写为 COW 或者 CoW，顾名思义就是写时复制。
不可变对象的写操作往往都是使用 Copy-on-Write 方法解决的。

Java 提供的 Copy-on-Write 容器，由于在修改的同时会复制整个容器，所以在提升读操作性能的同时，是以内存复制为代价的。

CopyOnWriteArrayList 和 CopyOnWriteArraySet 这两个 Copy-on-Write 容器，它们背后的设计思想就是 Copy-on-Write；
类Unix操作系统fork()函数
Docker 容器镜像的设计是 Copy-on-Write
分布式源码管理系统 Git 背后的设计思想都有 Copy-on-Write
函数式编程里面所有的修改操作都需要 Copy-on-Write 来解决 (按需复制)

《Purely Functional Data Structures》

Java 提供了 CopyOnWriteArrayList，为什么没有提供 CopyOnWriteLinkedList 呢？

  1. 没有提供CopyOnWriteLinkedList是因为linkedlist的数据结构关系分散到每一个节点里面，对每一个节点的修改都存在竟态条件，需要同步才能保证一致性。arraylist就不一样，数组天然的拥有前驱后继的结构关系，对列表的增删，因为是copy on wirte，所以只需要cas操作数组对象就能够保证线程安全，效率上也能接受，更重要的是避免锁竞争带来的上下文切换消耗。有一点需要注意的是CopyOnWriteArrayList在使用上有数据不完整的时间窗口，要不要考虑需要根据具体场景定夺。
  2. 链表的新增删除压根就不需要复制，就算是在并发场景下采用锁的方式性能损耗都不大，因此也就没必要采用copy的方式了，更何况链表的操作可以采用分段锁、节点锁。所以没有CopyOnWriteLinkedList的主要原因是没有这个必要。
  3. ArrayList 是用是数组实现的, 在内存上时一块连续的区域, 拷贝时效率比较高, 时间复杂度为 O(1)
  4. LinkedList 是链表实现, 其数据是通过指针串联起来的, 并非一块连续的区域, 拷贝时必须要进行遍历操作, 效率比较低, 时间复杂度是 O(n)
  5. CopyOnWriteLinkedList的链表结构读取效率比较低，就违背了读多写少的设计初衷。

(3) ThreadLocal 线程本地存储

线程本地存储模式本质上是一种避免共享的方案，由于没有共享，所以自然也就没有并发问题。

避免共享有两种方案，一种方案是将这个工具类作为局部变量使用，另外一种方案就是线程本地存储模式

(4) Guarded Suspension 模式

Guarded Suspension 模式本质上是一种等待唤醒机制的实现，只不过 Guarded Suspension 模式将其规范化了。

Guarded Suspension 模式也常被称作 Guarded Wait 模式、Spin Lock 模式（因为使用了 while 循环去等待），这些名字都很形象，不过它还有一个更形象的非官方名字：多线程版本的 if。

(5) Balking模式

Balking 模式和 Guarded Suspension 模式从实现上看似乎没有多大的关系，Balking 模式只需要用互斥锁就能解决，而 Guarded Suspension 模式则要用到管程这种高级的并发原语；

从应用的角度来看，它们解决的都是“线程安全的 if”语义，不同之处在于，Guarded Suspension 模式会等待 if 条件为真，而 Balking 模式不会等待。

(6) Thread-Per-Message模式

委托他人办理的方式，在并发编程领域被总结为一种设计模式，叫做 Thread-Per-Message 模式，简言之就是为每个任务分配一个独立的线程。这是一种最简单的分工方法。

你委托代办人做事，往往是和代办人直接沟通的；对应到编程领域，其实现也是主线程直接创建了一个子线程，主子线程之间是可以直接通信的。

Thread-Per-Message 模式在 Java 领域并不是那么知名，根本原因在于 Java 语言里的线程是一个重量级的对象，为每一个任务创建一个线程成本太高，尤其是在高并发领域，基本就不具备可行性。

Thread-Per-Message 模式在实现的时候需要注意是否存在线程的频繁创建、销毁以及是否可能导致 OOM。

Loom项目里Fiber实现了java轻量级线程(用户态) 官网 https://wiki.openjdk.java.net/display/loom

(7) Worker Thread模式

Worker Thread 模式类比的是工厂里车间工人的工作模式。

Worker Thread 模式能避免线程频繁创建、销毁的问题，而且能够限制线程的最大数量。

Java 语言里可以直接使用线程池来实现 Worker Thread 模式。
Worker Thread 模式的实现，需要注意潜在的线程死锁问题。
共享线程池虽然能够提供线程池的使用效率，但一定要保证一个前提，那就是：任务之间没有依赖关系。

(8) 两阶段终止模式

两阶段终止模式。顾名思义，就是将终止过程分成两个阶段，其中第一个阶段主要是线程 T1 向线程 T2发送终止指令，而第二阶段则是线程 T2响应终止指令。

Java 线程进入终止状态的前提是线程进入 RUNNABLE 状态，而实际上线程也可能处在休眠状态，也就是说，我们要想终止一个线程，首先要把线程的状态从休眠状态转换到 RUNNABLE 状态。
如何做到呢？这个要靠 Java Thread 类提供的 interrupt() 方法，它可以将休眠状态的线程转换到 RUNNABLE 状态。
线程转换到 RUNNABLE 状态之后，我们如何再将其终止呢？
RUNNABLE 状态转换到终止状态，优雅的方式是让 Java 线程自己执行完 run() 方法，所以一般我们采用的方法是设置一个标志位，然后线程会在合适的时机检查这个标志位，如果发现符合终止条件，则自动退出 run() 方法。
这个过程其实就是我们前面提到的第二阶段：响应终止指令。
综合上面这两点，我们能总结出终止指令，其实包括两方面内容：interrupt()方法和线程终止的标志位。

class Proxy {
  //线程终止标志位
  volatile boolean terminated = false;
  boolean started = false;
  //采集线程
  Thread rptThread;
  //启动采集功能
  synchronized void start(){
    //不允许同时启动多个采集线程
    if (started) {
      return;
    }
    started = true;
    terminated = false;
    rptThread = new Thread(()->{
      while (!terminated){
        //省略采集、回传实现
        report();
        //每隔两秒钟采集、回传一次数据
        try {
          Thread.sleep(2000);
        } catch (InterruptedException e){
          //重新设置线程中断状态
          Thread.currentThread().interrupt();
        }
      }
      //执行到此处说明线程马上终止
      started = false;
    });
    rptThread.start();
  }
  //终止采集功能
  synchronized void stop(){
    //设置中断标志位
    terminated = true;
    //中断线程rptThread
    rptThread.interrupt();
  }
}

Java 领域用的最多的还是线程池，而不是手动地创建线程。那我们该如何优雅地终止线程池呢？
shutdown() 方法是一种很保守的关闭线程池的方法。线程池执行 shutdown() 后，就会拒绝接收新的任务，但是会等待线程池中正在执行的任务和已经进入阻塞队列的任务都执行完之后才最终关闭线程池。
而 shutdownNow() 方法，相对就激进一些了，线程池执行 shutdownNow() 后，会拒绝接收新的任务，同时还会中断线程池中正在执行的任务，已经进入阻塞队列的任务也被剥夺了执行的机会，不过这些被剥夺执行机会的任务会作为 shutdownNow() 方法的返回值返回。

(9) 生产者-消费者模式

从架构设计的角度来看，生产者 - 消费者模式有一个很重要的优点，就是解耦。
生产者 - 消费者模式还有一个重要的优点就是支持异步，并且能够平衡生产者和消费者的速度差异。

Java 线程池本质上就是用生产者 - 消费者模式实现的，所以每当使用线程池的时候，其实就是在应用生产者 - 消费者模式。

线程池终止指定线程
线程池在消费到毒丸时知道需要结束，将方法执行完，break循环体。

References

[1] 28 | Immutability模式：如何利用不变性解决并发问题？
[2] 29 | Copy-on-Write模式：不是延时策略的COW
[3] 30 | 线程本地存储模式：没有共享，就没有伤害
[4] 31 | Guarded Suspension模式：等待唤醒机制的规范实现
[5] 32 | Balking模式：再谈线程安全的单例模式
[6] 33 | Thread-Per-Message模式：最简单实用的分工方法
[7] 34 | Worker Thread模式：如何避免重复创建线程？
[8] 35 | 两阶段终止模式：如何优雅地终止线程？
[9] 36 | 生产者-消费者模式：用流水线思想提高效率
[10] 37 | 设计模式模块热点问题答疑
[11] 《图解 Java 多线程设计模式》