并发的设计模式(二)

1.写在前面

笔者前面已经介绍了几种并发的设计模式，这篇笔者继续讲剩下的几种设计模式

2.Guarded Suspension模式

2.1概述

举个例子：比如，项目组团建要外出聚餐，我们提前预订了一个包间，然后兴冲冲地奔过去，到那儿后大堂经理看了一眼包间，发现服务员正在收拾，就会告诉我们：“您预订的包间服务员正在收拾，请您稍等片刻。”过了一会，大堂经理发现包间已经收拾完了，于是马上带我们去包间就餐。

Guarded Suspension模式直译过来就是保护性地暂停，下图就是 Guarded Suspension 模式的结构图，非常简单，一个对象 GuardedObject，内部有一个成员变量——受保护的对象，以及两个成员方法——get(Predicate p)和onChanged(T obj)方法。其中，对象 GuardedObject 就是我们前面提到的大堂经理，受保护对象就是餐厅里面的包间；受保护对象的 get() 方法对应的是我们的就餐，就餐的前提条件是包间已经收拾好了，参数 p 就是用来描述这个前提条件的；受保护对象的onChanged() 方法对应的是服务员把包间收拾好了，通过 onChanged() 方法可以 fire 一个事件，而这个事件往往能改变前提条件 p 的计算结果。

GuardedObject 的内部实现非常简单，是管程的一个经典用法，你可以参考下面的示例代码，核心是：get() 方法通过条件变量的 await() 方法实现等待，onChanged() 方法通过条件变量的 signalAll() 方法实现唤醒功能。逻辑还是很简单的，所以这里就不再详细介绍了。

class GuardedObject<T>{
	// 受保护的对象
	T obj;
	final Lock lock = new ReentrantLock();
	final Condition done = lock.newCondition();
	final int timeout=1;
	// 获取受保护对象
	T get(Predicate<T> p) {
		lock.lock();
		try {
			//MESA 管程推荐写法
			while(!p.test(obj)){
				done.await(timeout,TimeUnit.SECONDS);
			}
		}catch(InterruptedException e){
			throw new RuntimeException(e);
		}finally{
			lock.unlock();
		}
		// 返回非空的受保护对象
    	return obj;
	}
	// 事件通知方法
	void onChanged(T obj) {
		lock.lock();
		try {
			this.obj = obj;
			done.signalAll();
		} finally {
			lock.unlock();
		}
	}
}

2.2扩展 Guarded Suspension 模式

引出一个小问题：小灰工作中遇到一个问题，他开发了一个 Web 项目：Web 版的文件浏览器，通过它用户可以在浏览器里查看服务器上的目录和文件。这个项目依赖运维部门提供的文件浏览服务，而这个文件浏览服务只支持消息队列（MQ）方式接入。消息队列在互联网大厂中用的非常多，主要用作流量削峰和系统解耦。在这种接入方式中，发送消息和消费结果这两个操作之间是异步的，你可以参考下面的示意图来理解。

在小灰的这个 Web 项目中，用户通过浏览器发过来一个请求，会被转换成一个异步消息发送给 MQ，等 MQ 返回结果后，再将这个结果返回至浏览器。小灰同学的问题是：给 MQ发送消息的线程是处理 Web 请求的线程 T1，但消费 MQ 结果的线程并不是线程 T1，那线程 T1 如何等待 MQ 的返回结果呢？

有了前面的知识，我们写出如下的代码

class GuardedObject<T>{
	// 受保护的对象
	T obj;
	final Lock lock = new ReentrantLock();
	final Condition done = lock.newCondition();
	final int timeout=2;
	// 保存所有 GuardedObject
	final static Map<Object, GuardedObject> gos=new ConcurrentHashMap<>();
	// 静态方法创建 GuardedObject
	static <K> GuardedObject create(K key){
		GuardedObject go=new GuardedObject();
		gos.put(key, go);
		return go;
	}
	static <K, T> void fireEvent(K key, T obj){
		GuardedObject go=gos.remove(key);
		if (go != null){
			go.onChanged(obj);
		}
	}
	// 获取受保护对象
	T get(Predicate<T> p) {
		lock.lock();
		try {
			//MESA 管程推荐写法
			while(!p.test(obj)){
				done.await(timeout,TimeUnit.SECONDS);
			}
		}catch(InterruptedException e){
			throw new RuntimeException(e);
		}finally{
			lock.unlock();
		}
		// 返回非空的受保护对象
		return obj;
	}
	// 事件通知方法
	void onChanged(T obj) {
		lock.lock();
		try {
			this.obj = obj;
			done.signalAll();
		} finally {
			lock.unlock();
		}
	}
}

