java IO模型

最新推荐文章于 2024-04-07 11:13:57 发布

Coding-lover

最新推荐文章于 2024-04-07 11:13:57 发布

阅读量817

点赞数

分类专栏： java 通信

java 通信专栏收录该内容

37 篇文章 0 订阅

订阅专栏

一、 IO模型

所谓IO，就是计算机的输入输出系统，大多IO都会和硬件打交道，比如内存、硬盘、光驱等。由于要操作硬件，IO一般都比较耗时，所以操作系统都支持同步和异步两种IO方式，同步IO就是要等到操作完成才继续执行，而异步IO不需要等待。异步IO在各操作系统上的实现方式也不太一样，以下列举出windows和linux操作系统上的异步IO模型。

1、Windows

Ø 选择（Select）

Ø 异步选择（Async Select）

Ø 事件选择（Event Select）

Ø 重叠IO（Overlapped IO）

Ø 完成端口（Completion Port）

2、Linux

Ø 非阻塞I/O

Ø I/O复用（select和poll）

Ø 信号驱动I/O（SIGIO）

Ø 异步I/O（Posix.1的aio_系列函数）

Ø 增强版复用IO（epoll）（参考：http://blog.csdn.net/ljx0305/article/details/4065058）

Windows IO模型请参考：http://blog.pfan.cn/article.asp?id=51699

Linux IO模型请参考：http://blog.csdn.net/z3410218746/article/details/7563379

其中Windows的IOCP和linux的epoll被广泛用于高容量、大并发服务器。

同步IO和异步IO的使用场景：

同步IO一般用于对性能、并发量要求不是太高的场景，主要是客户端，比如一个社交应用需要读写文件，这时候就没有必要使用异步IO。

异步IO大多用于服务器端，因为服务器端要处理很大容量的数据以及保持很高的并发量。

二、 Javaio模型

1、OIO

OIO就是同步IO

2、NIO

在JDK 1.4版本之后才开始支持异步IO，其实NIO也是使用操作系统的IO模型，但在各操作系统上的实现方式也不太一样

在Windows系统使用的是Select模型，而不是性能更高的IOCP，原因就是并非所有Windows都支持IOCP，IOCP在windows NT 3.5中被引入，只支持WindowsNT和windows 2000。（参考：http://www.cnblogs.com/jobs/archive/2006/11/22/568023.html）

在Linux系统上使用的是多路复用IO，JDK 6之前用的是poll模型，JDK 7中使用epoll。（参考：http://www.cnblogs.com/jobs/archive/2006/11/22/568022.html）

3、AIO

JDK 7中出现了AIO，其实AIO就是NIO的增强版，因为JDK 6之前用的是poll，JDK 7用的是epoll，而epoll就是poll的增强版。

NIO三大概念：

1、Buffer

用于管理缓冲区，发送和接收都要使用Buffer

2、Channel

封装了各种IO，主要有FileChannel、SocketChannel、ServerSocketChannel等，并提供异步操作的方法

3、Selector

用于检索哪些Channel有事件发生，一共定义了四种事件，分别是accept、connect、read、write。

Java NIO的详细用法请参考：http://blog.csdn.net/geli_hero?viewmode=contents

AIO：

其实NIO和AIO的区别就是poll和epoll的区别。

poll和epoll的区别：（参考：http://blog.csdn.net/xuexi1028/article/details/7631567）

poll需要主动轮询描述符来探测事件，而epoll模型会主动上报事件。

AIO为每个Channel增加了对应的Asynchronous…Channel,这些Channel的操作都增加了一个回调，当此操作成功时就会调用回调。

下面说下nio和aio的流程（以接收数据为例）：

Nio：

Ø 注册事件（channel.register(selector)）

Ø 轮询事件(selector.select())

Ø 获得事件(selectKeys)

Ø 读取数据(channel.read(byteBuffer))

Aio：

Ø 创建线程池（AsynchronousChannelGroup）

Ø 绑定到线程池（async…Channel.open(group)）

Ø 读取操作并绑定事件（read(buf,readCompletedHandler)）

Ø 对应端口接收到数据，系统主动把数据放到buf里，然后放到完成列表

Ø 线程池从完成列表里取出，并触发回调。

底层的区别：

1、获取事件的方式不同

主要体现在Epoll和poll之间的区别

poll要通过select操作来取出事件，系统层面的流程如下：

Ø 注册描述符

Ø 端口产生数据

Ø 修改描述符

Ø 应用程序线程通过select查找有事件的描述符

而epool比poll多出一个描述符列表，流程如下:

Ø 注册描述符

Ø 端口产生事件

Ø 把此描述符放到已完成列表里

