zoukankan      html  css  js  c++  java

  • 阻塞IO和非阻塞IO

    阻塞IO

    传统的阻塞IO

    listenfd = socket();   // 打开一个网络通信端口
bind(listenfd);        // 绑定
listen(listenfd);      // 监听
while(1) {
  connfd = accept(listenfd);  // 阻塞建立连接
  int n = read(connfd, buf);  // 阻塞读数据
  doSomeThing(buf);  // 利用读到的数据做些什么
  close(connfd);     // 关闭连接，循环等待下一个连接
}

    image

    服务端的线程阻塞在了两个地方，一个是 accept 函数，一个是 read 函数。

    Read函数的细节，阻塞两次，第一次是等待文件描述符就绪（网卡->内核缓冲区），第二阶段是读取数据(内核缓冲区->用户缓冲区)。

    image

    整体流程

    image

    多线程阻塞IO

    每次都创建一个新的进程或线程，去调用 read 函数，并做业务处理。

    while(1) {
  connfd = accept(listenfd);  // 阻塞建立连接，建立一个连接后会阻塞等待下一个连接，第二阶段的读取阻塞交给子线程处理。
  pthread_create（doWork);  // 创建一个新的线程
}
void doWork() {
  int n = read(connfd, buf);  // 阻塞读数据
  doSomeThing(buf);  // 利用读到的数据做些什么
  close(connfd);     // 关闭连接，循环等待下一个连接
}

    这样，当给一个客户端建立好连接后，就可以立刻等待新的客户端连接，而不用阻塞在原客户端的read请求上。
    image

    但是，这并不叫非阻塞IO，仅仅用了多线程的手段使得主线程没有卡在read函数上不往下走。操作系统为我们提供的read函数仍然是阻塞的。

    真正的非阻塞IO，不是能通过用户层的小把戏，而是要恳请操作系统为我们提供一个非阻塞的read函数。
    这个非阻塞IO的read函数的效果是如果没有数据到达时（到达网卡并拷贝到了内核缓冲区），立刻返回一个错误值（-1），而不是阻塞地等待。

    非阻塞IO

    操作系统提供了非阻塞IO功能，只需要在调用read前，将文件描述符设置为非阻塞即可。

    fcntl(connfd, F_SETFL, O_NONBLOCK);
int n = read(connfd, buffer) != SUCCESS);

    这样，就需要用户线程循环调用read，直到返回值不为-1，再开始处理业务。
    image
    非阻塞的read只有一个阻塞阶段，在数据到达前，即数据还未到达网卡或者到达网卡但还没有拷贝到内核缓冲区之前，这个阶段是非阻塞的。
    当数据已到达内核缓冲区，此时调用read函数仍然是阻塞的，需要等待数据从内核缓冲区拷贝到用户缓冲区，才能返回。
    image

    IO多路复用

    阻塞IO，为每个客户端创建一个线程，服务器端的线程资源很容易被耗光。
    image

    非阻塞IO，每accept一个客户端连接后，将这个文件描述符（connfd）放到一个数组里。

    fdlist.add(connfd);

    然后起一个新的线程去不断遍历这个数组，调用每一个元素的非阻塞read方法。

    while(1) {
  for(fd <-- fdlist) {
    if(read(fd) != -1) {
      doSomeThing();
    }
  }
}

    这样就成功用一个线程处理了多个客户端连接。
    image

    有点多路复用的意思，但这和我们用多线程去将阻塞IO改造成看起来是非阻塞IO一样，这种遍历方式也只是我们用户自己想出的小把戏，每次遍历遇到read返回-1时仍然是一次浪费资源的系统调用。

    所以，还是得恳请操作系统，提供一个函数，将一批文件描述符通过一次系统调用传给内核，由内核层去遍历，才能真正解决这个问题。

    select

    select是操作系统提供的系统调用函数，通过它，我们可以把一个文件描述符的数组发给操作系统，让操作系统去遍历，确定哪个文件描述符可以读写，然后告诉我们去处理：
    select系统调用的函数定义：

    int select(
    int nfds,
    fd_set *readfds,
    fd_set *writefds,
    fd_set *exceptfds,
    struct timeval *timeout);
// nfds:监控的文件描述符集里最大文件描述符加1
// readfds：监控有读数据到达文件描述符集合，传入传出参数
// writefds：监控写数据到达文件描述符集合，传入传出参数
// exceptfds：监控异常发生达文件描述符集合, 传入传出参数
// timeout：定时阻塞监控时间，3种情况
//  1.NULL，永远等下去
//  2.设置timeval，等待固定时间
//  3.设置timeval里时间均为0，检查描述字后立即返回，轮询

    服务端代码
    首先一个线程不断接受客户端连接，并把socket文件描述符放到一个 list 里。

    while(1) {
  connfd = accept(listenfd);
  fcntl(connfd, F_SETFL, O_NONBLOCK);
  fdlist.add(connfd);
}

    然后，另一个线程不再自己遍历，而是调用select，将这批文件描述符list交给操作系统去遍历。

    while(1) {
  // 把一堆文件描述符 list 传给 select 函数
  // 有已就绪的文件描述符就返回，nready 表示有多少个就绪的
  nready = select(list);
  ...
}

    当select函数返回后，用户依然需要遍历刚刚提交给操作系统的 list。
    只不过，操作系统会将准备就绪的文件描述符做上标识，用户层将不会再有无意义的系统调用开销。

    while(1) {
  nready = select(list);   //阻塞，当有文件描述符就绪时才会返回已就绪数量
  // 用户层依然要遍历，只不过少了很多无效的系统调用
  for(fd <-- fdlist) {
    if(fd != -1) {
      // 只读已就绪的文件描述符
      read(fd, buf);
      // 总共只有 nready 个已就绪描述符，不用过多遍历
      if(--nready == 0) break;
    }
  }
}

    select细节

    1. select 调用需要传入 fd 数组，需要拷贝一份到内核，高并发场景下这样的拷贝消耗的资源是惊人的。（可优化为不复制）
    2. select 在内核层仍然是通过遍历的方式检查文件描述符的就绪状态，是个同步过程，只不过无系统调用切换上下文的开销。（内核层可优化为异步事件通知）
    3. select 仅仅返回可读文件描述符的个数，具体哪个可读还是要用户自己遍历。（可优化为只返回给用户就绪的文件描述符，无需用户做无效的遍历）

    select流程
    image

    这种方式，既做到了一个线程处理多个客户端连接（文件描述符），又减少了系统调用的开销（多个文件描述符只有一次select的系统调用 +n次就绪状态的文件描述符的read系统调用）。

    poll

    poll 也是操作系统提供的系统调用函数。

    int poll(struct pollfd *fds, nfds_tnfds, int timeout);

