编程语言
首页 > 编程语言> > Java基础十---JavaIO

Java基础十---JavaIO

作者：互联网

CPU指令与内核态、用户态

在操作系统中，CPU负责执行指令,这些指令有些来自应用程序，有些是来自底层系统。
有些指令是非常危险的，如清除内存，网络连接等等，如果错误调用的话有可能导致系统崩溃。
因而CPU将指令分为特权指令和非特权指令，对于某些特定的指令，只需要操作系统及其相关模块进行调用。
因而，根据这个特点，操作系统内部也划分出了内核态和用户态。

内核态

内核态拥有完全的底层资源控制权限，可以执行任何的CPU指令，访问任何内存地址，其占有的处理机是不允许被抢占的。

用户态

用户程序是运行在操作系统之上，这些程序运行时称之为用户态，用户态下不能直接访问底层硬件和内存地址，只能通过委托系统调用的方式来访问底层硬件和内存。

从用户态切换到内核态有三种方式

在网络I/O的过程中，都涉及到了内核态与用户态的切换。

BIO

阻塞模式同步IO

以前大多数网络通信方式都是阻塞模式的，即：

传统的BIO通信方式存在几个问题：

上面说的情况是服务器只有一个线程的情况，那么读者会直接提出我们可以使用多线程技术来解决这个问题(笔者实际生产中就是使用的多线程去解决这种问题的。)

但是使用线程来解决这个问题实际上是有局限性的(见下文非阻塞同步IO)

BIO的问题关键不在于是否使用了多线程（包括线程池）处理这次请求，而在于accept()、read()的操作点都是被阻塞

异步IO模式就是为了解决这样的并发性存在的。

阻塞式同步IO的工作原理

阻塞IO和非阻塞IO这两个概念是程序级别的。主要描述的是程序请求操作系统IO操作后,如果IO资源没有准备好,那么程序该如何处理的问题:
前者等待;后者继续执行(并且使用线程一直轮询,直到有IO资源准备好了)
同步IO和非同步IO这两个概念是操作系统级别的。主要描述的是操作系统在收到程序请求IO操作后,如果IO资源没有准备好,该如何响应程序的问题。
前者不响应，直到IO资源准备好以后;后者返回一个标记(好让程序和自己知道以后的数据往哪里通知),当IO资源准备好以后,再用事件机制返回给程序。

非阻塞同步IO

注：阻塞/非阻塞的描述是针对应用程序中的线程进行的,对于阻塞方式的一种改进是引用程序将其"一直等待"的状态主动打开
这种模式下，应用程序的线程不再一直等待操作系统的IO状态，而是在等待一段时间后，就解除阻塞。如果没有得到想要的结果，则再次进行相同的操作。
这样的工作方式，使得应用程序的线程不会一直阻塞，而是可以进行一些其他工作。

在这种模式下,等待数据的过程是非阻塞的,但是数据拷贝时,仍然是阻塞的，他更多是通过多线程去使得socket套接字的处理互相不受影响。

在这种模式下,依然存在以下问题:

个人的理解,无论是阻塞式同步IO还是非阻塞式同步IO，他都没有跳出BIO，BIO的阻塞，是操作系统层面的阻塞，而不是在请求处理层面的阻塞!

NIO

NIO是同步非阻塞模型，服务端的一个线程可以处理多个请求，客户端发送的连接请求注册在多路复用器Selector上，服务端线程通过轮询多路复用器查看是否有IO请求，有则进行处理。

多路复用IO

多路复用IO，从本质上看还是一种同步IO，因为它没有100%消除IO_WAIT，操作系统也没有为它提供“主动通知”机制。但是多路复用IO的处理速度已经相当快了，利用设备执行IO操作的时间，操作系统可以继续执行IO请求。并同样采用周期性轮询的方式，获取一批IO操作请求的执行响应。

多路复用IO概念

多路复用IO技术最适用的是"高并发"场景,所谓高并发是指1毫秒内至少同时有上千个连接请求准备好。其他情况下多路复用IO技术发挥不出来它的优势。另一方面，使用JAVA NIO进行功能实现，相对于传统的Socket套接字实现要复杂一些，所以实际应用中，需要根据自己的业务需求进行技术选择。

