08 网络通信优化之I O模型：如何解决高并发下I O瓶颈？
你好，我是刘超。
提到Java I/O，相信你一定不陌生。你可能使用I/O操作读写文件，也可能使用它实现Socket的信息传输…这些都是我们在系统中最常遇到的和I/O有关的操作。
我们都知道，I/O的速度要比内存速度慢，尤其是在现在这个大数据时代背景下，I/O的性能问题更是尤为突出，I/O读写已经成为很多应用场景下的系统性能瓶颈，不容我们忽视。
今天，我们就来深入了解下Java I/O在高并发、大数据业务场景下暴露出的性能问题，从源头入手，学习优化方法。
什么是I/O
I/O是机器获取和交换信息的主要渠道，而流是完成I/O操作的主要方式。
在计算机中，流是一种信息的转换。流是有序的，因此相对于某一机器或者应用程序而言，我们通常把机器或者应用程序接收外界的信息称为输入流（InputStream），从机器或者应用程序向外输出的信息称为输出流（OutputStream），合称为输入/输出流（I/O Streams）。
机器间或程序间在进行信息交换或者数据交换时，总是先将对象或数据转换为某种形式的流，再通过流的传输，到达指定机器或程序后，再将流转换为对象数据。因此，流就可以被看作是一种数据的载体，通过它可以实现数据交换和传输。
Java的I/O操作类在包java.io下，其中InputStream、OutputStream以及Reader、Writer类是I/O包中的4个基本类，它们分别处理字节流和字符流。如下图所示：
回顾我的经历，我记得在初次阅读Java I/O流文档的时候，我有过这样一个疑问，在这里也分享给你，那就是：“不管是文件读写还是网络发送接收，信息的最小存储单元都是字节，那为什么I/O流操作要分为字节流操作和字符流操作呢？”
我们知道字符到字节必须经过转码，这个过程非常耗时，如果我们不知道编码类型就很容易出现乱码问题。所以I/O流提供了一个直接操作字符的接口，方便我们平时对字符进行流操作。下面我们就分别了解下“字节流”和“字符流”。
1.字节流
InputStream/OutputStream是字节流的抽象类，这两个抽象类又派生出了若干子类，不同的子类分别处理不同的操作类型。如果是文件的读写操作，就使用FileInputStream/FileOutputStream；如果是数组的读写操作，就使用ByteArrayInputStream/ByteArrayOutputStream；如果是普通字符串的读写操作，就使用BufferedInputStream/BufferedOutputStream。具体内容如下图所示：
2.字符流
Reader/Writer是字符流的抽象类，这两个抽象类也派生出了若干子类，不同的子类分别处理不同的操作类型，具体内容如下图所示：
传统I/O的性能问题
我们知道，I/O操作分为磁盘I/O操作和网络I/O操作。前者是从磁盘中读取数据源输入到内存中，之后将读取的信息持久化输出在物理磁盘上；后者是从网络中读取信息输入到内存，最终将信息输出到网络中。但不管是磁盘I/O还是网络I/O，在传统I/O中都存在严重的性能问题。
1.多次内存复制
在传统I/O中，我们可以通过InputStream从源数据中读取数据流输入到缓冲区里，通过OutputStream将数据输出到外部设备（包括磁盘、网络）。你可以先看下输入操作在操作系统中的具体流程，如下图所示：
- JVM会发出read()系统调用，并通过read系统调用向内核发起读请求；
- 内核向硬件发送读指令，并等待读就绪；
- 内核把将要读取的数据复制到指向的内核缓存中；
- 操作系统内核将数据复制到用户空间缓冲区，然后read系统调用返回。
在这个过程中，数据先从外部设备复制到内核空间，再从内核空间复制到用户空间，这就发生了两次内存复制操作。这种操作会导致不必要的数据拷贝和上下文切换，从而降低I/O的性能。
2.阻塞
在传统I/O中，InputStream的read()是一个while循环操作，它会一直等待数据读取，直到数据就绪才会返回。这就意味着如果没有数据就绪，这个读取操作将会一直被挂起，用户线程将会处于阻塞状态。
在少量连接请求的情况下，使用这种方式没有问题，响应速度也很高。但在发生大量连接请求时，就需要创建大量监听线程，这时如果线程没有数据就绪就会被挂起，然后进入阻塞状态。一旦发生线程阻塞，这些线程将会不断地抢夺CPU资源，从而导致大量的CPU上下文切换，增加系统的性能开销。
如何优化I/O操作
面对以上两个性能问题，不仅编程语言对此做了优化，各个操作系统也进一步优化了I/O。JDK1.4发布了java.nio包（new I/O的缩写），NIO的发布优化了内存复制以及阻塞导致的严重性能问题。JDK1.7又发布了NIO2，提出了从操作系统层面实现的异步I/O。下面我们就来了解下具体的优化实现。
1.使用缓冲区优化读写流操作
在传统I/O中，提供了基于流的I/O实现，即InputStream和OutputStream，这种基于流的实现以字节为单位处理数据。
NIO与传统 I/O 不同，它是基于块（Block）的，它以块为基本单位处理数据。在NIO中，最为重要的两个组件是缓冲区（Buffer）和通道（Channel）。Buffer是一块连续的内存块，是 NIO 读写数据的中转地。Channel表示缓冲数据的源头或者目的地，它用于读取缓冲或者写入数据，是访问缓冲的接口。
传统I/O和NIO的最大区别就是传统I/O是面向流，NIO是面向Buffer。Buffer可以将文件一次性读入内存再做后续处理，而传统的方式是边读文件边处理数据。虽然传统I/O后面也使用了缓冲块，例如BufferedInputStream，但仍然不能和NIO相媲美。使用NIO替代传统I/O操作，可以提升系统的整体性能，效果立竿见影。
2. 使用DirectBuffer减少内存复制
NIO的Buffer除了做了缓冲块优化之外，还提供了一个可以直接访问物理内存的类DirectBuffer。普通的Buffer分配的是JVM堆内存，而DirectBuffer是直接分配物理内存(非堆内存)。
我们知道数据要输出到外部设备，必须先从用户空间复制到内核空间，再复制到输出设备，而在Java中，在用户空间中又存在一个拷贝，那就是从Java堆内存中拷贝到临时的直接内存中，通过临时的直接内存拷贝到内存空间中去。此时的直接内存和堆内存都是属于用户空间。
你肯定会在想，为什么Java需要通过一个临时的非堆内存来复制数据呢？如果单纯使用Java堆内存进行数据拷贝，当拷贝的数据量比较大的情况下，Java堆的GC压力会比较大，而使用非堆内存可以减低GC的压力。
DirectBuffer则是直接将步骤简化为数据直接保存到非堆内存，从而减少了一次数据拷贝。以下是JDK源码中IOUtil.java类中的write方法：
if (src instanceof DirectBuffer)
return writeFromNativeBuffer(fd, src, position, nd);
// Substitute a native buffer
int pos = src.position();
int lim = src.limit();
assert (pos <= lim);
int rem = (pos <= lim ? lim - pos : 0);
ByteBuffer bb = Util.getTemporaryDirectBuffer(rem);
try {
bb.put(src);
bb.flip();
// ...............
这里拓展一点，由于DirectBuffer申请的是非JVM的物理内存，所以创建和销毁的代价很高。DirectBuffer申请的内存并不是直接由JVM负责垃圾回收，但在DirectBuffer包装类被回收时，会通过Java Reference机制来释放该内存块。
DirectBuffer只优化了用户空间内部的拷贝，而之前我们是说优化用户空间和内核空间的拷贝，那Java的NIO中是否能做到减少用户空间和内核空间的拷贝优化呢？
答案是可以的，DirectBuffer是通过unsafe.allocateMemory(size)方法分配内存，也就是基于本地类Unsafe类调用native方法进行内存分配的。而在NIO中，还存在另外一个Buffer类：MappedByteBuffer，跟DirectBuffer不同的是，MappedByteBuffer是通过本地类调用mmap进行文件内存映射的，map()系统调用方法会直接将文件从硬盘拷贝到用户空间，只进行一次数据拷贝，从而减少了传统的read()方法从硬盘拷贝到内核空间这一步。
3.避免阻塞，优化I/O操作
NIO很多人也称之为Non-block I/O，即非阻塞I/O，因为这样叫，更能体现它的特点。为什么这么说呢？
传统的I/O即使使用了缓冲块，依然存在阻塞问题。由于线程池线程数量有限，一旦发生大量并发请求，超过最大数量的线程就只能等待，直到线程池中有空闲的线程可以被复用。而对Socket的输入流进行读取时，读取流会一直阻塞，直到发生以下三种情况的任意一种才会解除阻塞：
- 有数据可读；
- 连接释放；
- 空指针或I/O异常。
阻塞问题，就是传统I/O最大的弊端。NIO发布后，通道和多路复用器这两个基本组件实现了NIO的非阻塞，下面我们就一起来了解下这两个组件的优化原理。
通道（Channel）
前面我们讨论过，传统I/O的数据读取和写入是从用户空间到内核空间来回复制，而内核空间的数据是通过操作系统层面的I/O接口从磁盘读取或写入。
最开始，在应用程序调用操作系统I/O接口时，是由CPU完成分配，这种方式最大的问题是“发生大量I/O请求时，非常消耗CPU“；之后，操作系统引入了DMA（直接存储器存储），内核空间与磁盘之间的存取完全由DMA负责，但这种方式依然需要向CPU申请权限，且需要借助DMA总线来完成数据的复制操作，如果DMA总线过多，就会造成总线冲突。
通道的出现解决了以上问题，Channel有自己的处理器，可以完成内核空间和磁盘之间的I/O操作。在NIO中，我们读取和写入数据都要通过Channel，由于Channel是双向的，所以读、写可以同时进行。
多路复用器（Selector）
Selector是Java NIO编程的基础。用于检查一个或多个NIO Channel的状态是否处于可读、可写。
Selector是基于事件驱动实现的，我们可以在Selector中注册accpet、read监听事件，Selector会不断轮询注册在其上的Channel，如果某个Channel上面发生监听事件，这个Channel就处于就绪状态，然后进行I/O操作。
一个线程使用一个Selector，通过轮询的方式，可以监听多个Channel上的事件。我们可以在注册Channel时设置该通道为非阻塞，当Channel上没有I/O操作时，该线程就不会一直等待了，而是会不断轮询所有Channel，从而避免发生阻塞。
目前操作系统的I/O多路复用机制都使用了epoll，相比传统的select机制，epoll没有最大连接句柄1024的限制。所以Selector在理论上可以轮询成千上万的客户端。
下面我用一个生活化的场景来举例，看完你就更清楚Channel和Selector在非阻塞I/O中承担什么角色，发挥什么作用了。
我们可以把监听多个I/O连接请求比作一个火车站的进站口。以前检票只能让搭乘就近一趟发车的旅客提前进站，而且只有一个检票员，这时如果有其他车次的旅客要进站，就只能在站口排队。这就相当于最早没有实现线程池的I/O操作。
后来火车站升级了，多了几个检票入口，允许不同车次的旅客从各自对应的检票入口进站。这就相当于用多线程创建了多个监听线程，同时监听各个客户端的I/O请求。
最后火车站进行了升级改造，可以容纳更多旅客了，每个车次载客更多了，而且车次也安排合理，乘客不再扎堆排队，可以从一个大的统一的检票口进站了，这一个检票口可以同时检票多个车次。这个大的检票口就相当于Selector，车次就相当于Channel，旅客就相当于I/O流。
总结
Java的传统I/O开始是基于InputStream和OutputStream两个操作流实现的，这种流操作是以字节为单位，如果在高并发、大数据场景中，很容易导致阻塞，因此这种操作的性能是非常差的。还有，输出数据从用户空间复制到内核空间，再复制到输出设备，这样的操作会增加系统的性能开销。
传统I/O后来使用了Buffer优化了“阻塞”这个性能问题，以缓冲块作为最小单位，但相比整体性能来说依然不尽人意。
于是NIO发布，它是基于缓冲块为单位的流操作，在Buffer的基础上，新增了两个组件“管道和多路复用器”，实现了非阻塞I/O，NIO适用于发生大量I/O连接请求的场景，这三个组件共同提升了I/O的整体性能。
你可以在Github上通过几个简单的例子来实践下传统IO、NIO。
思考题
在JDK1.7版本中，Java发布了NIO的升级包NIO2，也就是AIO。AIO实现了真正意义上的异步I/O，它是直接将I/O操作交给操作系统进行异步处理。这也是对I/O操作的一种优化，那为什么现在很多容器的通信框架都还是使用NIO呢？
期待在留言区看到你的见解。也欢迎你点击“请朋友读”，把今天的内容分享给身边的朋友，邀请他一起学习。
- ZOU志伟 👍（74） 💬（4）
老师，为什么要字符流还是没懂
2019-06-19 - Only now 👍（53） 💬（3）
老师能不能讲讲DMA和Channel的区别, DMA需要占用总线, 那么Channel是如何跳过总线向内存传输数据的?
2019-06-06 - 张学磊 👍（50） 💬（1）
在Linux中，AIO并未真正使用操作系统所提供的异步I/O，它仍然使用poll或epoll，并将API封装为异步I/O的样子，但是其本质仍然是同步非阻塞I/O，加上第三方产品的出现，Java网络编程明显落后，所以没有成为主流
2019-06-06 - 皮皮 👍（28） 💬（1）
老师，个人觉得本期的内容讲的稍微浅了一点，关于IO的几种常见模型可以配图讲一下的，另外就是linux下的select，poll，epoll的对比应用场景。最重要的目前用的最多的IO多路复用可以深入讲一下的。
2019-06-06 - 小兵 👍（14） 💬（1）
很多知识linux 网络 I/O模型底层原理，零拷贝技术等深入讲一下，毕竟学Java性能调优的学员都是有几年工作经验的， 希望老师后面能专门针对这次io 出个补充，这一讲比较不够深入。
2019-06-07 - -W.LI- 👍（13） 💬（6）
老师好!隔壁的李好双老师说一次普通IO需要要进过六次拷贝。 网卡->内核->临时本地内存->堆内存->临时本地内存->内核->网卡。 directbfuffer下 网卡->内核->本地内存->内核->网卡 ARP下C直接调用 文件->内核->网卡。 李老师说的对么? 本地内存和堆内存都是在用户空间的是么?
2019-06-20 - td901105 👍（10） 💬（3）
在少量连接请求的情况下，使用这种方式没有问题，响应速度也很高。但在发生大量连接请求时，就需要创建大量监听线程，这时如果线程没有数据就绪就会被挂起，然后进入阻塞状态。一旦发生线程阻塞，这些线程将会不断地抢夺 CPU 资源，从而导致大量的 CPU 上下文切换，增加系统的性能开销。 后面一句一旦发生线程阻塞，这些线程会不断的抢夺CPU资源，从而导致大量的CPU进行上下文切换，增加系统开销，这一句不是太明白，能解释一下吗？阻塞线程不是不会占用CPU资源吗？
2019-12-04 - 钱 👍（10） 💬（2）
课后思考及问题 1本文核心观点 1-1：JAVA IO操作为啥分为字节流和字符流？我们知道字符到字节必须经过转码，这个过程非常耗时，如果我们不知道编码类型就很容易出现乱码问题。所以 I/O 流提供了一个直接操作字符的接口，方便我们平时对字符进行流操作。 有个疑问，字符流虽然在不知道其编码类型的情况下可以操作，不过一旦需要进行网络传输了，还是必须要知道的？ 1-2：一次读取数据的操作流程，如下 用户空间—请求数据—内核空间—请求数据—数据存储设备—响应数据—内核空间—响应数据—用户空间，应用程序从用户空间的数据缓存区中读取数据，数据以字节流的形式流转。这种方式数据经过了两次复制过程，比较耗性能。 1-3：传统IO耗性能的地方主要有两点，一是数据从从存储设备到应用程序中经历了两次复制，二是数据的处理方式是阻塞式的 1-4：NIO快就快在解决了传统IO的两个耗性能的问题，一是减少复制次数，二是数据处理线程不再阻塞，为此增加了缓存区+通道+多路复用选择器+操作系统数据缓存区 对比来看，感觉老师讲的有点凌乱，IO网络通信模型，我在很多的课程上都学过，这个几乎讲到高性能这一块是必讲的，极客时间里有好几个专栏里也都有讲，大概原理还行，不过体系和细致成度一般，可能是篇幅有限吧! 我见过最通俗易懂的讲解就是netty权威指南的李林峰，用了好几章来讲解这一块的内容。 他从IO的历史演进来讲，一个个IO通信模型是怎么来的？前一个有什么问题？后一个基本是为了解决前一个的问题而来的，以及具体是怎么解决的？ 磁盘或网络IO由于其内部结构决定和内存、各级缓存、CUP的速度有巨大的鸿沟，写操作系统的大神们和JDK的大神都清楚，所以，他们也都在绞尽脑汁来通过其他方式来尽量的解决这些问题。 希望他们的脑汁没没白绞，真心能明白他们绞尽脑汁后都产生了什么牛逼的方案。 非阻塞、零拷贝、多路复用选择器、Reactor、Preactor、DMA、epoll、通道这些概念有些理解啦有些还没，不过性能优化的原则没变还是那一套。
2019-09-07 - 仙道 👍（8） 💬（1）
有两个地方理解不了，请老师指点一下。 1.传统io请求数据没有的话就会挂起进入阻塞状态，既然进入了阻塞状态文中为什么还会说会继续强悍cpu。 2，传统io对文件边读边处理，NIO一次性将文件读到缓冲区，就这样的话问什么说NIO要快？我觉得单是读取的时间花费的是一样的
2019-08-16 - Haies 👍（6） 💬（2）
讲的很精炼，不过有三个问题没明白 1.图2的directbuffer是不是临时直接内存，和文中提到的DirectBuffer应该不是一回事吧。 2.Chanel有自己的处理器，这个何解？ 3.传统I/O使用buffer后，是不是处理单位也变成块了，怎么可以优化阻塞的问题呢，不太明白？
2019-11-24 - 昨夜的柠檬 👍（4） 💬（2）
文中说，多线程阻塞时，会占用大量CPU资源。线程阻塞应该会让出CPU吧？
2020-03-08 - 天星之主 👍（3） 💬（3）
“DirectBuffe直接将步骤简化为从内核空间复制到外部设备，减少了数据拷贝”，direct buffer申请的非堆内存，只是不受JVM管控，不应该还是用户态的内存吗
2019-11-07 - 张三丰 👍（2） 💬（1）
如果单纯使用 Java 堆内存进行数据拷贝，当拷贝的数据量比较大的情况下，Java 堆的 GC 压力会比较大，而使用非堆内存可以减低 GC 的压力。 为何GC压力会比较大呢？只能说是没法回收导致内存泄漏吧。
2020-04-07 - al-byte 👍（2） 💬（1）
我们可以在注册 Channel 时设置该通道为非阻塞，当 Channel 上没有 I/O 操作时，该线程就不会一直等待了，而是会不断轮询所有 Channel，从而避免发生阻塞。 如果一个Channel上I/O耗时很长是不是后续的Channel就被阻塞了？
2019-06-17 - Better me 👍（1） 💬（1）
老师在评论中的下面这段话 阻塞线程在阻塞状态是不会占用CPU资源的，但是会被唤醒争夺CPU资源。操作系统将CPU轮流分配给线程任务，当线程数量越多的时候，当某个线程在规定的时间片运行完之后，会被其他线程抢夺CPU资源，此时会导致上下文切换。抢夺越激烈，上下文切换就越频繁。 这里抢夺越激烈，上下文切换越频繁有点不太理解，如果只是单次抢夺操作，最后不都只有一个线程抢夺到CPU从而进行一次上下文切换吗？还是这里是以抢夺资源的这整段时间维度去衡量理解的
2020-05-24