struct pollfd {
  intfd; /*文件描述符*/
  shortevents; /*监控的事件*/
  shortrevents; /*监控事件中满足条件返回的事件*/
};

    它和select的主要区别就是，去掉了select只能监听 1024 个文件描述符的限制。

    epoll

    epoll是最终的大boss，它解决了select和poll的一些问题。

    select的三个细节：

    1. select 调用需要传入 fd 数组，需要拷贝一份到内核，高并发场景下这样的拷贝消耗的资源是惊人的。（可优化为不复制）
    2. select 在内核层仍然是通过遍历的方式检查文件描述符的就绪状态，是个同步过程，只不过无系统调用切换上下文的开销。（内核层可优化为异步事件通知）
    3. select 仅仅返回可读文件描述符的个数，具体哪个可读还是要用户自己遍历。（可优化为只返回给用户就绪的文件描述符，无需用户做无效的遍历）。

    epoll改进select三个细节

    1. 内核中保存一份文件描述符集合，无需用户每次都重新传入，只需告诉内核修改的部分即可。
    2. 内核不再通过轮询的方式找到就绪的文件描述符，而是通过异步IO事件唤醒。
    3. 内核仅会将有IO事件的文件描述符返回给用户，用户也无需遍历整个文件描述符集合。

    具体，操作系统提供了这三个函数。
    第一步，创建一个 epoll 句柄

    int epoll_create(int size);

    第二步，向内核添加、修改或删除要监控的文件描述符。

    int epoll_ctl(
  int epfd, int op, int fd, struct epoll_event *event);

    第三步，类似发起了select()调用

    int epoll_wait(
  int epfd, struct epoll_event *events, int max events, int timeout);

    epoll流程
    image

    总结

    一切的开始，都起源于这个 read 函数是操作系统提供的，而且是阻塞的，我们叫它 阻塞 IO。
    为了破这个局，程序员在用户态通过多线程来防止主线程卡死。
    后来操作系统发现这个需求比较大，于是在操作系统层面提供了非阻塞的 read 函数，这样程序员就可以在一个线程内完成多个文件描述符的读取，这就是 非阻塞 IO。
    但多个文件描述符的读取就需要遍历，当高并发场景越来越多时，用户态遍历的文件描述符也越来越多，相当于在 while 循环里进行了越来越多的系统调用。
    后来操作系统又发现这个场景需求量较大，于是又在操作系统层面提供了这样的遍历文件描述符的机制，这就是 IO 多路复用。
    多路复用有三个函数，最开始是 select，然后又发明了 poll 解决了 select 文件描述符的限制，然后又发明了 epoll 解决 select 的三个不足。

    多路复用产生的效果，完全可以由用户态去遍历文件描述符并调用其非阻塞的 read 函数实现。而多路复用快的原因在于，操作系统提供了这样的系统调用，使得原来的 while 循环里多次系统调用，变成了一次系统调用 + 内核层遍历这些文件描述符。
    就好比我们平时写业务代码，把原来 while 循环里调 http 接口进行批量添加，改成了让对方提供一个批量添加的 http 接口，然后我们一次 rpc 请求就完成了批量添加。

    参考：
    https://mp.weixin.qq.com/s/YdIdoZ_yusVWza1PU7lWaw
    http://www.pulpcode.cn/2017/02/01/user-buffer-and-kernel-buffer/
    https://mp.weixin.qq.com/s?__biz=MjM5Njg5NDgwNA==&mid=2247484905&idx=1&sn=a74ed5d7551c4fb80a8abe057405ea5e&chksm=a6e304d291948dc4fd7fe32498daaae715adb5f84ec761c31faf7a6310f4b595f95186647f12&scene=21#wechat_redirect

    如果这篇文章对你有用，麻烦关注一下本人微信公众号~
    微信公众号二维码
  • 相关阅读:
    IBatisNet基础组件
    IBatis 简易框架搭建
    JQuery 如何选择带有多个class的元素
    ASP.net MVC自定义错误处理页面的方法
    Console的使用——Google Chrome代码调试
    关闭 Visual Studio 2013 的 Browser Link 功能
    VS2013自带的Browser Link功能引发浏览localhost网站时不停的轮询
    JSON.parse()和JSON.stringify()
    Jquery easyui tree的使用
    EasyUI Tree判断节点是否是叶
  • 原文地址：https://www.cnblogs.com/aeolian/p/15151037.html
Copyright © 2011-2022 走看看