Ø 应用程序线程从已完成列表里取出事件

Poll要从一个很大的列表里查找出所有有事件的描述符，是比较耗时的，而epoll直接去已完成的列表里去拿就行了

Windows的IOCP可以注册多个端口（已完成描述符列表），系统会把事件放到其中一个端口上，设计上一般线程池里的每个线程都检测一个对应的端口

Epoll是否项IOCP一样可以创建多个端口?这个问题还没查到，以后有时间再查

2、读取数据的方式不同

Poll事件产生之后，其实数据还在对应的端口上，需要程序去再到这个端口上拿数据。

而epoll就不需要，因为系统已经把数据附加到事件上，并放到了已完成描述符列表里，程序拿到事件的时候就已经拿到了数据

应用上的区别：

由于底层的区别造成了应用层面上的设计也是不一样的，NIO一般采用Reactor模式，AIO使用Proactor模式。

关于这两种模式的详解和区别请参考: http://www.cnblogs.com/dawen/archive/2011/05/18/2050358.html

Reactor模式（参考：http://www.oschina.net/question/16_9863）：

1、单线程

2、多线程

3、主Reactor加子Reactor

Proactor模式（下面几张图片用于描述这种模式，详细请参考:http://www.61ic.com/Technology/Communicate/200811/21669.html）：

三、开源服务器框架

一直以来，IO是服务器端程序的最大瓶颈，选择合适的IO模型会大大提高服务器的性能，之前很多Web服务器采用的是同步IO，Java开发者也大都习惯于同步IO，如今很多Web服务器开始支持异步IO，比如Tomca 6，Resin 3，还有些开源框架，如netty，mina。

注：Tomca使用的是java的NIO，而Resin使用的是JNI调用本地代码（参考：http://bbs.linuxtone.org/thread-1484-1-1.html）

开源框架Netty和Mina。

首先看一下Netty和Mina的简单介绍：

Netty和Mina都是Socket通信框架，它们都采用开性能的IO模型，并简化了通信程序的开发工作。

Ø mina比netty出现的早，都是Trustin Lee的作品；、

Ø mina将内核和一些特性的联系过于紧密，使得用户在不需要这些特性的时候无法脱离，相比下性能会有所下降；netty解决了这个设计问题；

Ø netty的文档更清晰，很多mina的特性在netty里都有；

Ø netty更新周期更短，新版本的发布比较快；

Ø 它们的架构差别不大，mina靠apache生存，而netty靠jboss，和jboss的结合度非常高，netty有对google protocal buf的支持，有更完整的ioc容器支持(spring,guice,jbossmc和osgi)；

Ø netty比mina使用起来更简单，netty里你可以自定义的处理upstream events 或/和 downstream events，可以使用decoder和encoder来解码和编码发送内容；

Ø netty和mina在处理UDP时有一些不同，netty将UDP无连接的特性暴露出来；而mina对UDP进行了高级层次的抽象，可以把UDP当成"面向连接"的协议，而要netty做到这一点比较困难。

由于Netty比Mina更优秀，这里我们主要学习下Netty。

Netty的实现原理

Netty有几个概念：

1、Buffer

Netty的ByteBuffer是在Java NIO的Buffer基础上做了一些封装，主要是便于使用，在netty-buffer包里。下面是几个比较重要的Buffer：

a) HeapChannelBuffer

这是Netty读网络数据时默认使用的ChannelBuffer，这里的Heap就是Java堆的意思，因为读SocketChannel的数据是要经过ByteBuffer的，而ByteBuffer实际操作的就是个byte数组，所以 ChannelBuffer的内部就包含了一个byte数组，使得ByteBuffer和ChannelBuffer之间的转换是零拷贝方式。根据网络字节续的不同，HeapChannelBuffer又分为BigEndianHeapChannelBuffer和 LittleEndianHeapChannelBuffer，默认使用的是BigEndianHeapChannelBuffer。Netty在读网络数据时使用的就是HeapChannelBuffer，HeapChannelBuffer是个大小固定的buffer，为了不至于分配的Buffer的大小不太合适，Netty在分配Buffer时会参考上次请求需要的大小。

b) DynamicChannelBuffer

相比于HeapChannelBuffer，DynamicChannelBuffer可动态自适应大小。对于在DecodeHandler中的写数据操作，在数据大小未知的情况下，通常使用DynamicChannelBuffer。

c) ByteBufferBackedChannelBuffer