重要概念如下:

  1. channel
    通道，被建立的一个应用程序和操作系统交互事件、传递内容的渠道（注意是连接到操作系统）。一个通道会有一个专属的文件状态描述符。那么既然是和操作系统进行内容的传递，那么说明应用程序可以通过通道读取数据，也可以通过通道向操作系统写数据。
    JAVA NIO框架中,自有的Channel通道包括：

    • ServerSocketChannel：应用服务器程序的监听通道。只有通过这个通道，应用程序才能向操作系统注册支持“多路复用IO”的端口监听。同时支持UDP协议和TCP协议。

    • SocketChannel：TCP Socket套接字的监听通道，一个Socket套接字对应了一个客户端IP：端口 到 服务器IP：端口的通信连接。

    • DatagramChannel：UDP 数据报文的监听通道。

  2. Buffer
    数据缓存区：在JAVA NIO 框架中，为了保证每个通道的数据读写速度JAVA NIO 框架为每一种需要支持数据读写的通道集成了Buffer的支持。
    这句话怎么理解呢？例如ServerSocketChannel通道它只支持对OP_ACCEPT事件的监听，所以它是不能直接进行网络数据内容的读写的。所以ServerSocketChannel是没有集成Buffer的。
    Buffer有两种工作模式：写模式和读模式。在读模式下，应用程序只能从Buffer中读取数据，不能进行写操作。但是在写模式下，应用程序是可以进行读操作的，这就表示可能会出现脏读的情况。所以一旦您决定要从Buffer中读取数据，一定要将Buffer的状态改为读模式。

  3. Selector
    Selector的英文含义是“选择器”，不过根据我们详细介绍的Selector的岗位职责，您可以把它称之为“轮询代理器”、“事件订阅器”、“channel容器管理机”都行。

    • 事件订阅和Channel管理
      应用程序将向Selector对象注册需要它关注的Channel，以及具体的某一个Channel会对哪些IO事件感兴趣。Selector中也会维护一个“已经注册的Channel”的容器。以下代码来自WindowsSelectorImpl实现类中，对已经注册的Channel的管理容器：
    • 轮询代理
      应用层不再通过阻塞模式或者非阻塞模式直接询问操作系统“事件有没有发生”，而是由Selector代其询问。
      在个人看来，这就是一种代理模式的应用，由Selector作为代理，将轮询操作交由其执行。

多路复用IO优缺点

目前流行的多路复用IO实现主要包括四种:select、poll、epoll、kqueue

IO模型 相对性能 关键思路 操作系统 Java支持情况
select 较高 Reactor windows/Linux 支持,Reactor模式(反应器设计模式)。Linux操作系统的 kernels 2.4内核版本之前，默认使用select；而目前windows下对同步IO的支持，都是select模型
poll 较高 Reactor Linux Linux下的JAVA NIO框架，Linux kernels 2.6内核版本之前使用poll进行支持。也是使用的Reactor模式
epoll 高 Reactor/Proactor Linux Linux kernels 2.6内核版本及以后使用epoll进行支持；Linux kernels 2.6内核版本之前使用poll进行支持；另外一定注意，由于Linux下没有Windows下的IOCP技术提供真正的 异步IO 支持，所以Linux下使用epoll模拟异步IO
kqueue 高 Proactor Linux 目前JAVA的版本不支持

select、poll、epoll比较

select 基于轮询机制
fd: linux中， 每一个进程在内核中，都对应有一个“打开文件”数组，存放指向文件对象的指针，而 fd 是这个数组的下标。
我们对文件进行操作时，系统调用，将fd传入内核，内核通过fd找到文件，对文件进行操作。
select本质上是通过设置或检查存放fd标志位的数据结构进行下一步处理。
select模型的缺点：

  1. 单个进程可监视的fd数量被限制

  2. 对socket是线性扫描，即轮询，效率较低： 仅知道有I/O事件发生，却不知是哪几个流，只会无差异轮询所有流，找出能读数据或写数据的流进行操作。同时处理的流越多，无差别轮询时间越长

当socket较多时，每次select都要通过遍历FD_SETSIZE个socket，不管是否活跃，这会浪费很多CPU时间。如果能给 socket 注册某个回调函数，当他们活跃时，自动完成相关操作，即可避免轮询。

poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态， 但是它没有最大连接数的限制，原因是它是基于链表来存储的.

epoll基于操作系统支持的I/O通知机制，支持水平触发和边缘触发两种模式
epoll模型修改主动轮询为被动通知，当有事件发生时，被动接收通知。所以epoll模型注册套接字后，主程序可做其他事情，当事件发生时，接收到通知后再去处理。
epoll支持EPOLLLT和EPOLLET两种触发模式：

poll为什么要有EPOLL ET触发模式？
如果采用EPOLL LT模式的话，系统中一旦有大量你不需要读写的就绪文件描述符，它们每次调用epoll_wait都会返回，这样会大大降低处理程序检索自己关心的就绪文件描述符的效率。
而采用EPOLL ET这种边沿触发模式的话，当被监控的文件描述符上有可读写事件发生时，epoll_wait()会通知处理程序去读写。
如果这次没有把数据全部读写完(如读写缓冲区太小)，那么下次调用epoll_wait()时，它不会通知你，也就是它只会通知你一次，直到该文件描述符上出现第二次可读写事件才会通知你！！！
这种模式比水平触发效率高，系统不会充斥大量你不关心的就绪文件描述符。

因为epoll内核中实现是根据每个fd上的callback函数来实现的，只有活跃的socket才会主动调用callback，所以在活跃socket较少的情况下，使用epoll没有前面两者的线性下降的性能问题，但是所有socket都很活跃的情况下，可能会有性能问题。

Reactor模式

Reactor模式是基于事件驱动开发的,服务端程序处理传入多路请求,并将它们同步分派给请求对应的处理线程。
Reactor模式也叫Dispatcher模式,即I/O多路复用统一监听事件,收到事件后分发(Dispatch给某进程)，这是编写高性能网络服务器的必备技术之一。

