基础篇--Java IO--概览

待我称王封你为后i 2022-03-14 09:08 229阅读 0赞

**字符流、字节流、输入流、输出流**

Java 中使用IO（输入输出）来读取和写入，读写磁盘文件、内存、网络数据。输入输出是相对内存而言，往内存中读数据就为输入流，从内存中往外写就是输出流。  
根据处理类型分为字符流、字节流。

*  字节流处理所有类型数据，以Stream结尾；
 *  字符流处理文本数据，以Reader、Writer结尾；  
    Java IO类见下图：  
    ![Java IO类][Java IO]  
    **同步、异步、阻塞、非阻塞**  
    synchronous、asynchronous、blocking、non-blocking
    
    同步、异步关注的是**消息通信机制**  
    同步，是在发起调用后，在得到结果前，该调用不会返回。等到调用返回后，就能拿到返回值。调用者主动等待调用结果。  
    异步， 是在发起调用后，调用直接返回，所以无返回结果。后续通过状态、回调通知调用者。
    
    阻塞、非阻塞关注的是**程序在等待调用结果（返回值、消息）时的状态**  
    阻塞调用，是指在调用结果返回前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。  
    非阻塞调用，是指在调用结果返回前，该调用不会阻塞当前线程。
    
    换句话说：  
    同步、异步区别：是否需要等待调用结果，才能进行下一步。  
    阻塞、非阻塞：进程\\线程要访问的数据就绪前，进程\\线程是否需要等待。

**Linux的5种IO模型**

1.  阻塞IO模型
2.  非阻塞IO模型
3.  IO复用模型
4.  信号驱动IO模型
5.  异步IO模型

**1.阻塞IO模型**  
Linux中，默认情况下socket是阻塞的，一个典型的读操作流程如下：  
![socket读][socket]  
当用户进程调用了recvfrom这个系统调用，kernel就开始了I/O的第一个阶段：准备数据。对于network io来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包），这个时候kernel就要等待足够的数据到来。而在用户进程这边，整个进程会被阻塞。  
当kernel一直等到数据准备好了，它就会将数据从kernel系统缓冲区中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。所以，blocking IO的特点就是在I/O执行的两个阶段都是block。  
**Windows Socket API**  
socket()函数和WSASocket()函数创建套接字时，默认的套接字是阻塞的。线程会阻塞等待，直到Windows Sockets API执行完成。  
bind()、listen()函数，不会阻塞线程  
可能会阻塞套接字的Windows Socket API调用分为4类

1.  输入操作：recv()、recvfrom()、WSARecv()和WSARecvfrom()函数。以阻塞套接字为参数的该函数接受数据。如果此时套接字缓冲区中无数据，则调用线程一直睡眠到数据到来
2.  输出操作：send()、sendto()、WSASend()和WSASendto()函数。调用该函数发送数据。如果套接字缓冲区无可用空间，则调用线程会一直睡眠到有可用空间。
3.  接受连接：accept()和WSAAcept()函数。以阻塞套接字为参数的该函数等待接受对方的连接请求。无则线程休眠。
4.  外出连接：connect()和WSAConnect()函数。对于TCP连接，客户端以阻塞套接字为参数，调用该函数向服务器发起连接。  
    该函数在接收到服务器的应答前，不会返回。 这意味着TCP连接总会等待至少到服务器的一次往返时间。
    
    阻塞模式的套接字，开发实现简单。但是并发能力较弱，扩展性弱。

**2.非阻塞IO模型**  
Linux下，可以设置socket为non-blocking。这种情况下的读取流程如下：  
![非阻塞IO，读取流程][IO]  
用户进程调用recvfrom()时，如果kernal数据还未准备好，则直接返回error。用户线程不断重试，直到kernal准备好后，就马上将数据拷贝到用户内存，然后返回。**所以这种模式下，用户线程需要不断主动询问kernal数据好了没。**