这是directBuffer，直接封装了ByteBuffer的 directBuffer。对于读写网络数据的buffer，分配策略有两种：1）通常出于简单考虑，直接分配固定大小的buffer，缺点是，对一些应用来说这个大小限制有时是不合理的，并且如果buffer的上限很大也会有内存上的浪费。2）针对固定大小的buffer缺点，就引入动态buffer，动态buffer之于固定 buffer相当于List之于Array。

2、ChannelBuf

ChannelBuf是对ChannelPipeline上数据的描述，一共有两种类型的ChannelBuf，分别是：

ByteBuf：里面的数据是二进制Buffer，一般刚从socket读出来或刚要写进去时的数据都是ByteBuf，也就是ChannelPipeline上第一个写Handler和第一个读Handler接收到的数据都是ByteBuf

MessageBuf：里面的数据是Java对象，可以是任意的数据

3、Channel

Netty的Channel也是对Java NIO的Channel的扩展，在包netty-transport里面。

这里的Channel不提供直接的操作，可以通过Channel获取当前的状态，也可以获取ChannelPipeline，主要的操作都封装在ChannelPipeline里面。

Netty分别封装了OIO、NIO、AIO的Channel，只需修改一下配置就可以使用不同的IO模型。

4、ChannelPipeline

ChannelPipeline就类似一个生产线，如下图所示：

 *                                      I/O Request
 *                                    via {@link Channel} or
 *                                {@link ChannelHandlerContext}
 *                                          |
 * +----------------------------------------+---------------+
 * |                 ChannelPipeline      |              |
 * |                                      \|/             |
 * |  +----------------------+  +-----------+------------+ |
 * |  | Upstream Handler  N  |  | Downstream Handler 1  |  |
 * |  +----------+-----------+ +-----------+------------+ |
 * |           /|\                        |              |
 * |            |                        \|/             |
 * |  +----------+-----------+ +-----------+------------+ |
 * |  | Upstream Handler N-1 |  |Downstream Handler  2  |  |
 * |  +----------+-----------+ +-----------+------------+ |
 * |           /|\                        .              |
 * |            .                         .              |
 * |     [ sendUpstream()]        [ sendDownstream()]     |
 * |     [ + VAL_INBOUND data]        [ + VAL_OUTBOUND data ]     |
 * |            .                         .              |
 * |            .                        \|/             |
 * |  +----------+-----------+ +-----------+------------+ |
 * |  | Upstream Handler  2  |  | Downstream Handler M-1|  |
 * |  +----------+-----------+ +-----------+------------+ |
 * |           /|\                        |              |
 * |            |                        \|/             |
 * |  +----------+-----------+ +-----------+------------+ |
 * |  | Upstream Handler  1  |  | Downstream Handler M  |  |
 * |  +----------+-----------+ +-----------+------------+ |
 * |           /|\                        |              |
 * +-------------+--------------------------+---------------+
 *               |                        \|/
 * +-------------+--------------------------+---------------+
 * |            |                         |              |
 * |     [ Socket.read()]          [ Socket.write()]      |
 * |                                                       |
 * |  Netty Internal I/O Threads (Transport Implementation) |
 * +--------------------------------------------------------+

发送的时候，数据经过一系列的处理最终有socket发送出去，接收的时候socket拿到数据然后经过一些列的处理交给业务处理层。就像生产线上有很多工人，每个工人负责的具体工作也不一样，有负责解包的，有负责解析协议的等等，这些在Netty里都是Handler完成。

一个ChannelPipeline里可以注册多个Handler，并且提供了一系列管理Handler的方法，每个Handler处理完成自己的工作之后再交给下一个Channel。

ChannelPipeline还提供获取生产线上当前的数据的方法：

Ø inboundMessageBuffer和inboundByteBuffer：读取的数据

Ø outboundMessageBuffer和outboundByteBuffer：写入的数据

5、ChannelHandlerContext

表示ChannelPipeline上当前上下文环境

Ø channel()：获取当前的Channel

Ø pipeline()：获取当前管道

Ø executor()：获取当前的处理器（线程池里正在运行的线程）

Ø handler()

Ø types()

Ø hasInboundByteBuffer()：是否ChannelPipeline中有读取的数据

Ø hasInboundMessageBuffer()

Ø inboundByteBuffer()

Ø inboundMessageBuffer()

Ø hasOutboundByteBuffer()：获取ChannelPipeline中是否有写入的数据

Ø hasOutboundMessageBuffer()

Ø outboundByteBuffer()

Ø outboundMessageBuffer()

Ø hasNextInboundByteBuffer()

Ø hasNextInboundMessageBuffer()

Ø nextInboundByteBuffer()

Ø nextInboundMessageBuffer()

Ø hasNextOutboundByteBuffer()

Ø hasNextOutboundMessageBuffer()

Ø nextOutboundByteBuffer()

