Java中I/O的分类

  1. IO按照处理的数据类型可分为:
    (1)面向字节操作的I/O接口:inputStream、outputStream
    (2)面向字符操作的接口:Reader、Writer
  2. IO按照数据的传输方式可分为:
    (1)面向磁盘操作的I/O接口:File
    (2)面向网络接口的I/O接口:Socket

I/O模型

一个输入操作通常包括两个阶段:

  1. 等待数据准备好
  2. 从内核向进程复制数据
    对于一个套接字(套接字就是IP:端口号,是用于TCP连接的端点),第一步通常涉及等待数据从网络中到达。当所等待数据到达时,它被复制到内核中的某个缓冲区;第二步就是把数据从内核缓冲区复制到应用程序缓冲区。

Unix中有5种I/O模型:

  1. 阻塞式I/O
  2. 非阻塞式I/O
  3. I/O复用
  4. 信号驱动I/O
  5. 异步I/O

下图是几种常见I/O模型的对比:

同步和异步(从行为角度描述事物)

  • 同步 :两个同步任务相互依赖,并且一个任务必须以依赖于另一任务的某种方式执行。 比如在A->B事件模型中,你需要先完成 A 才能执行B。 再换句话说,同步调用中被调用者未处理完请求之前,调用不返回,调用者会一直等待结果的返回。
  • 异步: 两个异步的任务完全独立的,一方的执行不需要等待另外一方的执行。再换句话说,异步调用种一调用就返回结果不需要等待结果返回,当结果返回的时候通过回调函数或者其他方式拿着结果再做相关事情。

阻塞和非阻塞(从当前状态描述事物)

  • 阻塞: 阻塞就是发起一个请求,调用者一直等待请求结果返回,也就是当前线程会被挂起,无法从事其他任务,只有当条件就绪才能继续。
  • 非阻塞: 非阻塞就是发起一个请求,调用者不用一直等着结果返回,可以先去干其他事情。

阻塞式I/O

最常见的一种I/O模型。
之前介绍过,一个read操作是分两个阶段的,第一个阶段是,等待数据准备就绪,第二个阶段是将数据拷贝到调用这个IO的线程中。阻塞是发生在第一个阶段的,当数据没有准备好时,会一直阻塞用户线程,当数据就绪后再将数据拷贝到线程中,并返回结果给用户线程。
需要注意的是,阻塞式 I/O 不是意味着系统进入阻塞,而仅仅是当前应用程序阻塞,其他应用程序还是可以继续运行的,因此不消耗 CPU 时间,执行效率较高。

其实,大部分的socket接口都是典型的阻塞型。所谓阻塞型的接口是指系统调用(一般是IO接口)不返回调用结果并让当前线程一直阻塞,只有当该系统调用获得结果或者超时出错时才返回。

阻塞式I/O的问题:
阻塞时会使用户线程无法进行任何运算和请求。一般我们的处理这种问题的情况是使用多线程,每个链接创建一个线程,或是使用线程池来管理线程,或许可以缓解部分压力,但是不能解决所有问题。多线程模型可以方便高效的解决小规模的服务请求,但面对大规模的服务请求,多线程模型也会遇到瓶颈,可以用非阻塞接口来尝试解决这个问题。

非阻塞式I/O

非阻塞IO模型是这样一个过程,当应用程序发起一个read操作时,并不会阻塞,而是立刻会收到一个结果。应用程序的线程发现返回结果是一个error时,它就知道数据还没有准备好,于是它可以再次发送read操作。一旦数据准备好了,并且又再次收到了用户线程的请求,那么它马上就将数据拷贝到了用户内存,然后返回。
这样的一个过程,其实是需要用户线程不断的去询问系统是否准备好了数据,这种方式称为轮询(polling),这样就会一直占用CPU资源。但是这种模型是在只专门提供某种功能的系统才有。

I/O复用

