聊聊IOCP，聊聊异步编程

前言

IO完成端口（IO completion ports）在多核计算机的并行异步IO请求方面提供了一种高效的线程模型。当进程创建一个IO完成端口时，系统创建一个相关联的队列，其唯一目的是服务与那些请求。IO完成端口通常和预先分配的线程池配合，相比于一个一个创建线程，这使其更快更高效。IOCP在进程之间并不共享，一个IOCP及其句柄只和创建它的进程关联，但是一个进程中的多个线程可共享。IOCP最关键的地方就是，IOCP在IO请求和接收动作完成之后，激活线程池中的任意线程继续操作，而不是在IO请求和接受完成之后，激活原等待中的线程。这样的好处是防止等待线程闲置，和必须激活／切换到原等待线程的开销。

 

大多应用存在的问题

曾见过很多服务，几台，几十台，几百台服务器的，它们cpu大多数时间处于空闲状态，也许需要大量计算的应用并没有那么多，我们常见的应用大多主要读写关系数据库，读写内存数据库／缓存，RPC调用接口。IO耗时过多，CPU大量闲置，导致没看到服务器资源大量消耗，便已不能承受日益增加的访问量，再加服务器，依然大量浪费了资源。 CPU资源昂贵，每一个核心，同一时刻只能有一个线程在运行，超线程cpu同一时刻可以有两个逻辑线程运行，所以说线程不是创建的越多越好，过多的线程只会增加线程切换带来的成本。试想一下，如果应用线程池的线程，都在同步等待IO操作的结束，线程池中也就没有空闲线程继续处理请求，所以线程池会继续创建线程以提供服务。恶性循环，则会带来线程过多的成本，好在线程池不会让这样的事发生。那么到达服务器无法处理更多请求的程度时，http 503便出现了。

 

windows下使用IOCP

异步IO在于线程非阻塞，提高CPU利用率，增加服务器吞吐量，助我们承受更大的并发。在windows下使用IOCP，可以直接使用C#异步编程await／async。虽然C#可以直接操作win32API，但.NET平台已提供好异步IO的操作封装，只需要简单的语法，即可完成异步磁盘IO，异步HTTP请求，异步SOCKET，基于.NET框架现有的条件，也很容易做关系数据库，redis，ElasticSearch，mongodb的异步读写。所以推荐在windows下的IO尽可能使用IOCP。IOCP本质上解决的问题就是CPU和IO速度极大的不对等。

 

基于IOCP的异步编程线程行为证明

简单写了个API接口，用于证明在异步IO操作的时候，线程并不阻塞等待IO结束，而是将请求交给驱动后返回线程池，继续工作。

图中代码操作是先记录当前请求处理中的线程ID，然后请求一个10s返回的网络接口。用http客户端并发请求图中该接口后，我们稍后给出线程行为的结论。 我们都知道，如果说服务端线程是IO阻塞的，第一次请求，如果记录了线程ID为1，那么在10s内，该线程一直在阻塞等待，所以10s内不会再出现该线程ID被记录到日志中。 事实上结论是：

可以看到在同一秒甚至同一毫秒内，一个线程同时处理了多次http请求。另外可以确定的一个事实是，IO前和IO后，线程可能是不一样的，也可能是一样的。

 

感谢志同道合的你的阅读，如果你希望长期学习到 .Net , Java , Kotlin ,Python 等原理知识，互联网实践干货，技术感悟等，不妨 关注博客，或者闲暇时在微信公众号上阅读。

 

 

 

转载于:https://www.cnblogs.com/tdws/p/9582155.html