Reactor模式以NIO为底层支持,核心组成部分包括Reactor和Handler

根据Reactor的数量和Handler线程数量，可以将Reactor分为三种模型:

Handler完成read -> (decode -> compute -> encode) ->send的业务流程。

这种模型好处是简单，坏处却很明显，当某个Handler阻塞时，会导致其他客户端的handler和accpetor都得不到执行，无法做到高性能，只适用于业务处理非常快速的场景，如redis读写操作。

主线程中，Reactor对象通过Selector监控连接事件,收到事件后通过dispatch进行分发，如果是连接建立事件，则由Acceptor处理，Acceptor通过accept接收连接，并创建一个Handler来处理后续事件，而Handler只负责响应事件，不进行业务操作，也就是只进行read读取数据和write写出数据，业务处理交给一个线程池进行处理。

线程池分配一个线程完成真正的业务处理，然后将响应结果交给主进程的Handler处理，Handler将结果send给client。

单Reactor承担所有事件的监听和响应，而当我们的服务端遇到大量的客户端同时进行连接，或者在请求连接时执行一些耗时操作，比如身份认证，权限检查等，这种瞬时的高并发就容易成为性能瓶颈。

存在多个Reactor，每个Reactor都有自己的Selector选择器，线程和dispatch。

主线程中的mainReactor通过自己的Selector监控连接建立事件，收到事件后通过Accpetor接收，将新的连接分配给某个子线程。

子线程中的subReactor将mainReactor分配的连接加入连接队列中通过自己的Selector进行监听，并创建一个Handler用于处理后续事件。

Handler完成read -> 业务处理 -> send的完整业务流程。

在Reactor中，被拆分的小线程或者子过程对应的是handler，每一种handler会出处理一种event。这里会有一个全局的管理者selector，我们需要把channel注册感兴趣的事件，那么这个selector就会不断在channel上检测是否有该类型的事件发生，如果没有，那么主线程就会被阻塞，否则就会调用相应的事件处理函数即handler来处理。

Redis中的IO多路复用机制(基于Reactor模式)

Redis基于Reactor模式开发了自己的网络事件处理器，称之为文件事件处理器(File Event Hanlder)。文件事件处理器由Socket、IO多路复用程序、文件事件分派器(dispather)，事件处理器(handler)四部分组成。
image
IO多路复用程序会同时监听多个socket，当被监听的socket准备好执行accept、read、write、close等操作时，与这些操作相对应的文件事件就会产生。IO多路复用程序会把所有产生事件的socket压入一个队列中，然后有序地每次仅一个socket的方式传送给文件事件分派器，文件事件分派器接收到socket之后会根据socket产生的事件类型调用对应的事件处理器进行处理。

AIO

异步IO

IO模型是由操作系统提供支持，且上文提到的三种IO模型都是同步IO，都是采用的“应用程序不询问我，我绝不会主动通知”的方式。

异步IO则是采用“订阅-通知”模式：即应用程序向操作系统注册IO监听，然后继续做自己的事情。当操作系统发生IO事件，并且准备好数据后，在主动通知应用程序，触发相应的函数：

注意在JAVA NIO框架中，我们说到了一个重要概念“selector”（选择器）。它负责代替应用查询中所有已注册的通道到操作系统中进行IO事件轮询、管理当前注册的通道集合，定位发生事件的通道等操操作；但是在JAVA AIO框架中，由于应用程序不是“轮询”方式，而是订阅-通知方式，所以不再需要“selector”（选择器）了，改由channel通道直接到操作系统注册监听。

JAVA AIO框架中，只实现了两种网络IO通道“AsynchronousServerSocketChannel”（服务器监听通道）、“AsynchronousSocketChannel”（socket套接字通道）。但是无论哪种通道他们都有独立的fileDescriptor（文件标识符）、attachment（附件，附件可以使任意对象，类似“通道上下文”），并被独立的SocketChannelReadHandle类实例引用。

JAVA NIO和JAVA AIO框架，除了因为操作系统的实现不一样而去掉了Selector外，其他的重要概念都是存在的，例如上文中提到的Channel的概念，还有演示代码中使用的Buffer缓存方式。实际上JAVA NIO和JAVA AIO框架您可以看成是一套完整的“高并发IO处理”的实现。

为什么还有Netty?
那么有的读者可能就会问，既然JAVA NIO / JAVA AIO已经实现了各主流操作系统的底层支持，那么为什么现在主流的JAVA NIO技术会是Netty和MINA呢？答案很简单：因为更好用，这里举几个方面的例子：

参考链接

Java 网络IO模型简介---凡尘多遗梦
架构设计：系统间通信---说好不能打脸
Redis中的IO多路复用机制---凡尘多遗梦
Java 开发必备！ I/O与Netty原理精讲---阿里技术

标签：Java,操作系统,阻塞,---,JavaIO,线程,事件,IO,Reactor
来源： https://www.cnblogs.com/winter0730/p/15533783.html