Ø nextOutboundMessageBuffer()

Ø isReadable()

Ø readable(boolean readable)

Ø DefaultChannelHandlerContext. Bind

Ø DefaultChannelHandlerContext. Connect

Ø DefaultChannelHandlerContext disconnect

Ø DefaultChannelHandlerContext.close

Ø DefaultChannelHandlerContext. Deregister

Ø DefaultChannelHandlerContext. Flush

Ø DefaultChannelHandlerContext. Write：写入数据

Handler的每个事件触发都会包含这个参数

6、Handler

Handler是ChannelPipeline上处理器，一共定义了四种类型的Handler，分别是：

STATE：状态

INBOUND：处理读取数据

OPERATION：操作

OUTBOUND：处理写入数据

基类是ChannelHandler，它定义了几个基本的事件，分别是：

Ø beforeAdd

Ø afterAdd

Ø beforeRemove

Ø afterRemove

Ø exceptionCaught：当有异常时触发

Ø userEventTriggered：用于触发用户注册的事件（如SctpNotificationEvent、ChannelInputShutdownEvent）

ChannelStateHandler集成自ChannelHandler，定义了一些状态事件：

Ø channelRegistered

Ø channelUnregistered

Ø channelActive

Ø channelInactive

Ø inboundBufferUpdated：ChannelPipeline上的数据发生变化时触发，一般由这个事件触发下个Handler处理数据

ChannelInboundHandler集成自ChannelStateHandler

Ø ChannelInboundByteHandler.newInboundBuffer：创建新的读取Buf（二进制）

Ø ChannelInBoundMessageHandler.newInboundBuffer:创建新的读取Buf（Java对象）

ChannelOperationHandler继承自ChannelHandler

Ø Bind：绑定到端口

Ø Connect：连接到远程服务器

Ø Disconnect：断开连接

Ø Close：关闭Channel

Ø Deregister：取消监听

Ø Flush：刷新流使其马上发送出去

ChannelOutboundHandler继承自ChannelOperationHandler

Ø ChannelOutboundByteHandler.newOutboundBuffer：创建新的写入Buf（二进制）

Ø ChannelOutboundMessageHandler.newOutboundBuffer：创建新的写入Buf（Java对象）

以上这些类也都定义对应的Adapter，用于实现对应的功能，主要是ChannelInboundHandlerAdapter：

Ø ChannelInboundByteHandlerAdapter.inboundBufferUpdated：接收到Byte类型Buf

Ø ChannelInboundMessageHandlerAdapter.messageReceived：接收到Message类型的Buf

以上都是Handler的基本类型，在实际应用都会扩展这些Handler，一般都会以下几种Handler

Ø decodeFrameHandler：用于解包（TCP协议会产生粘包、半包的问题）

Ø decodeHandler：用于根据协议解析数据包

Ø encodeHandler：用于封包（把数据按照协议封装成二进制数据包）

Ø executorHandler：用于处理协议

Ø businessHandler：根据不同的协议产生不同的业务逻辑

netty-codec封装了常用的decodeFrameHandler、decodeHandler、encodeHandler，另外还有加密解密的Handler（JZlibDecodeHandler、JZlibEncodeHandler、ZLibDecodeHandler、ZLibEncodeHandler），还有序列化等。

netty-http封装了http协议的一些解析方法

重点说下几个常用的解包Handler：

a) FixedLengthFrameDecoder

适用于每个数据的大小固定的协议，比如：

 * +---+----+------+----+
 * | A | BC | DEFG | HI |
 * +---+----+------+----+
 如果一个数据包的大小为3字节，则上面的数据经过解包分为下面3个数据包
 * +-----+-----+-----+
 * | ABC | DEF | GHI |
 * +-----+-----+-----+

这个稍微负责一些，这种协议要求有协议头，协议头里有个字段表示后面数据的长度b) LengthFieldBasedFrameDecoder

 * BEFORE DECODE (16 bytes)                       AFTER DECODE (13 bytes)
 * +------+--------+------+----------------+      +------+----------------+
 * | HDR1 | Length | HDR2 | Actual Content |----->| HDR2 | Actual Content |
 * | 0xCA | 0x0010 | 0xFE | "HELLO, WORLD" |      | 0xFE | "HELLO, WORLD" |
 * +------+--------+------+----------------+      +------+----------------+

这个比较好理解，协议里面有一个固定的数据作为结尾，DelimiterBasedFrameDecoder就以这个固定的分隔符来拆分数据包。c) DelimiterBasedFrameDecoder

7、EventLoopGroup

EventLoopGroup就是线程池，整个程序都要依赖于线程池工作。

