基础篇--Java IO--概览

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

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

字节流处理所有类型数据，以Stream结尾；
字符流处理文本数据，以Reader、Writer结尾；
Java IO类见下图：

同步、异步、阻塞、非阻塞
synchronous、asynchronous、blocking、non-blocking

同步、异步关注的是消息通信机制
同步，是在发起调用后，在得到结果前，该调用不会返回。等到调用返回后，就能拿到返回值。调用者主动等待调用结果。
异步，是在发起调用后，调用直接返回，所以无返回结果。后续通过状态、回调通知调用者。

阻塞、非阻塞关注的是程序在等待调用结果（返回值、消息）时的状态
阻塞调用，是指在调用结果返回前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。
非阻塞调用，是指在调用结果返回前，该调用不会阻塞当前线程。

换句话说：
同步、异步区别：是否需要等待调用结果，才能进行下一步。
阻塞、非阻塞：进程\线程要访问的数据就绪前，进程\线程是否需要等待。

Linux的5种IO模型

阻塞IO模型
非阻塞IO模型
IO复用模型
信号驱动IO模型
异步IO模型

1.阻塞IO模型
Linux中，默认情况下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类

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

阻塞模式的套接字，开发实现简单。但是并发能力较弱，扩展性弱。

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

3.IO复用模型(IO multiplexing)
IO复用模型又称event driven I/O，是在实际中使用最多的I/O模型。基本原理是select/epoll这个方法不断轮训所负责的socket，当某个socket有数据到达时，就通知用户线程。流程如下：
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
5.异步I/O模型(Asynchronous I/O)
这种模型不常用，流程如下：
异步I/O流程图
用户线程发起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标志位的数据结构来进行下一步处理。这样所带来的缺点是：

单个进程可监视的fd数量被限制，即能监听端口的大小有限：
一般来说这个数目和系统内存关系很大，具体数目可以cat /proc/sys/fs/file-max察看。32位机默认是1024个。64位机默认是2048
对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低：
当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度,不管哪个Socket是活跃的,都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。
需要维护一个用来存放大量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的优点：
没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）
效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。只有活跃可用的FD才会调用callback函数
即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll
内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销