在介绍I/O复用时,先简单说一下 select 函数和 poll 函数。

  • select函数 select函数允许进程指示内核等待多个事件中的任何一个事件发生,并且只在有一个或多个事件发生或经历一段指定的时间后才唤醒它。
  • poll函数 poll函数提供的功能与select函数类似,但是poll没有最大文件描述符数量的限制。select函数和poll函数将就绪的文件描述符告诉进程后,如果进程没有对其进行IO操作,那么下次调用select函数或者poll函数时会再次报告这些文件描述符, 所以他们一般不会丢失就绪的消息,这种方式称为水平触发(Level Triggered)。

IO复用模型就是调用select或poll函数,并且此模型的阻塞过程就是发生在调用这两个函数中的,而不是发生在真正的的I/O系统调用上的,使用select或poll的好处在于可以用单个线程或进程,处理多个网络连接的IO。整个过程就是select或poll函数会不断的轮询所负责的socket,当某个socket有数据到达了,就通知用户线程或进程。

注意:如果处理的连接数不是很高的话,使用 select/epoll 的 web server 不一定比使用 multi-threading + blocking IO 的 web server 性能更好,可能延迟还更大。select/epoll 的优势并不是对于单个连接能处理得更快,而是在于能处理更多的连接。

信号驱动I/O

因为不常用。基本不会涉及到 本文不做介绍。

异步I/O

异步IO模型的过程是这样的,当用户线程发起read操作时,告知内核启动读取数据操作,并让内核在整个操作(包括将数据从内核复制到我们自己的缓冲区)完成后通知我们。这样在内核执行读取数据操作时,用户线程可以继续执行,当接收到内核在整个操作都完成的信号时,就可以直接去使用数据了。

在异步IO模型中,IO操作的两个阶段都不会阻塞用户线程或进程,这两个阶段都是由内核完成的,然后发送一个信号告知用户线程或进程操作已完成。异步IO模型与信号驱动IO模型的区别在于,信号驱动IO模型是由内核通知用户线程何时启动一个IO操作,而异步IO模型是由内核通知我们IO操作何时完成,异步IO模型中用户线程并不需要进行实际的读写操作,只需要在内核操作完成后,接到读取完成信号后,直接使用数据即可。

详解I/O多路复用技术

select,poll,epoll都是IO多路复用的机制。I/O多路复用就是通过一种机制,一个进程可以监视多个描述符,一旦某个描述符就绪(一般是读就绪或者写就绪),能够通知程序进行相应的读写操作。但select,poll,epoll本质上都是同步I/O,因为他们都需要在读写事件就绪后自己负责进行读写,也就是说这个读写过程是阻塞的,而异步I/O则无需自己负责进行读写,异步I/O的实现会负责把数据从内核拷贝到用户空间。

文件描述符(File descriptor)是计算机科学中的一个术语,是一个用于表述指向文件的引用的抽象化概念。
文件描述符在形式上是一个非负整数。实际上,它是一个索引值,指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时,内核向进程返回一个文件描述符。在程序设计中,一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。

select函数

int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

select 函数监视的文件描述符分3类,分别是writefds、readfds、和exceptfds。分别对应读、 写、 异常条件的描述符集合。 fd_set 使用数组实现, 数组大小使用 FD_SETSIZE 定义。timeout 为超时参数, 调用 select 会一直阻塞直到有描述符的事件到达或者等待的时间超过 timeout。成功调用返回结果大于 0, 出错返回结果为 -1, 超时返回结果为 0。

select详细过程:
当用户 process 调用 select 的时候,select 会将需要监控的 readfds 集合拷贝到内核空间(假设监控的仅仅是 socket 可读),然后遍历自己监控的 socket sk,挨个调用 sk 的 poll 逻辑以便检查该 sk 是否有可读事件,遍历完所有的 sk 后,如果没有任何一个 sk 可读,那 select 会调用 schedule_timeout 进入 schedule 循环,使得 process 进入睡眠。如果在 timeout 时间内某个 sk 上有数据可读了,或者等待 timeout 了,则调用 select 的 process 会被唤醒,接下来 select 就是遍历监控的 sk 集合,挨个收集可读事件并返回给用户

  • 优点:select目前几乎在所有的平台上支持,其良好跨平台支持也是它的一个优点。
  • 缺点:单个进程能够监视的文件描述符的数量存在最大限制,在Linux上一般为1024,可以通过修改宏定义甚至重新编译内核的方式提升这一限制,但 是这样也会造成效率的降低。

