架构设计：系统间通信（5）——IO通信模型和JAVA实践 下篇
接上篇：《架构设计：系统间通信（4）——IO通信模型和JAVA实践 中篇》，我们继续讲解 异步IO
7、异步IO
上面两篇文章中，我们分别讲解了阻塞式同步IO、非阻塞式同步IO、多路复用IO 这三种IO模型，以及JAVA对于这三种IO模型的支持。重点说明了IO模型是由操作系统提供支持，且这三种IO模型都是同步IO，都是采用的“应用程序不询问我，我绝不会主动通知”的方式。
异步IO则是采用“订阅-通知”模式：即应用程序向操作系统注册IO监听，然后继续做自己的事情。当操作系统发生IO事件，并且准备好数据后，在主动通知应用程序，触发相应的函数：
和同步IO一样，异步IO也是由操作系统进行支持的。微软的windows系统提供了一种异步IO技术：IOCP（I/O Completion Port，I/O完成端口）；
Linux下由于没有这种异步IO技术，所以使用的是epoll（上文介绍过的一种多路复用IO技术的实现）对异步IO进行模拟。
8、JAVA的支持（JAVA AIO）
8-1、JAVA AIO框架简析
同样的犹如《架构设计：系统间通信（4）——IO通信模型和JAVA实践 中篇》中对JAVA NIO框架的实现分析，这里也没有将JAVA AIO框架所有的实现类画完，只是通过这个结构分析要告诉各位读者JAVA AIO中类设计和操作系统的相关性
在文中我们一再说明JAVA AIO框架在windows下使用windows IOCP技术，在Linux下使用epoll多路复用IO技术模拟异步IO，这个从JAVA AIO框架的部分类设计上就可以看出来。例如框架中，在Windows下负责实现套接字通道的具体类是“sun.nio.ch.WindowsAsynchronousSocketChannelImpl”，其引用的IOCP类型文档注释如是：
/**
* Windows implementation of AsynchronousChannelGroup encapsulating an I/O
* completion port.
*/
如果您感兴趣，当然可以去看看全部完整代码（建议从“java.nio.channels.spi.AsynchronousChannelProvider”这个类看起）。
- 特别说明一下，请注意图中的“java.nio.channels.NetworkChannel”接口，这个接口同样被JAVA NIO框架实现了，如下图所示：
8-2、代码实例
下面，我们通过一个代码示例，来讲解JAVA AIO框架的具体使用，先上代码，在针对代码编写和运行中的要点进行讲解：
package testASocket;import java.io.IOException;
import java.io.UnsupportedEncodingException;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.AsynchronousChannelGroup;
import java.nio.channels.AsynchronousServerSocketChannel;
import java.nio.channels.AsynchronousSocketChannel;
import java.nio.channels.CompletionHandler;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.log4j.BasicConfigurator;/*** JAVA AIO框架测试。请一定将* 《架构设计：系统间通信（4）——IO通信模型和JAVA实践 中篇》看了后再看本篇测试代码。* 这样对您理解代码的关键点非常有益。* @author yinwenjie*/
public class SocketServer {static {BasicConfigurator.configure();}private static final Object waitObject = new Object();/*** @param args* @throws Exception*/public static void main(String[] args) throws Exception {/** 对于使用的线程池技术，我一定要多说几句* 1、Executors是线程池生成工具，通过这个工具我们可以很轻松的生成“固定大小的线程池”、“调度池”、“可伸缩线程数量的池”。具体请看API Doc* 2、当然您也可以通过ThreadPoolExecutor直接生成池。* 3、这个线程池是用来得到操作系统的“IO事件通知”的，不是用来进行“得到IO数据后的业务处理的”。要进行后者的操作，您可以再使用一个池（最好不要混用）* 4、您也可以不使用线程池（不推荐），如果决定不使用线程池，直接AsynchronousServerSocketChannel.open()就行了。* */ExecutorService threadPool = Executors.newFixedThreadPool(20);AsynchronousChannelGroup group = AsynchronousChannelGroup.withThreadPool(threadPool);final AsynchronousServerSocketChannel serverSocket = AsynchronousServerSocketChannel.open(group);//设置要监听的端口“0.0.0.0”代表本机所有IP设备serverSocket.bind(new InetSocketAddress("0.0.0.0", 83));//为AsynchronousServerSocketChannel注册监听，注意只是为AsynchronousServerSocketChannel通道注册监听//并不包括为 随后客户端和服务器 socketchannel通道注册的监听serverSocket.accept(null, new ServerSocketChannelHandle(serverSocket));//等待，以便观察现象（这个和要讲解的原理本身没有任何关系，只是为了保证守护线程不会退出）synchronized(waitObject) {waitObject.wait();}}
}/*** 这个处理器类，专门用来响应 ServerSocketChannel 的事件。* 还记得我们在《架构设计：系统间通信（4）——IO通信模型和JAVA实践 中篇》中所提到的内容吗？ServerSocketChannel只有一种事件：接受客户端的连接* @author yinwenjie*/
class ServerSocketChannelHandle implements CompletionHandler<AsynchronousSocketChannel, Void> {/*** 日志*/private static final Log LOGGER = LogFactory.getLog(ServerSocketChannelHandle.class);private AsynchronousServerSocketChannel serverSocketChannel;/*** @param serverSocketChannel*/public ServerSocketChannelHandle(AsynchronousServerSocketChannel serverSocketChannel) {this.serverSocketChannel = serverSocketChannel;}/*** 注意，我们分别观察 this、socketChannel、attachment三个对象的id。* 来观察不同客户端连接到达时，这三个对象的变化，以说明ServerSocketChannelHandle的监听模式*/@Overridepublic void completed(AsynchronousSocketChannel socketChannel, Void attachment) {ServerSocketChannelHandle.LOGGER.info("completed(AsynchronousSocketChannel result, ByteBuffer attachment)");//每次都要重新注册监听（一次注册，一次响应），但是由于“文件状态标示符”是独享的，所以不需要担心有“漏掉的”事件this.serverSocketChannel.accept(attachment, this);//为这个新的socketChannel注册“read”事件，以便操作系统在收到数据并准备好后，主动通知应用程序//在这里，由于我们要将这个客户端多次传输的数据累加起来一起处理，所以我们将一个stringbuffer对象作为一个“附件”依附在这个channel上//ByteBuffer readBuffer = ByteBuffer.allocate(50);socketChannel.read(readBuffer, new StringBuffer(), new SocketChannelReadHandle(socketChannel , readBuffer));}/* (non-Javadoc)* @see java.nio.channels.CompletionHandler#failed(java.lang.Throwable, java.lang.Object)*/@Overridepublic void failed(Throwable exc, Void attachment) {ServerSocketChannelHandle.LOGGER.info("failed(Throwable exc, ByteBuffer attachment)");}
}/*** 负责对每一个socketChannel的数据获取事件进行监听。<p>* * 重要的说明：一个socketchannel都会有一个独立工作的SocketChannelReadHandle对象（CompletionHandler接口的实现），* 其中又都将独享一个“文件状态标示”对象FileDescriptor、* 一个独立的由程序员定义的Buffer缓存（这里我们使用的是ByteBuffer）、* 所以不用担心在服务器端会出现“窜对象”这种情况，因为JAVA AIO框架已经帮您组织好了。<p>* * 但是最重要的，用于生成channel的对象：AsynchronousChannelProvider是单例模式，无论在哪组socketchannel，* 对是一个对象引用（但这没关系，因为您不会直接操作这个AsynchronousChannelProvider对象）。* @author yinwenjie*/
class SocketChannelReadHandle implements CompletionHandler<Integer, StringBuffer> {/*** 日志*/private static final Log LOGGER = LogFactory.getLog(SocketChannelReadHandle.class);private AsynchronousSocketChannel socketChannel;/*** 专门用于进行这个通道数据缓存操作的ByteBuffer<br>* 当然，您也可以作为CompletionHandler的attachment形式传入。<br>* 这是，在这段示例代码中，attachment被我们用来记录所有传送过来的Stringbuffer了。*/private ByteBuffer byteBuffer;public SocketChannelReadHandle(AsynchronousSocketChannel socketChannel , ByteBuffer byteBuffer) {this.socketChannel = socketChannel;this.byteBuffer = byteBuffer;}/* (non-Javadoc)* @see java.nio.channels.CompletionHandler#completed(java.lang.Object, java.lang.Object)*/@Overridepublic void completed(Integer result, StringBuffer historyContext) {//如果条件成立，说明客户端主动终止了TCP套接字，这时服务端终止就可以了if(result == -1) {try {this.socketChannel.close();} catch (IOException e) {SocketChannelReadHandle.LOGGER.error(e);}return;}SocketChannelReadHandle.LOGGER.info("completed(Integer result, Void attachment) : 然后我们来取出通道中准备好的值");/** 实际上，由于我们从Integer result知道了本次channel从操作系统获取数据总长度* 所以实际上，我们不需要切换成“读模式”的，但是为了保证编码的规范性，还是建议进行切换。* * 另外，无论是JAVA AIO框架还是JAVA NIO框架，都会出现“buffer的总容量”小于“当前从操作系统获取到的总数据量”，* 但区别是，JAVA AIO框架中，我们不需要专门考虑处理这样的情况，因为JAVA AIO框架已经帮我们做了处理（做成了多次通知）* */this.byteBuffer.flip();byte[] contexts = new byte[1024];this.byteBuffer.get(contexts, 0, result);this.byteBuffer.clear();try {String nowContent = new String(contexts , 0 , result , "UTF-8");historyContext.append(nowContent);SocketChannelReadHandle.LOGGER.info("================目前的传输结果：" + historyContext);} catch (UnsupportedEncodingException e) {SocketChannelReadHandle.LOGGER.error(e);}//如果条件成立，说明还没有接收到“结束标记”if(historyContext.indexOf("over") == -1) {return;}//=========================================================================// 和上篇文章的代码相同，我们以“over”符号作为客户端完整信息的标记//=========================================================================SocketChannelReadHandle.LOGGER.info("=======收到完整信息，开始处理业务=========");historyContext = new StringBuffer();//还要继续监听（一次监听一次通知）this.socketChannel.read(this.byteBuffer, historyContext, this);}/* (non-Javadoc)* @see java.nio.channels.CompletionHandler#failed(java.lang.Throwable, java.lang.Object)*/@Overridepublic void failed(Throwable exc, StringBuffer historyContext) {SocketChannelReadHandle.LOGGER.info("=====发现客户端异常关闭，服务器将关闭TCP通道");try {this.socketChannel.close();} catch (IOException e) {SocketChannelReadHandle.LOGGER.error(e);}}
}8-2-1、要点讲解
注意在JAVA NIO框架中，我们说到了一个重要概念“selector”（选择器）。它负责代替应用查询中所有已注册的通道到操作系统中进行IO事件轮询、管理当前注册的通道集合，定位发生事件的通道等操操作；但是在JAVA AIO框架中，由于应用程序不是“轮询”方式，而是订阅-通知方式，所以不再需要“selector”（选择器）了，改由channel通道直接到操作系统注册监听。
JAVA AIO框架中，只实现了两种网络IO通道“AsynchronousServerSocketChannel”（服务器监听通道）、“AsynchronousSocketChannel”（socket套接字通道）。但是无论哪种通道他们都有独立的fileDescriptor（文件标识符）、attachment（附件，附件可以使任意对象，类似“通道上下文”），并被独立的SocketChannelReadHandle类实例引用。我们通过debug操作来看看它们的引用结构：
在测试过程中，我们启动了两个客户端（客户端用什么语言来写都行，用阻塞或者非阻塞方式也都行，只要是支持 TCP Socket套接字的就行。如果您非要看看客户端是怎么写的，您可以参见我的《架构设计：系统间通信（3）——IO通信模型和JAVA实践 上篇》这篇文章中的客户端代码示例），然后我们观察服务器端对这两个客户端通道的处理情况：
可以看到，在服务器端分别为客户端1和客户端2创建的两个WindowsAsynchronousSocketChannelImpl对象为：
客户端1：WindowsAsynchronousSocketChannelImpl：760 | FileDescriptor：762
客户端2：WindowsAsynchronousSocketChannelImpl：792 | FileDescriptor：797
接下来，我们让两个客户端发送信息到服务器端，并观察服务器端的处理情况。客户端1发来的消息和客户端2发来的消息，在服务器端的处理情况如下图所示：
客户端1：WindowsAsynchronousSocketChannelImpl：760 | FileDescriptor：762 | SocketChannelReadHandle：803 | HeapByteBuffer：808
客户端2：WindowsAsynchronousSocketChannelImpl：792 | FileDescriptor：797 | SocketChannelReadHandle：828 | HeapByteBuffer：833
可以明显看到，服务器端处理每一个客户端通道所使用的SocketChannelReadHandle（处理器）对象都是独立的，并且所引用的SocketChannel对象都是独立的。
- JAVA NIO和JAVA AIO框架，除了因为操作系统的实现不一样而去掉了Selector外，其他的重要概念都是存在的，例如上文中提到的Channel的概念，还有演示代码中使用的Buffer缓存方式。实际上JAVA NIO和JAVA AIO框架您可以看成是一套完整的“高并发IO处理”的实现。
8-2-2、还有改进可能
当然，以上代码是示例代码，目标是为了让您了解JAVA AIO框架的基本使用。所以它还有很多改造的空间，例如：
在生产环境下，我们需要记录这个通道上“用户的登录信息”。那么这个需求可以使用JAVA AIO中的“附件”功能进行实现。
我们在本文和上文（《架构设计：系统间通信（4）——IO通信模型和JAVA实践 中篇》）中，都是使用“自定义文本”格式传输内容，并检查“over”关键字。但是在正式生产环境下，您会这样用吗？
显然是不会的，因为它压缩率不高。要么我们会使用json格式：因为它在相同的压缩率的前提下，有更好的信息结构；我们还可以使用protobuffer：因为它兼顾传输效率和良好的信息结构；甚至还可以使用TLV格式：提供很好的信息传输效率（它连一个多余的byte描述都没有），这几种格式的讲解，您可以参考《架构设计：系统间通信（1）——概述从“聊天”开始上篇》。
记住JAVA AIO 和 JAVA NIO 框架都是要使用线程池的（当然您也可以不用），线程池的使用原则，一定是只有业务处理部分才使用，使用后马上结束线程的执行（还回线程池或者消灭它）。JAVA AIO框架中还有一个线程池，是拿给“通知处理器”使用的，这是因为JAVA AIO框架是基于“订阅-通知”模型的，“订阅”操作可以由主线程完成，但是您总不能要求在应用程序中并发的“通知”操作也在主线程上完成吧^_^。
最好的改进方式，当然就是使用Netty或者Mina咯。
8-3、为什么还有Netty
那么有的读者可能就会问，既然JAVA NIO / JAVA AIO已经实现了各主流操作系统的底层支持，那么为什么现在主流的JAVA NIO技术会是Netty和MINA呢？答案很简单：因为更好用，这里举几个方面的例子：
虽然JAVA NIO 和 JAVA AIO框架提供了 多路复用IO/异步IO的支持，但是并没有提供上层“信息格式”的良好封装。例如前两者并没有提供针对 Protocol Buffer、JSON这些信息格式的封装，但是Netty框架提供了这些数据格式封装（基于责任链模式的编码和解码功能）
要编写一个可靠的、易维护的、高性能的（注意它们的排序）NIO/AIO 服务器应用。除了框架本身要兼容实现各类操作系统的实现外。更重要的是它应该还要处理很多上层特有服务，例如：客户端的权限、还有上面提到的信息格式封装、简单的数据读取。这些Netty框架都提供了响应的支持。
JAVA NIO框架存在一个poll/epoll bug：Selector doesn’t block on Selector.select(timeout)，不能block意味着CPU的使用率会变成100%（这是底层JNI的问题，上层要处理这个异常实际上也好办）。当然这个bug只有在Linux内核上才能重现。
这个问题在JDK 1.7版本中还没有被完全解决：http://bugs.java.com/bugdatabase/view_bug.do?bug_id=2147719。虽然Netty 4.0中也是基于JAVA NIO框架进行封装的（上文中已经给出了Netty中NioServerSocketChannel类的介绍），但是Netty已经将这个bug进行了处理。
其他原因，用过Netty后，您就可以自己进行比较了。
9、后文预告
通过三篇文章，我们把操作系统的四种IO模型都进行了介绍，并且说明了JAVA对这四种IO模型的支持，也给出了代码讲解。有读者反映还是不够深入，例如典型的EPOLL技术的工作细节并没有讲解，也没有进行各种IO模型的性能比较，等等。别慌，我计划未来的3-4个月我们都会讨论“系统间通信技术”，所以就想做“负载均衡”那个系列的专栏一样，我们会在后面的时间进行补全。当然本人的技术水平有限，写博客的目的主要也是为了分享和总结，所以欢迎各位读者多多吐槽。
从下篇文章开始，我们将话一到两篇文章的内容，讨论Netty框架（以Netty4.0版本作为讨论基础）。随后我们将开始介绍JAVA 的RIM，并从RIM引导进入RPC技术的介绍。
架构设计：系统间通信（5）——IO通信模型和JAVA实践 下篇相关推荐
- 架构设计：系统间通信（4）——IO通信模型和JAVA实践 中篇
接上篇<架构设计:系统间通信(3)--IO通信模型和JAVA实践 上篇> 4.多路复用IO模型 在"上篇"文章中,我们已经提到了使用多线程解决高并发场景的问题所在,这篇 ...
- 走向.NET架构设计—第五章—业务层模式，原则，实践（中篇）
走向.NET架构设计-第五章-业务层模式,原则,实践(中篇) 前言:设计模式并不是什么很高深的东西,至少不是那么"神乎其神".说到底,设计模式就是一些设计思想.下面我们就走进项目, ...
- 走向.NET架构设计—第五章—业务层模式，原则，实践（后篇）
走向.NET架构设计-第五章-业务层模式,原则,实践(后篇) 前言:在上一篇文章中,讲述了一些设计模式的使用,本篇首先接着介绍还没有讲完的一些设计模式,然后再讲述一些架构模式中的超类模式,作为本篇的结 ...
- 【计组笔记03】计算机组成原理之系统五大部件介绍、主存模型和CPU结构介绍
这篇文章,主要介绍计算机组成原理之系统五大部件.主存模型和CPU结构. 目录 一.计算机五大部件 1.1.体系结构 (1)冯诺依曼体系结构
- 系统架构设计 - 系统安全性和保密性设计
一.安全性和保密性设计 计算机及信息技术的应用领域在不断扩展,计算机在政府.企业.民生等各个领域中都得到越来越广泛的应用.与此同时,网络攻击和入侵事件与日俱增,重要机构的信息系统遭黑客袭击的事件时有发 ...
- 系统架构设计-系统的可靠性分析与设计
一.可靠性概述 与可靠性相关的概念主要有:可靠度.可用度.可维度.平均无故障时间.平均故障修复时间及平均故障间隔时间等. 可靠性和可用性 二.可靠性指标 三.串联系统与并联系统可靠性计算 四.可靠性设 ...
- 架构设计：系统间通信（10）——RPC的基本概念
1.概述 经过了详细的信息格式.网络IO模型的讲解,并且通过JAVA RMI的讲解进行了预热.从这篇文章开始我们将进入这个系列博文的另一个重点知识体系的讲解:RPC.在后续的几篇文章中,我们首先讲解R ...
- 商品详情页动态渲染系统：大型网站的多机房4级缓存架构设计
124_大型电商网站的商品详情页的深入分析 之前,咱们也是说在讲解这个商品详情页系统的架构 缓存架构,高可用服务 商品详情页系统,我们只是抽取了其中一部分来讲解,而且还做了很大程度的简化 主要是为了用 ...
- 基于大数据的情报分析与服务系统架构设计
一.大数据在军事领域中的应用 技术作为一项从大量数据中获取有用知识的实用技术,已被广泛应用于各行各业并取得了较大的经济和社会效益,而其在军事领域的应用也具有很大的潜力. 1 提升情报获取能力 现代战 ...
最新文章
- android4.0浏览器在eclipse中编译的步骤
- 关于时间差查询的一个小技巧
- 软件缘-网友个人精心打造的精品软件收集
- 使用Spring Boot 2.0的Spring Security：保护端点
- mysqld和mysql区别_mysqld与mysqld_safe的区别
- 【读史笔记】《晋书·卫玠列传》
- 2022李宏毅机器学习hw2
- java电商三级地址_Java电商项目面试--收货地址模块
- 技术状态管理（四）-技术状态控制
- c语言换行用分号代替,go语言换行的地方可以用分号替代吗?
- 怎样才能成为一名有创造力的领导者？
- spring核心技术之Resource资源理解
- 注册一个北京公司可以申请办理京牌吗，好申请吗？
- 三个臭皮匠赛过诸葛亮！白话Blending和Bagging
- 【云驻共创】初探数通网络开放可编程
- iOS UILable换行相关设置
- 一文看懂“摩根系”，摩根士丹利、摩根大通、大摩、小摩到底有什么关系？
- Servlet的生命周期,及Servlet和CGI的区别
- 碰撞体速度过快穿透的问题
- 算法基础——蓝桥杯（python实现，实际上大多数用c++更明白易懂）（第一部分，共12个小题）