// 处理浏览器发来的请求
Respond handleWebReq(){
	int id= 序号生成器.get();
	// 创建一消息
	Message msg1 = new Message(id,"{...}");
	// 创建 GuardedObject 实例
	GuardedObject<Message> go= GuardedObject.create(id);
	// 发送消息
	send(msg1);
	// 等待 MQ 消息
	Message r = go.get(t->t != null);
}
void onMessage(Message msg){
	// 唤醒等待的线程
	GuardedObject.fireEvent(msg.id, msg);
}

我们利用id来保证GuardedObject对象是一个，扩展 Guarded Suspension模式的实现，扩展后的 GuardedObject 内部维护了一个 Map，其 Key 是 MQ 消息 id，
而 Value 是 GuardedObject 对象实例，同时增加了静态方法 create() 和 fireEvent()；create() 方法用来创建一个 GuardedObject 对象实例，并根据 key 值将其加入到 Map中，而 fireEvent() 方法则是模拟的大堂经理根据包间找就餐人的逻辑。

2.3总结

Guarded Suspension 模式本质上是一种等待唤醒机制的实现，只不过 GuardedSuspension 模式将其规范化了。规范化的好处是你无需重头思考如何实现，也无需担心实现程序的可理解性问题，同时也能避免一不小心写出个 Bug 来。

Guarded Suspension 模式也常被称作 Guarded Wait 模式、Spin Lock 模式（因为使用了 while 循环去等待），这些名字都很形象，不过它还有一个更形象的非官方名字：多线程版本的 if。单线程场景中，if 语句是不需要等待的，因为在只有一个线程的条件下，如果这个线程被阻塞，那就没有其他活动线程了，这意味着 if 判断条件的结果也不会发生变化了。但是多线程场景中，等待就变得有意义了，这种场景下，if 判断条件的结果是可能发生变化的。所以，用“多线程版本的 if”来理解这个模式会更简单。

3.Balking模式

上节我们提到可以用“多线程版本的 if”来理解 Guarded Suspension 模式，不同于单线程中的 if，这个“多线程版本的 if”是需要等待的，而且还很执着，必须要等到
条件为真。但很显然这个世界，不是所有场景都需要这么执着，有时候我们还需要快速放弃。

需要快速放弃的一个最常见的例子是各种编辑器提供的自动保存功能。自动保存功能的实现逻辑一般都是隔一定时间自动执行存盘操作，存盘操作的前提是文件做过修改，如果文件没有执行过修改操作，就需要快速放弃存盘操作。 条件就是是否改变过，说到底就是一个状态变量，业务逻辑依赖于这个状态变量的状态：当状态满足某个条件时，执行某个业务逻辑，其本质其实不过就是一个 if 而已，放到多线程场景里，就是一种“多线程版本的 if”。这种“多线程版本的 if”的应用场景还是很多的，所以也有人把它总结成了一种设计模式，叫做Balking模式。

3.1Balking模式的经典实现

笔者带着大家用这种模式写一个自动保存的例子，具体的代码如下：

boolean changed=false;
// 自动存盘操作
void autoSave(){
	synchronized(this){
        if (!changed) {
            return;
        }
		changed = false;
	}
	// 执行存盘操作
	// 省略且实现
	this.execSave();
}
// 编辑操作
void edit(){
	// 省略编辑逻辑
	......
	change();
}
// 改变状态
void change(){
	synchronized(this){
		changed = true;
	}
}

你会发现仅仅是将 edit() 方法中对共享变量 changed 的赋值操作抽取到了 change() 中，这样的好处是将并发处理逻辑和业务逻辑分开。

3.2用volatile实现Balking模式

前面笔者使用的是synchronized实现了 Balking 模式，这种实现方式最为稳妥，建议你实际工作中也使用这个方案。不过在某些特定场景下，也可以使用 volatile 来实现，但使用volatile 的前提是对原子性没有要求。

最经典的就是双重检查，具体的代码如下：

class Singleton{
	private static volatile Singleton singleton;
	// 构造方法私有化
	private Singleton() {}
		// 获取实例（单例）
	public static Singleton
		getInstance() {
			// 第一次检查
			if(singleton==null){
				synchronize{Singleton.class){
					// 获取锁后二次检查
					if(singleton==null){
						singleton=new Singleton();
					}
				}
			}
		return singleton;
	}
}

3.3总结