poll函数

int poll (struct pollfd *fds, unsigned int nfds, int timeout);

不同与select使用三个位图来表示三个fdset的方式,poll使用一个 pollfd的指针实现。
poll本质上和select没有区别,它将用户传入的数组拷贝到内核空间,然后查询每个fd对应的设备状态,如果设备就绪则在设备等待队列中加入一项并继续遍历,如果遍历完所有fd后没有发现就绪设备,则挂起当前进程,直到设备就绪或者主动超时,被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。

它没有最大连接数的限制,原因是它是基于链表来存储的,但是同样有一个缺点:

  1. 大量的fd的数组被整体复制于用户态和内核地址空间之间,而不管这样的复制是不是有意义。
  2. poll还有一个特点是“水平触发”,如果报告了fd后,没有被处理,那么下次poll时会再次报告该fd。

select poll比较

  • 功能
    实现大致相同,但是一些细节还是存在不同:
    select 的描述符类型使用数组实现,FD_SETSIZE 默认大小为 1024,不过这个值可以改变,如果需要修改的话要重新编译;而 poll 使用链表实现,没有描述符大小的限制。
    poll 提供更多的事件类型,并且对描述符的重复利用比 selec 高。
    如果一个线程对某个描述符调用了 selec 或者 poll,另一个线程关闭了该描述符,会导致调用结果不确定。
  • 速度
    速度都很慢。
    共同的就是在调用时都需要将全部描述符从应用进程缓冲区复制到内核缓冲区。
    两者返回结果中没有声明哪些描述符已经准备好,所以如果返回值大于 0 时,应用进程都需要使用轮询的方式来找到 I/O 完成的描述符。
  • 可移植性
    select 出现比较早,所以基本上所有的系统都支持,而只有比较新的系统才支持 poll。

epoll函数

//创建一个epoll的句柄,size用来告诉内核这个监听的数目一共有多大
int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

epoll_ctl() 用于向内核注册新的描述符或者是改变某个文件描述符的状态。 已注册的描述符在内核中会被维护在一棵红黑树上, 通过回调函数内核会将 I/O 准备好的描述符加入到一个链表中管理, 进程调用 epoll_wait() 便可以得到事件完成的描述符。

epoll特点:

  • epoll 只需要将描述符从进程缓冲区向内核缓冲区拷贝一次, 并且进程不需要通过轮询来获得事件完成的描述符。
  • epoll 仅适用于 Linux OS。
  • epoll 比 select 和 poll 更加灵活而且没有描述符数量限制。
  • epoll 对多线程编程更有友好, 一个线程调用了 epoll_wait() 另一个线程关闭了同一个描述符也不会产生像 select 和 poll 的不确定情况。

epoll工作模式
epoll 的描述符事件有两种触发模式: LT( level trigger,默认模式) 和 ET( edge trigger,高速模式)。

  • LT 模式
    当 epoll_wait() 检测到描述符事件到达时,将此时间通知进程,进程可以不立即处理该事件,下次调用 epoll_wait() 时会再次通知进程,这是默认一种模式,并且同时支持阻塞和非阻塞。

  • ET 模式
    和 LT 模式不同的是,通知之后必须立即处理事件,下次再调用 epoll_wait() 不会再得到时间到达的通知。减少了 epoll 事件被重复触发的次数,因此效率比 LT 高,只支持非阻塞式,以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

应用场景