**3.IO复用模型(IO multiplexing)**  
IO复用模型又称event driven I/O，是在实际中使用最多的I/O模型。基本原理是select/epoll这个方法不断轮训所负责的socket，当某个socket有数据到达时，就通知用户线程。流程如下：  
![I/O复用模型][I_O]  
当用户线程调用select()，整个线程就会block，同时kernal会监听所有select负责的socket，一旦有socket的数据准备好了，select()就会返回。这时候用户线程再去调用read()操作，将数据从kernal拷贝到用户线程。  
当线程数量较少时，这种方式可能比阻塞I/O模型效率更低，因为多了select()操作。**select/epoll的优势是能处理更多的连接，在高并发场景效率更高。**

**4.信号驱动I/O模型(Signal-driven I/O)**  
首先我们需要允许套接字使用信号驱动IO，并安装一个信号处理函数，然后进程继续运行并不阻塞。当数据准备好时，进程会收到一个SIGIO信号，在信号处理函数中调用IO操作函数处理数据。流程如下：（这种模型在实际中并不常用）  
![信号驱动I/O][I_O 1]  
**5.异步I/O模型(Asynchronous I/O)**  
这种模型不常用，流程如下：  
![异步I/O流程图][I_O 2]  
用户线程发起read操作后，立刻就可以去做别的事情。从kernal角度，当它收到一个asynchroous read请求之后，会立刻返回，不会阻塞用户进程。然后kernal等待数据准备完成，将数据拷贝到用户内存，之后给用户进程发送一个signal，告诉它read操作完成了。

**总结**  
1：blocking和non-blocking的区别  
blocking IO会阻塞住对应的进程直到操作完成，non-blocking IO在kernal还未准备好数据的时候，直接返回。

1：synchronous I/O 和asynchronous IO的区别  
区别在于synchronous I/O做I/O操作的时候会将进程阻塞。所以，**blocking I/O**，**non-blocking I/O**，**I/O multiplexing**，**Signal-driven I/O**都属于synchronous I/O，只有**Asynchronous I/O**属于asynchronous IO

**扩展：select、poll、epoll简介**  
epoll跟select都能提供多路I/O复用的解决方案。在现在的Linux内核里有都能够支持，其中epoll是Linux所特有，而select则应该是POSIX所规定，一般操作系统均有实现。  
**1.select**  
select本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理。这样所带来的缺点是：

1.  单个进程可监视的fd数量被限制，即能监听端口的大小有限：  
    一般来说这个数目和系统内存关系很大，具体数目可以cat /proc/sys/fs/file-max察看。32位机默认是1024个。64位机默认是2048
2.  对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低：  
    当套接字比较多的时候，每次select()都要通过遍历FD\_SETSIZE个Socket来完成调度,不管哪个Socket是活跃的,都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。
3.  需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大
    
    **2.poll**  
    poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。  
    **它没有最大连接数的限制，原因是它是基于链表来存储的**，但是同样有一个缺点：
    
        1. 大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义
        2. poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd
    
    **3.epoll**  
    epoll支持水平触发和边缘触发，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就需态，并且只会通知一次。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll\_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll\_wait便可以收到通知。  
    epoll的优点：
4.  **没有最大并发连接的限制**，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）
5.  **效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。只有活跃可用的FD才会调用callback函数**  
    即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll
6.  **内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销**

**select、poll、epoll 区别**

<table> 
 <thead> 
  <tr> 
   <th>select</th> 
   <th>内核需要将消息传递到用户空间，都需要内核拷贝动作</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>poll</td> 
   <td>同上</td> 
  </tr> 
  <tr> 
   <td>epoll</td> 
   <td>epoll通过内核和用户空间共享一块内存来实现</td> 
  </tr> 
 </tbody> 
</table>

4、**Linux I/O模型总结**：

综上，在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自身特点：

1、表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。  
2、select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善

[Java IO]: /images/20220313/77c5eb0220664b8a80ac6d21ee35617e.png
[socket]: /images/20220313/72de8f0e0561417eb9b452f4966588e2.png
[IO]: /images/20220313/75d5c98c4380411596e59fe5d3e46535.png
[I_O]: /images/20220313/88f8f69595da4cb9a1961338a2be4009.png
[I_O 1]: /images/20220313/6421d291745949c5961e5a67c343508a.png
[I_O 2]: /images/20220313/2d4bbdf649e14d908eea8163c274fb9c.png