在 Java 中总共有三种 IO 类型：BIO（Blocking I/O，阻塞I/O）、NIO（Non-blocking I/O，非阻塞I/O）和 AIO（Asynchronous I/O，异步I/O），它们的区别如下：
- 在 JDK 1.4 之前，只有 BIO 一种模式，其开发过程相对简单，新来一个连接就会创建一个新的线程处理，但随着请求并发度的提升，BIO 很快遇到了性能瓶颈。
- 所以在 JDK 1.4 以后开始引入了 NIO 技术，NIO 可以在一个线程中处理多个 IO 操作，提高了资源的利用率和系统的吞吐量。
- 而到了 JDK 1.7 发布了 AIO 模型，它可以实现当线程发起一个 IO 操作后，可以直接返回，无需等待 IO 操作完成。操作系统会在整个 IO 操作完成后，通过回调函数通知应用程序。
1.空轮询和CPU100%
然而，随着 NIO 逐渐使用，人们却发现了 NIO 的一个经典问题，也就是臭名昭著的 Epoll（多路复用实现技术）空轮询的问题。
空轮询的问题是指，在 Linux 系统下，使用 Java 中的 NIO 时，即使 Selector（多路复用器）轮询结果为空，也没有 wakeup 或新消息要处理时，NIO 依旧会进行空轮询，导致 CPU 一直上升，最终造成 CPU 使用率 100% 的问题。
该 BUG 相关可以参见以下链接：
2.空轮询的原因
空轮询产生的原因可以在 bugs.java.com/bugdatabase... 上找到答案，例如以下就是一个经典的 bug 复现场景：
arduino
A DESCRIPTION OF THE PROBLEM :
The NIO selector wakes up infinitely in this situation..
0. server waits for connection
1. client connects and write message
2. server accepts and register OP_READ
3. server reads message and remove OP_READ from interest op set
4. client close the connection
5. server write message (without any reading.. surely OP_READ is not set)
6. server's select wakes up infinitely with return value 0也就说，当连接出现了 RST（强制连接关闭），因为 poll 和 epoll 对于突然中断的连接 Socket 会对返回的 eventSet 事件集合置为 POLLHUP 或者 POLLERR，eventSet 事件集合发生了变化，这就导致 Selector 会被唤醒，进而导致 CPU 100% 问题，其根本原因就是 JDK 没有处理好这种情况，比如 SelectionKey 中就没定义有异常事件的类型，导致异常无法被捕捉和处理，从而一直空轮询。
3.如何解决空轮询？
NIO 空轮询可能会导致 CPU 100% 的解决方案通常有以下两种：
- 升级 Java 版本：早期的 JDK 版本中（JDK 1.7 之前），这个 bug 较为常见，但后续的 JDK 更新中，Oracle 和 OpenJDK 团队已经着手解决了这一问题，确保使用最新的 Java 版本可以减少遇到此问题的风险。但网上依然有人发现即使在 JDK 1.8 中，使用原生的 NIO 依然会发生空轮询的问题，只是发生的概率变低了而已。
- 使用第三方库：对于无法升级 Java 版本的情况，或担心新版本的 JDK 中依然存在空轮询问题的团队可以考虑使用已经解决了此问题的第三方库，如 Netty。Netty 通过主动检测和处理空轮询情况，当检测到可能的空轮询时，会采取措施如临时增加 Selector 的等待时间，或者重建 Selector，以此来避免 CPU 资源的浪费。
课后思考
说说 Netty 解决空轮询的具体实现细节？为什么重建 Selector 可以避免空轮询呢？
本文已收录到我的面试小站 www.javacn.site，其中包含的内容有：Redis、JVM、并发、并发、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、设计模式、消息队列等模块。