此网站为PM小曹的博客网站,致力于分享项目管理、技术干货、职场心得,欢迎关注交流!
当前位置:PM小曹社区 > 技术干货 > 正文

Java 网络IO编程总结(BIO、NIO、AIO)

07-03 技术干货 【作者:PM小曹】

1,BIO编程

1.1、传统的BIO编程

     网络编程的基本模型是C/S模型,即两个进程间的通信
    服务端提供IP和监听端口,客户端通过连接操作想服务端监听的地址发起连接请求,通过三次握手连接,
如果连接成功建立,双方就可以通过套接字进行通信。
    传统的同步阻塞模型开发中,ServerSocket负责绑定IP地址,启动监听端口;Socket负责发起连接操作。
连接成功后,双方通过输入和输出流进行同步阻塞式通信。 
    简单的描述一下BIO的服务端通信模型:采用BIO通信模型的服务端,通常由一个独立的Acceptor线程
负责监听客户端的连接,它接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理没
处理完成后,通过输出流返回应答给客户端,线程销毁。即典型的一请求一应答通信模型。


传统BIO通信模型图:
01
      该模型最大的问题就是缺乏弹性伸缩能力,当客户端并发访问量增加后,服务端的线程个数和客户端
并发访问数呈1:1的正比关系,Java中的线程也是比较宝贵的系统资源,线程数量快速膨胀后,系统的
性能将急剧下降,随着访问量的继续增大,系统最终就死-掉-了。

 

    1.2、伪异步I/O编程

    为了改进这种一连接一线程的模型,我们可以使用线程池来管理这些线程,实现1个或多个线程处理N个
客户端的模型(但是底层还是使用的同步阻塞I/O),通常被称为“伪异步I/O模型“。
    伪异步I/O模型图:


       我们知道,如果使用CachedThreadPool线程池(不限制线程数量,如果不清楚请参考文首提供的文章),
其实除了能自动帮我们管理线程(复用),看起来也就像是1:1的客户端:线程数模型,而使用FixedThreadPool
我们就有效的控制了线程的最大数量,保证了系统有限的资源的控制,实现了N:M的伪异步I/O模型。
       但是,正因为限制了线程数量,如果发生大量并发请求,超过最大数量的线程就只能等待,直到线程池中的有空闲的线程可以被复用。
而对Socket的输入流按行读取时,会一直阻塞,直到发生:

  •     无数据可读
  •     可用数据以及读取完毕
  •     发生空指针或I/O异常

    所以在读取数据较慢时(比如数据量大、网络传输慢等),大量并发的情况下,其他接入的消息,只能一直等待,这就是最大的弊端。
    而后面即将介绍的NIO,就能解决这个难题。

2、NIO 编程

     JDK 1.4中的java.nio.*包中引入新的Java I/O库,其目的是提高速度。实际上,“旧”的I/O包已经使用NIO重新实现过,即使我们不显式的
使用NIO编程,也能从中受益。速度的提高在文件I/O和网络I/O中都可能会发生,但本文只讨论后者。

2.1、简介

    NIO我们一般认为是New I/O(也是官方的叫法),因为它是相对于老的I/O类库新增的(其实在JDK 1.4中就已经被引入了,但这个名词
还会继续用很久,即使它们在现在看来已经是“旧”的了,所以也提示我们在命名时,需要好好考虑),做了很大的改变。但民间跟多人称之
为Non-block I/O,即非阻塞I/O,因为这样叫,更能体现它的特点。而下文中的NIO,不是指整个新的I/O库,而是非阻塞I/O。
    NIO提供了与传统BIO模型中的Socket和ServerSocket相对应的SocketChannel和ServerSocketChannel两种不同的套接字通道实现。
    新增的着两种通道都支持阻塞和非阻塞两种模式。
    阻塞模式使用就像传统中的支持一样,比较简单,但是性能和可靠性都不好;非阻塞模式正好与之相反。
    对于低负载、低并发的应用程序,可以使用同步阻塞I/O来提升开发速率和更好的维护性;对于高负载、高并发的(网络)应用,应使
用NIO的非阻塞模式来开发。
    下面会先对基础知识进行介绍。

2.2、缓冲区 Buffer


    Buffer是一个对象,包含一些要写入或者读出的数据。
    在NIO库中,所有数据都是用缓冲区处理的。在读取数据时,它是直接读到缓冲区中的;在写入数据时,也是写入到缓冲区中。
任何时候访问NIO中的数据,都是通过缓冲区进行操作。
    缓冲区实际上是一个数组,并提供了对数据结构化访问以及维护读写位置等信息。
    具体的缓存区有这些:ByteBuffe、CharBuffer、 ShortBuffer、IntBuffer、LongBuffer、FloatBuffer、DoubleBuffer。
