前言
进行总结的初衷是没搞明白linux下的select/poll/epoll与java下nio的selector多路复用器的关系，于是对知识点进行了梳理。
先上结论，selector多路复用器算是对linux下的select/poll/epoll进行封装，selector可以i有多种实现，linux系统下默认使用epoll的实现方式。
BIO模型
https://www.jianshu.com/p/138847d5cafd
BIO即为阻塞IO的意思，通常我们讲BIO的时候都会和服务器模型配合着讲，在实际应用中讲会更好理解。大家看下面的代码，估计在大家初学java网络编程的时候用的都是这个模型：
什么是BIO，NIO？他们和多路复用器有啥关系？
只要没有客户端连接上服务器，accept方法就一直不能返回，这就是阻塞；对应的读写操作道理也一样，想要读取数据，必须等到有数据到达才能返回，这就是阻塞。
我们还可以站在阻塞的基础上思考一下，为什么服务器的模型要设计成来一个客户端就新建一个线程？
其实答案很简单，当来了一个客户端创建连接后，如果不给客户端新分配一个线程执行服务器逻辑，那么服务端将很难再和第二个客户端建立连接。
就算你把客户端连接用集合保存起来，通过单线程遍历集合的方式去执行服务器端逻辑也是不行的。因为如果某个客户端连接因为读写操作阻塞了，那么其他客户端将得不到执行。
优点：
每个连接创建一个线程，实现了一个服务器连接多个客户端
缺点：
1.每处理一个请求就要new一个线程，而cpu是不会停止的，时间片轮调度各个线程切换（系统计时器发出时钟中断，调度程序停止该进程运行并把进程放到就绪队列末尾），上下文切换浪费时间，并且线程多消耗内存。并且太多系统调用（用户态到内核态）。系统调用：socket监听端口，客户端accpet，创建线程，客户端读取都是系统调用
2.很多线程其实是在等数据（阻塞），是一个无用的线程
没用多路复用的NIO模型
如果说服务器只有很少的人用，那么上面那段bio的代码其实挺好的，但问题在于互联网蓬勃发展，随着服务器访问人数的增加，这样的服务器模型将会成为瓶颈。
我们以一种C10K的思想去看待上面这段服务器代码。如果我们客户端的连接数增加了10K倍，那么就意味着要创建10k个线程，单单创建线程就是一项不小的开销了，再加上线程之间要来回切换，单机服务器根本就扛不住这么大的连接数。
那既然瓶颈是出在线程上，我们就考虑能不能把服务器的模型变为单线程模型，思路其实和之前说的差不多，用集合保存每个连接的客户端，通过while循环来对每个连接进行操作。
之前我们说了这样的操作瓶颈在于accept客户端的时候会阻塞，以及进行读写操作的时候会阻塞，导致单线程执行效率低。为了突破这个瓶颈，操作系统发展出了nio，这里的nio指的是非阻塞io。
也就是说在accept客户端连接的时候，不需要阻塞，如果没有客户端连接就返回-1（java-NULL），在读写操作的时候，也不阻塞，有数据就读，没数据就直接返回，这样就解决了单线程服务器的瓶颈问题。示例代码如下：
优点：
相比于BIO，客户端的accept和客户端读取都是非阻塞的
缺点：
在客户端与服务器建立连接后，后续会进行一系列的读写操作。虽然这些读写操作是非阻塞的，但是每调一次读写操作在操作系统层面都要进行一次用户态和内核态的切换，这个也是一项巨大的开销（读写等系统调用都是在内核态完成的）。
什么是BIO，NIO？他们和多路复用器有啥关系？
引入多路复用器
尽管上面的单线程NIO服务器模型比BIO的优良许多，但是仍然有一个大问题。在客户端与服务器建立连接后，后续会进行一系列的读写操作。虽然这些读写操作是非阻塞的，但是每调一次读写操作在操作系统层面都要进行一次用户态和内核态的切换，这个也是一项巨大的开销（读写等系统调用都是在内核态完成的）。
在上面的代码中每次循环遍历都进行读写操作，我们以读操作为例：大部分读操作都是在数据没有准备好的情况下进行读的，相当于执行了一次空操作。我们要想办法避免这种无效的读取操作，避免内核态和用户态之间的频繁切换。
补充：客户端与服务器两端都是通过socket进行连接的，socket在linux操作系统中有对应的文件描述符（fd），我们的读写操作都是以该文件描述符为单位进行操作的。
为了避免上述的无效读写，我们得想办法得知当前的文件描述符是否可读可写。如果逐个文件描述符去询问，那么效率就和直接进行读写操作差不多了，我们希望有一种方法能够一次性得知哪些文件描述符可读，哪些文件描述符可写，这，就操作系统后来发展出的多路复用器。
也就是说，**多路复用器的核心功能就是告诉我们哪些文件描述符可读，哪些文件描述符可写。**而多路复用器也分为几种，他们也经历了一个演化的过程。最初的多路复用器是select模型，它的模式是这样的：程序端每次把文件描述符集合交给select的系统调用，select遍历每个文件描述符后返回那些可以操作的文件描述符，然后程序对可以操作的文件描述符进行读写。
它的弊端是，一次传输的文件描述符集合有限，只能给出1024个文件描述符，poll在此基础上进行了改进，没有了文件描述符数量的限制。
但是select和poll在性能上还可以优化，它们共同的弊端在于：
- 它们需要在内核中对所有传入的文件描述符进行遍历，这也是一项比较耗时的操作
- （这点是否存在优化空间有待考证）每次要把文件描述符从用户态的内存搬运到内核态的内存，遍历完成后再搬回去，这个来回复制也是一项耗时的操纵。
后来操作系统加入了epoll这个多路复用器，彻底解决了这个问题：
epoll多路复用器的模型是这样的：
为了在发起系统调用的时候不遍历所有的文件描述符，epoll的优化在于：当数据到达网卡的时候，会触发中断，正常情况下cpu会把相应的数据复制到内存中，和相关的文件描述符进行绑定。epoll在这个基础之上做了延伸，epoll首先是在内核中维护了一个红黑树，以及一些链表结构，当数据到达网卡拷贝到内存时会把相应的文件描述符从红黑树中拷贝到链表中，这样链表存储的就是已经有数据到达的文件描述符，这样当程序调用epoll_wait的时候就能直接把能读的文件描述符返回给应用程序。
除了epoll_wait之外，epoll还有两个系统调用，分别是epoll_create和epoll_ctl，分别用于初始化epoll和把文件描述符添加到红黑树中。
以上就是多路复用器与常见io模型的关系了，网上常常有文章把多路复用器说成是nio的一部分，我觉得也是合理的，因为在具体编程的时候两个概念往往会融为一体。
select、poll和epoll
https://www.zhihu.com/question/32163005/answer/1802684879
一张图总结一下select,poll,epoll的区别：
| select | poll | epoll | |
|---|---|---|---|
| 操作方式 | 遍历 | 遍历 | 回调 |
| 底层实现 | 数组 | 链表 | 红黑树 |
| IO效率 | 每次调用都进行线性遍历，时间复杂度为O(n) | 每次调用都进行线性遍历，时间复杂度为O(n) | 事件通知方式，每当fd就绪，系统注册的回调函数就会被调用，将就绪fd放到readyList里面，时间复杂度O(1) |
| 最大连接数 | 1024（x86）或2048（x64） | 无上限 | 无上限 |
| fd拷贝 | 每次调用select，都需要把fd集合从用户态拷贝到内核态，再拷贝回用户态 | 每次调用poll，都需要把fd集合从用户态拷贝到内核态，再拷贝回用户态 | 调用epoll_ctl时拷贝进内核并保存，之后每次epoll_wait不拷贝 |
epoll是Linux目前大规模网络并发程序开发的首选模型。在绝大多数情况下性能远超select和poll。目前流行的高性能web服务器Nginx正式依赖于epoll提供的高效网络套接字轮询服务。但是，在并发连接不高的情况下，多线程+阻塞I/O方式可能性能更好。
select
select 实现多路复用的方式是，将已连接的 Socket 都放到一个文件描述符集合，然后调用 select 函数将文件描述符集合拷贝到内核里，让内核来检查是否有网络事件产生，检查的方式很粗暴，就是通过遍历文件描述符集合的方式，当检查到有事件产生后，将此 Socket 标记为可读或可写， 接着再把整个文件描述符集合拷贝回用户态里，然后用户态还需要再通过遍历的方法找到可读或可写的 Socket，然后再对其处理。
所以，对于 select 这种方式，需要进行 2 次「遍历」文件描述符集合，一次是在内核态里，一个次是在用户态里 ，而且还会发生 2 次「拷贝」文件描述符集合，先从用户空间传入内核空间，由内核修改后，再传出到用户空间中。
select 使用固定长度的 BitsMap，表示文件描述符集合，而且所支持的文件描述符的个数是有限制的，在 Linux 系统中，由内核中的 FD_SETSIZE 限制， 默认最大值为 1024，只能监听 0~1023 的文件描述符。
poll
poll 不再用 BitsMap 来存储所关注的文件描述符，取而代之用动态数组，以链表形式来组织，突破了 select 的文件描述符个数限制，当然还会受到系统文件描述符限制。
但是 poll 和 select 并没有太大的本质区别，都是使用「线性结构」存储进程关注的 Socket 集合，因此都需要遍历文件描述符集合来找到可读或可写的 Socket，时间复杂度为 O(n)，而且也需要在用户态与内核态之间拷贝文件描述符集合，这种方式随着并发数上来，性能的损耗会呈指数级增长。
epoll
epoll 通过两个方面，很好解决了 select/poll 的问题。
第一点，epoll 在内核里使用红黑树来跟踪进程所有待检测的文件描述字，把需要监控的 socket 通过 epoll_ctl() 函数加入内核中的红黑树里，红黑树是个高效的数据结构，增删查一般时间复杂度是 O(logn)，通过对这棵黑红树进行操作，这样就不需要像 select/poll 每次操作时都传入整个 socket 集合，只需要传入一个待检测的 socket，减少了内核和用户空间大量的数据拷贝和内存分配。
第二点， epoll 使用事件驱动的机制，内核里维护了一个链表来记录就绪事件，当某个 socket 有事件发生时，通过回调函数内核会将其加入到这个就绪事件列表中，当用户调用 epoll_wait() 函数时，只会返回有事件发生的文件描述符的个数，不需要像 select/poll 那样轮询扫描整个 socket 集合，大大提高了检测的效率。
从下图你可以看到 epoll 相关的接口作用：
epoll 的方式即使监听的 Socket 数量越多的时候，效率不会大幅度降低，能够同时监听的 Socket 的数目也非常的多了，上限就为系统定义的进程打开的最大文件描述符个数。因而，epoll 被称为解决 C10K 问题的利器。
插个题外话，网上文章不少说，epoll_wait 返回时，对于就绪的事件，epoll使用的是共享内存的方式，即用户态和内核态都指向了就绪链表，所以就避免了内存拷贝消耗。
这是错的！看过 epoll 内核源码的都知道，压根就没有使用共享内存这个玩意。你可以从下面这份代码看到， epoll_wait 实现的内核代码中调用了 __put_user函数，这个函数就是将数据从内核拷贝到用户空间。
Java中的Selector
其实Java已经为我们把多路复用器用Selector类给封装起来了，我们完全可以基于Selector进行NIO服务器开发。但是我们自己写nio服务器可能不够严谨，Java届有一款优秀nio框架，名叫Netty。
Java中的Selector是对select 、poll和epoll的封装，对程序员的视图是一样的，屏蔽了底层实现细节。但open、register和select函数在底层上是有区别的。
参考https://www.zhihu.com/question/343373314
以下图为例，多路复用器（selector）的底层实现是可选择的，不同平台可以不同，以Linux系统为例，默认使用使用 epoll 实现 ，早期的 NIO 采用 select 到 poll 进行演化，实质上是对每个链接循环检测是否有数据发送，性能较低。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ccp6bF0b-1616842230471)(https://i.loli.net/2021/03/27/TeyrJNS9gbfh75n.png)]
Java用Selector实现NIO
什么是 NIO？
NIO 是 JDK1.4 引入的同步非阻塞 IO。服务器实现模式为多个连接请求对应一个线程，客户端连接请求会注册到一个多路复用器 Selector ，Selector 轮询到连接有 IO 请求时才启动一个线程处理。适用连接数目多且连接时间短的场景。
同步是指线程还是要不断接收客户端连接并处理数据，非阻塞是指如果一个管道没有数据，不需要等待，可以轮询下一个管道。
核心组件：
-
Selector： 多路复用器，轮询检查多个 Channel 的状态，判断注册事件是否发生，即判断 Channel 是否处于可读或可写状态。使用前需要将 Channel 注册到 Selector，注册后会得到一个 SelectionKey，通过 SelectionKey 获取 Channel 和 Selector 相关信息。
-
Channel： 双向通道，替换了 BIO 中的 Stream 流，不能直接访问数据，要通过 Buffer 来读写数据，也可以和其他 Channel 交互。
-
Buffer： 缓冲区，本质是一块可读写数据的内存，用来简化数据读写。Buffer 三个重要属性：position 下次读写数据的位置，limit 本次读写的极限位置，capacity 最大容量。
flip将写转为读，底层实现原理把 position 置 0，并把 limit 设为当前的 position 值。clear将读转为写模式（用于读完全部数据的情况，把 position 置 0，limit 设为 capacity）。compact将读转为写模式（用于存在未读数据的情况，让 position 指向未读数据的下一个）。- 通道方向和 Buffer 方向相反，读数据相当于向 Buffer 写，写数据相当于从 Buffer 读。
使用步骤：向 Buffer 写数据，调用 flip 方法转为读模式，从 Buffer 中读数据，调用 clear 或 compact 方法清空缓冲区。
Java NIO 的核心组件
Java NIO 有以下几个核心组件：
- Channels
- Buffers
- Selectors
1、Channel 和 Buffer
Buffer 本质是一个数组,发送到Channel中的所有对象必须放到Buffer中，从Channel读取数据的时候也是把数据放到Buffer中，然后从Buffer中读取。
通常，NIO 中的所有 IO 都从 Channel 开始，Channel 有点类似于 Stream。数据可以从 Channel 读到一个 Buffer 中，也可以从一个 Buffer 写入到一个 Channel 中，如下图所示：
Channel 和 Buffer 有很多种类型，下面是 Java NIO 中 Channel 的主要实现类：
- FileChannel
- DatagramChannel
- SocketChannel
- ServerSocketChannel
可以看到，这些 Channel 涵盖了 UDP 和 TCP 的网络 IO 以及文件的 IO。伴随着这些类的还有一些有意思的接口，简单起见这里不做赘述。
下面是 Java NIO 中 Buffer 的主要实现类：
- ByteBuffer
- CharBuffer
- DoubleBuffer
- FloatBuffer
- IntBuffer
- LongBuffer
- ShortBuffer
这些 Buffer 涵盖了可以通过 IO 传输的基本数据类型：byte、short、int、long、float、double 和 characters。
Java NIO 中还有个 MappedByteBuffer，用于内存映射文件。
2、Selectors
Selector（选择器）是Java NIO中能够检测一到多个NIO通道，并能够知晓通道是否为诸如读写事件做好准备的组件。使用Selector来实现 一个单独的线程可以管理多个channel，从而管理多个网络连接。
一个 Selector 允许一个线程处理多个 Channel (的事件)，这对于应用程序中打开了很多个连接(Channel)，但连接中数据传输并不频繁时会很有帮助。例如一个聊天服务器。这有一个线程使用一个 Selector 同时处理3个 Channel 的示意图：
使用 Selector 时需要将 Channel 注册到 Selector 上，然后调用 Selector 的select()方法。这个方法会一直阻塞直到注册的某个 Channel 的某个 event 就绪，一旦这个方法 return，线程就会处理这些事件。这里说的事件有新连接的到来，数据的接收等。
871
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
