极限挑战下架停播原因,wow玉猫,水男孩脸红心跳
io完成端口（io completion ports）在多核计算机的并行异步io请求方面提供了一种高效的线程模型。当进程创建一个io完成端口时，系统创建一个相关联的队列，其唯一目的是服务与那些请求。io完成端口通常和预先分配的线程池配合，相比于一个一个创建线程，这使其更快更高效。iocp在进程之间并不共享，一个iocp及其句柄只和创建它的进程关联，但是一个进程中的多个线程可共享。iocp最关键的地方就是，iocp在io请求和接收动作完成之后，激活线程池中的任意线程继续操作，而不是在io请求和接受完成之后，激活原等待中的线程。这样的好处是防止等待线程闲置，和必须激活／切换到原等待线程的开销。
曾见过很多服务，几台，几十台，几百台服务器的，它们cpu大多数时间处于空闲状态，也许需要大量计算的应用并没有那么多，我们常见的应用大多主要读写关系数据库，读写内存数据库／缓存，rpc调用接口。io耗时过多，cpu大量闲置，导致没看到服务器资源大量消耗，便已不能承受日益增加的访问量，再加服务器，依然大量浪费了资源。 cpu资源昂贵，每一个核心，同一时刻只能有一个线程在运行，超线程cpu同一时刻可以有两个逻辑线程运行，所以说线程不是创建的越多越好，过多的线程只会增加线程切换带来的成本。试想一下，如果应用线程池的线程，都在同步等待io操作的结束，线程池中也就没有空闲线程继续处理请求，所以线程池会继续创建线程以提供服务。恶性循环，则会带来线程过多的成本，好在线程池不会让这样的事发生。那么到达服务器无法处理更多请求的程度时，http 503便出现了。
异步io在于线程非阻塞，提高cpu利用率，增加服务器吞吐量，助我们承受更大的并发。在windows下使用iocp，可以直接使用c#异步编程await／async。虽然c#可以直接操作win32api，但.net平台已提供好异步io的操作封装，只需要简单的语法，即可完成异步磁盘io，异步http请求，异步socket，基于.net框架现有的条件，也很容易做关系数据库，redis，elasticsearch，mongodb的异步读写。所以推荐在windows下的io尽可能使用iocp。iocp本质上解决的问题就是cpu和io速度极大的不对等。
简单写了个api接口，用于证明在异步io操作的时候，线程并不阻塞等待io结束，而是将请求交给驱动后返回线程池，继续工作。
图中代码操作是先记录当前请求处理中的线程id，然后请求一个10s返回的网络接口。用http客户端并发请求图中该接口后，我们稍后给出线程行为的结论。 我们都知道，如果说服务端线程是io阻塞的，第一次请求，如果记录了线程id为1，那么在10s内，该线程一直在阻塞等待，所以10s内不会再出现该线程id被记录到日志中。 事实上结论是：
可以看到在同一秒甚至同一毫秒内，一个线程同时处理了多次http请求。另外可以确定的一个事实是，io前和io后，线程可能是不一样的，也可能是一样的。
感谢志同道合的你的阅读，如果你希望长期学习到 .net , java , kotlin ,python 等原理知识，互联网实践干货，技术感悟等，不妨 关注博客，或者闲暇时在微信公众号上阅读。
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复
Blazor server side 自家的一些开源的, 实用型项目的进度之 CEF客户端
.NET IoC模式依赖反转(DIP)、控制反转(Ioc)、依赖注入(DI)
vue+.netcore可支持业务代码扩展的开发框架 VOL.Vue 2.0版本发布
我要评论
网友评论