通过上面的对比,很容易理解是既然 epoll 这么强大,那么都使用 epoll 不就够了?实际上不是这样的,其实都各自有各自的使用场景:

  • select 使用场景
    select 的 timeout 精度为 1ns,而其他两种为 1ms,所以 select 更适用于实时要求很高的场景,比如核反应堆的控制。
    select 可移植性好,几乎被所有主流平台支持。
  • poll 使用场景
    poll 与 select 相比没有最大描述符数量的限制,并且如果平台对实时性要求不是很高,一般使用poll需要同时监控小于 1000 个描述符,就没必要使用 epoll,因为这个应用场景下并不能体现 epoll 的优势。
    需要监控的描述符状态变化多,而且都是非常短暂的,也没有必要使用 epoll,因为 epoll 中的所有描述符都是存储在内核中,造成每次对描述符状态的改变都需要通过系统调用,频繁系统调用肯定会降低效率,并且 epoll 的描述符存储在内核中不容易调试。
  • epoll 使用场景
    只需要运行在 Linux 平台,并且有非常大量的描述符需要同时轮询,而且这些连接最好是长连接。

Java I/O

Java 中的 BIO、NIO和 AIO 理解为是 Java 语言对操作系统的各种 IO 模型的封装。程序员在使用这些 API 的时候,不需要关心操作系统层面的知识,也不需要根据不同操作系统编写不同的代码。只需要使用Java的API就可以了。

BIO (Blocking I/O)

同步阻塞I/O模式,数据的读取写入必须阻塞在一个线程内等待其完成。例如:InputStream和OutputStream,Reader和Writer。

传统BIO

BIO通信(一请求一应答)模型图:

采用 BIO 通信模型 的服务端,通常由一个独立的 Acceptor 线程负责监听客户端的连接。我们一般通过在while(true) 循环中服务端会调用 accept() 方法等待接收客户端的连接的方式监听请求,请求一旦接收到一个连接请求,就可以建立通信套接字在这个通信套接字上进行读写操作,此时不能再接收其他客户端连接请求,只能等待同当前连接的客户端的操作执行完成, 不过可以通过多线程来支持多个客户端的连接,如上图所示。

如果要让 BIO 通信模型能够同时处理多个客户端请求,就必须使用多线程(主要原因是socket.accept()、socket.read()、socket.write() 涉及的三个主要函数都是同步阻塞的),也就是说它在接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理,处理完成之后,通过输出流返回应答给客户端,线程销毁。这就是典型的 一请求一应答通信模型 。我们可以设想一下如果这个连接不做任何事情的话就会造成不必要的线程开销,不过可以通过线程池机制改善,线程池还可以让线程的创建和回收成本相对较低。使用FixedThreadPool 可以有效的控制了线程的最大数量,保证了系统有限的资源的控制,实现了N(客户端请求数量):M(处理客户端请求的线程数量)的伪异步I/O模型(N 可以远远大于 M)。

当客户端并发访问量增加后这种模型会出现什么问题?
在 Java 虚拟机中,线程是宝贵的资源,线程的创建和销毁成本很高,除此之外,线程的切换成本也是很高的。尤其在 Linux 这样的操作系统中,线程本质上就是一个进程,创建和销毁线程都是重量级的系统函数。如果并发访问量增加会导致线程数急剧膨胀可能会导致线程堆栈溢出、创建新线程失败等问题,最终导致进程宕机或者僵死,不能对外提供服务。

伪异步IO

为了解决同步阻塞I/O面临的一个链路需要一个线程处理的问题,后来有人对它的线程模型进行了优化一一一后端通过一个线程池来处理多个客户端的请求接入,形成客户端个数M:线程池最大线程数N的比例关系,其中M可以远远大于N.通过线程池可以灵活地调配线程资源,设置线程的最大值,防止由于海量并发接入导致线程耗尽。

伪异步IO模型图:

采用线程池和任务队列可以实现一种叫做伪异步的 I/O 通信框架,它的模型图如上图所示。当有新的客户端接入时,将客户端的 Socket 封装成一个Task(该任务实现java.lang.Runnable接口)投递到后端的线程池中进行处理,JDK 的线程池维护一个消息队列和 N 个活跃线程,对消息队列中的任务进行处理。由于线程池可以设置消息队列的大小和最大线程数,因此,它的资源占用是可控的,无论多少个客户端并发访问,都不会导致资源的耗尽和宕机。
伪异步I/O通信框架采用了线程池实现,因此避免了为每个请求都创建一个独立线程造成的线程资源耗尽问题。不过因为它的底层仍然是同步阻塞的BIO模型,因此无法从根本上解决问题。

代码示例

下面代码中演示了BIO通信(一请求一应答)模型。我们会在客户端创建多个线程依次连接服务端并向其发送"当前时间+:hello world",服务端会为每个客户端线程创建一个线程来处理。

客户端

import java.io.IOException;
import java.net.Socket;
import java.util.Date;
public class IOClient {
    public static void main(String[] args) {
        // TODO 创建多个线程,模拟多个客户端连接服务端
        new Thread(() -> {
            try {
                Socket socket = new Socket("127.0.0.1", 3333);
                while (true) {
                    try {
                        socket.getOutputStream().write((new Date() + ": hello world").getBytes());
                        Thread.sleep(2000);
                    } catch (Exception e) {
                    }
                }
            } catch (IOException e) {
            }
        }).start();
    }
}

服务端

import java.io.IOException;
import java.io.InputStream;
import java.net.ServerSocket;
import java.net.Socket;
public class IOServer {
    public static void main(String[] args) throws IOException {
        // TODO 服务端处理客户端连接请求
        ServerSocket serverSocket = new ServerSocket(3333);
        // 接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理
        new Thread(() -> {
            while (true) {
                try {
                    // 阻塞方法获取新的连接
                    Socket socket = serverSocket.accept();
                    // 每一个新的连接都创建一个线程,负责读取数据
                    new Thread(() -> {
                        try {
                            int len;
                            byte[] data = new byte[1024];
                            InputStream inputStream = socket.getInputStream();
                            // 按字节流方式读取数据
                            while ((len = inputStream.read(data)) != -1) {
                                System.out.println(new String(data, 0, len));
                            }
                        } catch (IOException e) {
                        }
                    }).start();
                } catch (IOException e) {
                }
            }
        }).start();
    }
}

总结

在活动连接数不是特别高(小于单机1000)的情况下,这种模型是比较不错的,可以让每一个连接专注于自己的 I/O 并且编程模型简单,也不用过多考虑系统的过载、限流等问题。线程池本身就是一个天然的漏斗,可以缓冲一些系统处理不了的连接或请求。但是,当面对十万甚至百万级连接的时候,传统的 BIO 模型是无能为力的。因此,我们需要一种更高效的 I/O 处理模型来应对更高的并发量。

NIO (New I/O)

NIO是一种同步非阻塞的I/O模型,在Java 1.4 中引入了 NIO 框架,对应 java.nio 包,提供了 Channel , Selector,Buffer等抽象。NIO中的N可以理解为Non-blocking,不单纯是New。

NIO简介

它支持面向缓冲的,基于通道的I/O操作方法。 NIO提供了与传统BIO模型中的 Socket 和 ServerSocket 相对应的 SocketChannel 和 ServerSocketChannel 两种不同的套接字通道实现,两种通道都支持阻塞和非阻塞两种模式。阻塞模式使用就像传统中的支持一样,比较简单,但是性能和可靠性都不好;非阻塞模式正好与之相反。对于低负载、低并发的应用程序,可以使用同步阻塞I/O来提升开发速率和更好的维护性;对于高负载、高并发的(网络)应用,应使用 NIO 的非阻塞模式来开发。

NIO特性/NIO与IO区别

Non-bolcking IO(非阻塞IO)

