线程池＋同步io和异步io(浅谈)

线程池＋同步io和异步io(浅谈)

来自于知乎大佬的一个评论 我们的系统代码从同步方式+线程池改成异步化之后压测发现性能提高了一倍，不再有大量的空闲线程，但是CPU的消耗太大，几乎打满，后来改成协程化之后减少了线程数，提高了性能（相比异步化的代码，性能又提高了一倍以上），降低了资源消耗（主要是CPU）。
本片文章只是进行浅谈理解可能欠缺以后加以改正

首先最近一直在写负载均衡器　对与每个客户端的请求做了一个任务队列，然后采用线程池的模型，采用epoll 将有时间的ｉｏ挂载到任务队列通过多个线程去处理，显而易见，epoll 在模型中也是同步io方式，只不过他是一种伪异步的方式，具体如何伪异步，他只检测当前事件是否到来如果到来就将对应的fd放到就绪队列.具体请看epoll 代码。

其实对于异步和同步我有自己的认识，当数据没来时在同步和非同步下，都要去缓冲区中看一下，他们都要自己去处理。对于异步的方式而言，如果异步的处理方式而言，每次事件发生都是由内核帮我将数据拷贝到用户态一般采用回调函数处理，效率明显比过了不就去看一下啊的然后在进行处理的方式高很多。对于ｃｐｕ的占用也不是很高；他只有在回调处理时处于阻塞态.

其实这种模型对应是半同步半异步模型

异步线程等待客户端请求，同步线程处理客户端事件；提高效率.

但对于任务队列而言有一个加锁和解锁的操作感觉效率不高；

同步：提交请求->等待服务器处理->处理完毕返回 这个期间客户端浏览器不能干任何事
异步: 请求通过事件触发->服务器处理（这是浏览器仍然可以作其他事情）->处理完毕

虽然异步有很多好处但是如果开辟太多的线程会　造成ｃｐｕ占用率高，并且异步编程过于难晦涩难懂，ｃ＋＋ａｉｏ或者异步编程　推荐ｃ＋＋　并发编程这本书　因此所以出现了协程这个东西。并且线程上下文切换也需要时间

协程就是用户态线程，比内核线程低廉，切换阻塞成本低; 单调度器下，访问共享资源无需上锁，用于提高cpu单核的并发能力缺点是 无法利用多核资源，只能开多进程才行，不过现在使用协程的语言都用到了多调度器的架构，单进程下的协程也能用多核了协程可以用来解决很多问题，比如node js的嵌套回调，Erlang以及Golang的并发模型实现。并且所有协成同属一个线程。因此不需要进行加锁解锁操作。

ｄｏｔｏ。。。。。。。。。。。。。。。。。。。。。。。。。。。