他们实现了相同的接口:Buffer。

 2.3、通道 Channel


    我们对数据的读取和写入要通过Channel,它就像水管一样,是一个通道。通道不同于流的地方就是通道是双向的,
可以用于读、写和同时读写操作。
    底层的操作系统的通道一般都是全双工的,所以全双工的Channel比流能更好的映射底层操作系统的API。
    Channel主要分两大类:

  •     SelectableChannel:用户网络读写
  •     FileChannel:用于文件操作

 2.4、多路复用器 Selector

    Selector是Java  NIO 编程的基础。
    Selector提供选择已经就绪的任务的能力:Selector会不断轮询注册在其上的Channel,如果某个Channel上面发生读或者写事件,
这个Channel就处于就绪状态,会被Selector轮询出来,然后通过SelectionKey可以获取就绪Channel的集合,进行后续的I/O操作。
    一个Selector可以同时轮询多个Channel,因为JDK使用了epoll()代替传统的select实现,所以没有最大连接句柄1024/2048的限制。
所以,只需要一个线程负责Selector的轮询,就可以接入成千上万的客户端。
可以看到,创建NIO服务端的主要步骤如下:

  1.     打开ServerSocketChannel,监听客户端连接
  2.     绑定监听端口,设置连接为非阻塞模式
  3.     创建Reactor线程,创建多路复用器并启动线程
  4.     将ServerSocketChannel注册到Reactor线程中的Selector上,监听ACCEPT事件
  5.     Selector轮询准备就绪的key
  6.     Selector监听到新的客户端接入,处理新的接入请求,完成TCP三次握手,简历物理链路
  7.     设置客户端链路为非阻塞模式
  8.     将新接入的客户端连接注册到Reactor线程的Selector上,监听读操作,读取客户端发送的网络消息
  9.     异步读取客户端消息到缓冲区
  10.     对Buffer编解码,处理半包消息,将解码成功的消息封装成Task
  11.     将应答消息编码为Buffer,调用SocketChannel的write将消息异步发送给客户端

    因为应答消息的发送,SocketChannel也是异步非阻塞的,所以不能保证一次能吧需要发送的数据发送完,此时就会出现写半包的问题。
我们需要注册写操作,不断轮询Selector将没有发送完的消息发送完毕,然后通过Buffer的hasRemain()方法判断消息是否发送完成。

3、AIO编程

    NIO 2.0引入了新的异步通道的概念,并提供了异步文件通道和异步套接字通道的实现。
   异步的套接字通道时真正的异步非阻塞I/O,对应于UNIX网络编程中的事件驱动I/O(AIO)。他不需要过多的Selector对注册的通道进行
 轮询即可实现异步读写,从而简化了NIO的编程模型。

使用的类: 
1.ServerSocketChannel类:ServerSocket的代替类,支持非阻塞通信; 
2.SocketChannel类:Socket的代替类,支持非阻塞通信; 
3.Selector:为ServerSocketChannel监控接收连接就绪事件,为SocketChannel监控连接就绪,读就绪和写就绪事件。 
4.SelectionKey:代表ServerSocketChannel和SocketChannel向Selector注册事件的句柄。
 
基本思路: 
服务器端: 
1.使用ServerSocketChannel类对地址端口号进行绑定,通过open()方法获取通道,并且设置为非阻塞; 
2.通过Selector的open()方法,创建Selector对象; 
3.进行注册连接就绪事件; 
3.通过Selector的select()方法返回注册事件的数目,返回对象为SelectionKey,对SelectionKey进行遍历,当监听到连接事件的时候,就使用accept()连接并返回一个SocketChannel对象,对它注册读就绪事件; 
4.收到消息之后进行反馈; 
客户端: 
1.通过IP和端口号进行连接; 
2.通过Selector的open()方法创建该类对象; 
3.进行注册读事件监听,读取服务器端的反馈; 
4.输出消息;

4、各种I/O的对比

    先以一张表来直观的对比一下:
    03
    具体选择什么样的模型或者NIO框架,完全基于业务的实际应用场景和性能需求,如果客户端很少,服务器负荷不重,
 就没有必要选择开发起来相对不那么简单的NIO做服务端;相反,就应考虑使用NIO或者相关的框架了。
 

版权保护: 本文由 PM小曹社区 收录,转载请保留链接: http://www.pmxiaocao.com/jsgh/2019_54.html

尚未注册畅言帐号,请到后台注册
博客主人PM小曹
一枚技术型项目经理,从事编程开发达8年之久,项目管理4年之长,期待与你相识!
  • 文章总数
  • 37695访问次数
  • 建站天数
  • 欢迎关注博主微信公众号[PM小曹]

    微信公众号

    标签