IO流是阻塞的,NIO流是非阻塞的。
Java NIO使我们可以进行非阻塞IO操作。比如说,单线程中从通道读取数据到buffer,同时可以继续做别的事情,当数据读取到buffer中后,线程再继续处理数据。写数据也是一样的。另外,非阻塞写也是如此。一个线程请求写入一些数据到某通道,但不需要等待它完全写入,这个线程同时可以去做别的事情。
Java IO的各种流是阻塞的。这意味着,当一个线程调用 read() 或 write() 时,该线程被阻塞,直到有一些数据被读取,或数据完全写入。该线程在此期间不能再干任何事情了。

Buffer(缓冲区)

IO 面向流(Stream oriented),而 NIO 面向缓冲区(Buffer oriented)。
Buffer是一个对象,它包含一些要写入或者要读出的数据。在NIO类库中加入Buffer对象,体现了新库与原I/O的一个重要区别。在面向流的I/O中,可以将数据直接写入或者将数据直接读到 Stream 对象中。虽然 Stream 中也有Buffer 开头的扩展类,但只是流的包装类,还是从流读到缓冲区,而 NIO 却是直接读到 Buffer 中进行操作。
在NIO厍中,所有数据都是用缓冲区处理的。在读取数据时,它是直接读到缓冲区中的; 在写入数据时,写入到缓冲区中。任何时候访问NIO中的数据,都是通过缓冲区进行操作。
最常用的缓冲区是 ByteBuffer,一个 ByteBuffer 提供了一组功能用于操作 byte 数组。除了ByteBuffer,还有其他的一些缓冲区,事实上,每一种Java基本类型(除了Boolean类型)都对应有一种缓冲区。

Channel(通道)

NIO 通过Channel(通道) 进行读写。
通道是双向的,可读也可写,而流的读写是单向的。无论读写,通道只能和Buffer交互。因为 Buffer,通道可以异步地读写。

Selector(选择器)

NIO有选择器,而IO没有。
选择器用于使用单个线程处理多个通道。因此,它需要较少的线程来处理这些通道。线程之间的切换对于操作系统来说是昂贵的。 因此,为了提高系统效率选择器是有用的。

NIO读写数据的方式

通常来说NIO中的所有IO都是从 Channel(通道) 开始的。

  • 从通道进行数据读取 :创建一个缓冲区,然后请求通道读取数据。
  • 从通道进行数据写入 :创建一个缓冲区,填充数据,并要求通道写入数据。

数据读取和写入操作图示:

NIO核心组件

NIO 包含下面几个核心的组件:

  • Channel(通道)
  • Buffer(缓冲区)
  • Selector(选择器)
    整个NIO体系包含的类远远不止这三个,只能说这三个是NIO体系的“核心API”。我们上面已经对这三个概念进行了基本的阐述,这里就不多做解释了。

代码示例

客户端 IOClient.java 的代码不变,我们对服务端使用 NIO 进行改造。以下代码较多而且逻辑比较复杂,大家看看就好。

