学习Reactor反应器模式(二)
前面学习了单线程的Reactor反应器模式,我接着将单线程的代码改成了多线程。
多线程Reactor反应器模式
总体来说,多线程池反应器的模式,大致如下:
(1)将负责输入输出处理的IOHandler处理器的执行,放入独立的线程池中。这样,业务处理线程与负责服务监听和IO事件查询的反应器线程相隔离,避免服务器的连接监听受到阻塞。
(2)如果服务器为多核的CPU,可以将反应器线程拆分为多个子反应器线程;同时,引入多个选择器,每一个SubReactor子线程负责一个选择器。这样,充分释放了系统资源的能力;也提高了反应器管理大量连接,提升选择大量通道的能力。
代码如下
接下来再看看处理器的代码
class MultiThreadEchoHandler implements Runnable
{
final SocketChannel channel;
final SelectionKey sk;
final ByteBuffer byteBuffer = ByteBuffer.allocate(1024);
static final int RECIEVING = 0, SENDING = 1;
int state = RECIEVING;
//引入线程池
static ExecutorService pool = Executors.newFixedThreadPool(4);
MultiThreadEchoHandler(Selector selector, SocketChannel c) throws IOException
{
channel = c;
c.configureBlocking(false);
//先取得选择键,再设置感兴趣的IO事件
sk = channel.register(selector, 0);
//将本Handler作为sk选择键的附件,方便事件dispatch
sk.attach(this);
//向sk选择键注册Read就绪事件
sk.interestOps(SelectionKey.OP_READ);
selector.wakeup();
}
public void run()
{
//提交数据传输任务到线程池
// IO处理不在IO事件轮询线程中执行,在独立的线程池中执行
pool.submit(()->asyncRun());
}
//数据传输任务,不在IO事件轮询线程中执行,在独立的线程池中执行
public synchronized void asyncRun()
{
try
{
if (state == SENDING)
{
//写入通道
channel.write(byteBuffer);
//写完后,准备开始从通道读,byteBuffer切换成写模式
byteBuffer.clear();
//写完后,注册read就绪事件
sk.interestOps(SelectionKey.OP_READ);
//写完后,进入接收的状态
state = RECIEVING;
} else if (state == RECIEVING)
{
//从通道读
int length = 0;
while ((length = channel.read(byteBuffer)) > 0)
{
Logger.info(new String(byteBuffer.array(), 0, length));
}
//读完后,准备开始写入通道,byteBuffer切换成读模式
byteBuffer.flip();
//读完后,注册write就绪事件
sk.interestOps(SelectionKey.OP_WRITE);
//读完后,进入发送的状态
state = SENDING;
}
//处理结束了, 这里不能关闭select key,需要重复使用
//sk.cancel();
} catch (IOException ex)
{
ex.printStackTrace();
}
}
}
总结
1.反应器模式和生产者消费者模式对比
相似之处:在一定程度上,反应器模式有点类似生产者消费者模式。在生产者消费者模式中,一个或多个生产者将事件加入到一个队列中,一个或多个消费者主动地从这个队列中提取(Pull)事件来处理。
不同之处在于:反应器模式是基于查询的,没有专门的队列去缓冲存储IO事件,查询到IO事件之后,反应器会根据不同IO选择键(事件)将其分发给对应的Handler处理器来处理。
2.反应器模式和观察者模式(Observer Pattern)对比
相似之处在于:在反应器模式中,当查询到IO事件后,服务处理程序使用单路/多路分发(Dispatch)策略,同步地分发这些IO事件。观察者模式(ObserverPattern)也被称作发布/订阅模式,它定义了一种依赖关系,让多个观察者同时监听某一个主题(Topic)。这个主题对象在状态发生变化时,会通知所有观察者,它们能够执行相应的处理。
不同之处在于:在反应器模式中,Handler处理器实例和IO事件(选择键)的订阅关系,基本上是一个事件绑定到一个Handler处理器;每一个IO事件(选择键)被查询后,反应器会将事件分发给所绑定的Handler处理器;而在观察者模式中,同一个时刻,同一个主题可以被订阅过的多个观察者处理。
最后,总结一下反应器模式的优点和缺点。
作为高性能的IO模式,反应器模式的优点如下:
响应快,虽然同一反应器线程本身是同步的,但不会被单个连接的同步IO所阻塞;
编程相对简单,最大程度避免了复杂的多线程同步,也避免了多线程的各个进程之间切换的开销;· 可扩展,可以方便地通过增加反应器线程的个数来充分利用CPU资源。
反应器模式的缺点如下:
反应器模式增加了一定的复杂性,因而有一定的门槛,并且不易于调试。
反应器模式需要操作系统底层的IO多路复用的支持,如Linux中的epoll。如果操作系统的底层不支持IO多路复用,反应器模式不会有那么高效。
同一个Handler业务线程中,如果出现一个长时间的数据读写,会影响这个反应器中其他通道的IO处理。例如在大文件传输时,IO操作就会影响其他客户端(Client)的响应时间。因而对于这种操作,还需要进一步对反应器模式进行改进。