Java中IO复用.pdfVIP

Java IO 复用 对于服务器的并发处理能力，我们需要的是：每一毫秒服务器都能及时处理这一毫秒内收到的数百个不同 TCP 连接上 的报文，与此同时，可能服务器上还有数以十万计的最近几秒没有收发任何报文的相对不活跃连接。同时处理多个并行发生 事件的连接，简称为并发；同时处理万计、十万计的连接，则是高并发。服务器的并发编程所追求的就是处理的并发连接数 目无限大，同时维持着高效率使用CPU 等资源，直至物理资源首先耗尽。 并发编程有很多种实现模型，最简单的就是与“线程”捆绑，1 个线程处理 1 个连接的全部生命周期。优点：这个模型 足够简单，它可以实现复杂的业务场景，同时，线程个数是可以远大于 CPU 个数的。然而，线程个数又不是可以无限增大的， 为什么呢？因为线程什么时候执行是由操作系统内核调度算法决定的，调度算法并不会考虑某个线程可能只是为了一个连接 服务的，它会做大一统的玩法：时间片到了就执行一下，哪怕这个线程一执行就会不得不继续睡眠。这样来回的唤醒、睡眠 线程在次数不多的情况下，是廉价的，但如果操作系统的线程总数很多时，它就是昂贵的（被放大了），因为这种技术性的 调度损耗会影响到线程上执行的业务代码的时间。举个例子，这时大部分拥有不活跃连接的线程就像我们的国企，它们执行 效率太低了，它总是唤醒就睡眠在做无用功，而它唤醒争到 CPU 资源的同时，就意味着处理活跃连接的民企线程减少获得了 CPU 的机会，CPU 是核心竞争力，它的无效率进而影响了 GDP 总吞吐量。我们所追求的是并发处理数十万连接，当几千个 线程出现时，系统的执行效率就已经无法满足高并发了。 对高并发编程，目前只有一种模型，也是本质上唯一有效的玩法。连接上的消息处理，可以分为两个阶段：等待消息 准备好、消息处理。当使用默认的阻塞套接字时（例如上面提到的 1 个线程捆绑处理 1 个连接），往往是把这两个阶段合而 为一，这样操作套接字的代码所在的线程就得睡眠来等待消息准备好，这导致了高并发下线程会频繁的睡眠、唤醒，从而影 响了 CPU 的使用效率。 高并发编程方法当然就是把两个阶段分开处理。即，等待消息准备好的代码段，与处理消息的代码段是分离的。当然， 这也要求套接字必须是非阻塞的，否则，处理消息的代码段很容易导致条件不满足时，所在线程又进入了睡眠等待阶段。那 么问题来了，等待消息准备好这个阶段怎么实现？它毕竟还是等待，这意味着线程还是要睡眠的！解决办法就是，主动查询， 或者让 1 个线程为所有连接而等待！这就是 IO 多路复用了。多路复用就是处理等待消息准备好这件事的，但它可以同时处 理多个连接！它也可以“等待”，所以它也可能导致线程睡眠，然而这不要紧，因为它一对多、它可以监控所有连接。这样， 当我们的线程被唤醒执行时，就一定是有一些连接准备好被我们的代码执行了，这是有效率的！没有那么多个线程都在争抢 处理“等待消息准备好”阶段，整个世界终于清净了！ 多路复用有很多种实现，在 linux 上，2.4 内核前主要是select 和 poll ，现在主流是epoll ，它们的使用方法似乎很不 同，但本质是一样的。 效率却也不同 ，这也是epoll 完全替代了 select 的原因。 简单的谈下 epoll 为何会替代 select。 前面提到过，高并发的核心解决方案是 1 个线程处理所有连接的“等待消息准备好”，这一点上 epoll 和 select 是无争议的。 但 select 预估错误了一件事，就像我们开篇所说，当数十万并发连接存在时，可能每一毫秒只有数百个活跃的连接，同时其 余数十万连接在这一毫秒是非活跃的。select 的使用方法是这样的： 返回的活跃连接 ==select （全部待监控的连接） 什么时候会调用 select 方法呢？在你认为需要找出有报文到达的活跃连接时，就应该调用。所以，调用 select 在高并发时是 会被频繁调用的。这样，这个频繁调用的方法就很有必要看看它是否有效率，因为，它的轻微效率损失都会被“频繁”二字 所放大。它有效率损失吗？显而易见，全部待监控连接是数以十万计的，返回的只是数百个活跃连接，这本身就是无效率的 表现。被放大后就会发现，处理并发上万个连接时，select 就完全力不从心了。 看几个图。当并发连接为一千以下，select 的执行次数不算频繁，与 epoll 似乎并无多少差距： 1 / 4 然而，并发数一旦上去，select 的缺点被“执行频繁