Balking 模式和 Guarded Suspension 模式从实现上看似乎没有多大的关系，Balking 模式只需要用互斥锁就能解决，而 Guarded Suspension 模式则要用到管程这种高级的并发原语；但是从应用的角度来看，它们解决的都是“线程安全的 if”语义，不同之处在于，Guarded Suspension 模式会等待 if 条件为真，而 Balking 模式不会等待。

Balking 模式的经典实现是使用互斥锁，你可以使用 Java 语言内置 synchronized，也可以使用 SDK 提供 Lock；如果你对互斥锁的性能不满意，可以尝试采用 volatile 方案，不过使用 volatile 方案需要你更加谨慎。

当然你也可以尝试使用双重检查方案来优化性能，双重检查中的第一次检查，完全是出于对性能的考量：避免执行加锁操作，因为加锁操作很耗时。而加锁之后的二次检查，则是出于对安全性负责。

4.Thread-Per-Message模式：最简单实用的分工方法

4.1概述

简言之就是为每个任务分配一个独立的线程。

4.2用Thread实现Thread-Per-Message模式

Thread-Per-Message 模式的一个最经典的应用场景是网络编程里服务端的实现，服务端为每个客户端请求创建一个独立的线程，当线程处理完请求后，自动销毁，这是一种最简单的并发处理网络请求的方法。

我们来写简单的网络程序echo程序

final ServerSocketChannel ssc = ServerSocketChannel.open().bind(new InetSocketAddress(8080));
// 处理请求
try {
	while (true) {
		// 接收请求
		SocketChannel sc = ssc.accept();
		// 每个请求都创建一个线程
		new Thread(()->{
			try {
				// 读 Socket
				ByteBuffer rb = ByteBuffer.allocateDirect(1024);
				sc.read(rb);
				// 模拟处理请求
				Thread.sleep(2000);
				// 写 Socket
				ByteBuffer wb = (ByteBuffer)rb.flip();
				sc.write(wb);
				// 关闭 Socket
				sc.close();
			}catch(Exception e){
				throw new UncheckedIOException(e);
			}
		}).start();
	}
} finally {
	ssc.close();
}

上面的代码的问题就是：上面这个 echo 服务的实现方案是不具备可行性的。原因在于 Java 中的线程是一个重量级的对象，创建成本很高，一方面创建线程比较耗时，另一方面线程占用的内存也比较大。所以，为每个请求创建一个新的线程并不适合高并发场景。

Java 语言里，Java 线程是和操作系统线程一一对应的，这种做法本质上是将 Java 线程的调度权完全委托给操作系统，而操作系统在这方面非常成熟，所以这种做法的好处是稳定、可靠，但是也继承了操作系统线程的缺点：创建成本高。为了解决这个缺点，Java 并发包里提供了线程池等工具类。这个思路在很长一段时间里都是很稳妥的方案，但是这个方案并不是唯一的方案。 业界还有另外一种方案，叫做轻量级线程。

4.3用 Fiber 实现 Thread-Per-Message 模式

final ServerSocketChannel ssc = ServerSocketChannel.open().bind(new InetSocketAddress(8080));
// 处理请求
try{
	while (true) {
		// 接收请求
		final SocketChannel sc = serverSocketChannel.accept();
		Fiber.schedule(()->{
			try {
				// 读 Socket
				ByteBuffer rb = ByteBuffer.allocateDirect(1024);
				sc.read(rb);
				// 模拟处理请求
				LockSupport.parkNanos(2000*1000000);
				// 写 Socket
				ByteBuffer wb = (ByteBuffer)rb.flip()
				sc.write(wb);
				// 关闭 Socket
				sc.close();
			} catch(Exception e){
				throw new UncheckedIOException(e);
			}
		});
	}//while
}finally{
	ssc.close();
}

4.4总结

并发编程领域的分工问题，指的是如何高效地拆解任务并分配给线程。前面我们在并发工具类模块中已经介绍了不少解决分工问题的工具类，例如 Future、CompletableFuture 、CompletionService、Fork/Join 计算框架等，这些工具类都能很好地解决特定应用场景的问题，所以，这些工具类曾经是 Java 语言引以为傲的。不过这些工具类都继承了 Java 语言的老毛病：太复杂。

Thread-Per-Message 模式在 Java 领域并不是那么知名，根本原因在于 Java 语言里的线程是一个重量级的对象，为每一个任务创建一个线程成本太高，尤其是在高并发领域，基本就不具备可行性。不过这个背景条件目前正在发生巨变，Java 语言未来一定会提供轻量级线程，这样基于轻量级线程实现 Thread-Per-Message 模式就是一个非常靠谱的选择。

5.写在最后

本篇博客主要介绍几种并发的设计模式，后面还有一个设计模式，会在下篇博客中说明。