import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;
import java.nio.charset.Charset;
import java.util.Iterator;
import java.util.Set;
public class NIOServer {
    public static void main(String[] args) throws IOException {
        // 1. serverSelector负责轮询是否有新的连接,服务端监测到新的连接之后,不再创建一个新的线程,
        // 而是直接将新连接绑定到clientSelector上,这样就不用 IO 模型中 1w 个 while 循环在死等
        Selector serverSelector = Selector.open();
        // 2. clientSelector负责轮询连接是否有数据可读
        Selector clientSelector = Selector.open();
        new Thread(() -> {
            try {
                // 对应IO编程中服务端启动
                ServerSocketChannel listenerChannel = ServerSocketChannel.open();
                listenerChannel.socket().bind(new InetSocketAddress(3333));
                listenerChannel.configureBlocking(false);
                listenerChannel.register(serverSelector, SelectionKey.OP_ACCEPT);
                while (true) {
                    // 监测是否有新的连接,这里的1指的是阻塞的时间为 1ms
                    if (serverSelector.select(1) > 0) {
                        Set<SelectionKey> set = serverSelector.selectedKeys();
                        Iterator<SelectionKey> keyIterator = set.iterator();
                        while (keyIterator.hasNext()) {
                            SelectionKey key = keyIterator.next();
                            if (key.isAcceptable()) {
                                try {
                                    // (1) 每来一个新连接,不需要创建一个线程,而是直接注册到clientSelector
                                    SocketChannel clientChannel = ((ServerSocketChannel) key.channel()).accept();
                                    clientChannel.configureBlocking(false);
                                    clientChannel.register(clientSelector, SelectionKey.OP_READ);
                                } finally {
                                    keyIterator.remove();
                                }
                            }
                        }
                    }
                }
            } catch (IOException ignored) {
            }
        }).start();
        new Thread(() -> {
            try {
                while (true) {
                    // (2) 批量轮询是否有哪些连接有数据可读,这里的1指的是阻塞的时间为 1ms
                    if (clientSelector.select(1) > 0) {
                        Set<SelectionKey> set = clientSelector.selectedKeys();
                        Iterator<SelectionKey> keyIterator = set.iterator();
                        while (keyIterator.hasNext()) {
                            SelectionKey key = keyIterator.next();
                            if (key.isReadable()) {
                                try {
                                    SocketChannel clientChannel = (SocketChannel) key.channel();
                                    ByteBuffer byteBuffer = ByteBuffer.allocate(1024);
                                    // (3) 面向 Buffer
                                    clientChannel.read(byteBuffer);
                                    byteBuffer.flip();
                                    System.out.println(Charset.defaultCharset().newDecoder().decode(byteBuffer).toString());
                                } finally {
                                    keyIterator.remove();
                                    key.interestOps(SelectionKey.OP_READ);
                                }
                            }
                        }
                    }
                }
            } catch (IOException ignored) {
            }
        }).start();
    }
}

为什么大家都不愿意用 JDK 原生 NIO 进行开发呢?
从上面的代码中大家都可以看出来,是真的难用!除了编程复杂、编程模型难之外,它还有以下让人诟病的问题:

  • JDK 的 NIO 底层由 epoll 实现,该实现饱受诟病的空轮询 bug 会导致 cpu 飙升 100%
  • 项目庞大之后,自行实现的 NIO 很容易出现各类 bug,维护成本较高,上面这一坨代码我都不能保证没有 bug
    Netty 的出现很大程度上改善了 JDK 原生 NIO 所存在的一些让人难以忍受的问题。

AIO (Asynchronous I/O)

AIO 也就是 NIO 2。在 Java 7 中引入了 NIO 的改进版 NIO 2,它是异步非阻塞的IO模型。异步 IO 是基于事件和回调机制实现的,也就是应用操作之后会直接返回,不会堵塞在那里,当后台处理完成,操作系统会通知相应的线程进行后续的操作。

AIO得到结果的方式:

  • 基于回调:实现CompletionHandler接口,调用时触发回调函数
  • 返回Future:通过isDone()查看是否准备好,通过get()等待返回数据
    但要实现真正的异步非阻塞IO,需要操作系统支持,Windows支持而Linux不完善。

AIO 是异步IO的缩写,虽然 NIO 在网络操作中,提供了非阻塞的方法,但是 NIO 的 IO 行为还是同步的。对于 NIO 来说,我们的业务线程是在 IO 操作准备好时,得到通知,接着就由这个线程自行进行 IO 操作,IO操作本身是同步的。(除了 AIO 其他的 IO 类型都是同步的,这一点可以从底层IO线程模型解释,推荐一篇文章:《漫话:如何给女朋友解释什么是Linux的五种IO模型?》 )
查阅网上相关资料,我发现就目前来说 AIO 的应用还不是很广泛,Netty 之前也尝试使用过 AIO,不过又放弃了。

参考文档:
https://juejin.im/post/6844904199868645383
https://juejin.im/post/6844903810322661390
https://github.com/Snailclimb/JavaGuide/blob/master/docs/java/BIO-NIO-AIO.md