浅谈select-epoll

今天的话题还是得从最开始的IO开始。哈哈！

我们都知道，在linux系统中，IO的操作和下面两个操作密不可分：

用户态和内核态切换。

内核缓冲区和进程缓冲区(用户态缓冲区)。

我们编写的应用程序在进行IO的操作时，系统调用read() 和 write()。

调用read函数：

用户态->内核态，数据会从磁盘拷贝到内核缓冲区。

内核态->用户态，数据从内核缓冲区拷贝到进程缓冲区进行操作。

调用write函数：

用户态->内核态：数据从进程缓冲区 -> 内核缓冲区。

数据从内核缓冲区 -> 网卡或磁盘。内核态->用户态 ，程序返回结果。

综上：一次普通网络IO操作需要4次状态切换以及4次数据拷贝。以上只是操作系统底层流程，至于具体代码(欢迎去看linux源码)。

在Java中，几种主要的IO模型：

1.阻塞性IO(BIO,NIO).

首先理解一下这个阻塞：

   1.指的是内存缓冲区和用户缓冲区进行数据交换的时候(具体的读写)阻塞。

   2.在等待内核缓冲区数据时线程阻塞。(BIO)

BIO：

NIO和BIO的区别和相同点：

1.在内核缓冲区没有数据时，不会发生阻塞，会立马返回结果，后期通过轮询非方式询问结果。

2.如果调用read函数，此时内核缓冲区存在数据，则会和BIO一样，阻塞，线程挂起，读取数据。

BIO程序相对简易，在阻塞等待数据期间，用户线程挂起，期间基本不会占用CPU。但是一般情况下，每个请求需要单独分配一个单独的线程，在高并发的场景下开销非常大。因此高并发场景下几乎不可用。（死等）

NIO程序在无数据的时候不需要挂起，轮询数据是否准备好，直到完成系统调用为止，实时性较好，但是不断的轮询会使CPU空转，占用较多CPU时间片。这种模型在大流量冲击下几乎不可用。（一直问好了吗，好了吗）

还有一种是好了，通知对方