8、Bootstrap

Bootstrap是一个程序的入口，我们看一下它的定义：

Ø group（EventLoopGroup）:绑定到线程池

Ø channel（Channel）：指定Channel的类型

Ø channelFactory（ChannelFactory）：指定ChannelFactory

Ø localAddress（host，port）：配置本地端口

Ø option（ChannelOption）

Ø attr（AttributeKey）

Ø shutdown（）：停止服务

Ø bind（）

Ø handler（channelHandler）

Ø client.remoteAddress（host，port）：配置远程端口

Ø client.connect()：连接到远程服务器

Ø server. childOption(ChannelOption)

Ø server. childHandler

Ø server. Bind()

Ø server.group(EventLoopGroup):绑定到线程池

Ø server.group(EventLoopGroup,EventLoopGroup)

Bootstrap用于client端，ServerBootstrap用于服务端

在Java IO模型里面我们讲到了两种设计模式，Reactor和Proactor，在这里就体现出了Netty如何使用Reactor模式。

其实EventLoopGroup就相当于Reactor，Bootstrap.group方法就是要创建Reactor模式，在client端只能创建单Reactor模式，在server端可以创建mainReactor加childReactor

一个简单的server端程序：

public class Server {
    public static void main(String[] args) {
       ServerBootstrap bootstrap = new ServerBootstrap();
       bootstrap.group(new NioEventLoopGroup(1), new NioEventLoopGroup())
              .channel(NioServerSocketChannel.class).localAddress(9001)
              .childHandler(new ChannelInitializer<SocketChannel>() {
                  @Override
                  public void initChannel(SocketChannel ch) throws Exception {
                     ChannelPipeline pipeline = ch.pipeline();
                     pipeline.addLast(
                            "1",
                            new DelimiterBasedFrameDecoder(
                                   Integer.MAX_VALUE, new HeapByteBuf("\n"
                                          .getBytes(), 1)) {
                                @Override
                                public void inboundBufferUpdated(
                                       ChannelHandlerContext ctx)
                                       throws Exception {
                                   super.inboundBufferUpdated(ctx);
                                }
                            });
                     pipeline.addLast("2", new StringDecoder() {
                         @Override
                         public String decode(ChannelHandlerContext ctx,
                                ByteBuf msg) throws Exception {
                            return super.decode(ctx, msg);
                         }
                     });
                     pipeline.addLast(
                            "3",
                            new ChannelInboundMessageHandlerAdapter<Object>(
                                   Object.class, ByteBuf.class) {
                               
                                @Override
                                public void messageReceived(
                                       ChannelHandlerContext ctx,
                                       Object msg) throws Exception {
                                   if (ChannelHandlerUtil.unfoldAndAdd(
                                          ctx, msg, true)) {
                                       ctx.fireInboundBufferUpdated();
                                   }
                                }
                            });
                     pipeline.addLast("4",new ChannelInboundMessageHandlerAdapter<String>(Object.class) {
 
                         @Override
                         public void messageReceived(
                                ChannelHandlerContext ctx, String msg)
                                throws Exception {
                            ByteBuf buf = Unpooled.copiedBuffer(msg, Charset.defaultCharset());
                            if (ChannelHandlerUtil.unfoldAndAdd(
                                   ctx, buf, true)) {
                                ctx.fireInboundBufferUpdated();
                            }
                         }
                     });
                     pipeline.addLast("handler",
                            new ChannelInboundByteHandlerAdapter() {
 
                                @Override
                                public void inboundBufferUpdated(
                                       ChannelHandlerContext ctx,
                                       ByteBuf in) throws Exception {
                                   String msg = in.toString(Charset
                                          .defaultCharset());
                                   System.out.println(msg);
 
                                }
                            });
                  }
              });
       bootstrap.bind();
    }
}

由于时间有限，没有更深入的了解其架构，但是我觉得大致的结构和原理基本上清楚了，另外，netty版本更新比较快，网上很多文章说的是早起版本，现在结构上有了很大变化，请下载最新的源代码Netty官方网站： https://netty.io/

转载自：http://blog.csdn.net/shanpengfei77/article/details/8161077

Coding-lover

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
java IO模型

一、 IO模型所谓IO，就是计算机的输入输出系统，大多IO都会和硬件打交道，比如内存、硬盘、光驱等。由于要操作硬件，IO一般都比较耗时，所以操作系统都支持同步和异步两种IO方式，同步IO就是要等到操作完成才继续执行，而异步IO不需要等待。异步IO在各操作系统上的实现方式也不太一样，以下列举出windows和linux操作系统上的异步IO模型。1、Windows
复制链接

扫一扫

专栏目录