線程池＋同步io和異步io(淺談)
來自於知乎大佬的一個評論 我們的系統代碼從同步方式+線程池改成異步化之后壓測發現性能提高了一倍，不再有大量的空閑線程，但是CPU的消耗太大，幾乎打滿，后來改成協程化之后減少了線程數，提高了性能（相比異步化的代碼，性能又提高了一倍以上），降低了資源消耗（主要是CPU）。
本片文章只是進行淺談理解可能欠缺以后加以改正
首先最近一直在寫負載均衡器 對與每個客戶端的請求做了一個任務隊列，然后采用線程池的模型，采用epoll 將有時間的ｉｏ掛載到任務隊列通過多個線程去處理，顯而易見，epoll 在模型中也是同步io方式，只不過他是一種偽異步的方式，具體如何偽異步，他只檢測當前事件是否到來如果到來就將對應的fd放到就緒隊列.具體請看epoll 代碼。
其實對於異步和同步我有自己的認識，當數據沒來時在同步和非同步下，都要去緩沖區中看一下，他們都要自己去處理。對於異步的方式而言，如果異步的處理方式而言，每次事件發生都是由內核幫我將數據拷貝到用戶態一般采用回調函數處理，效率明顯比過了不就去看一下啊的然后在進行處理的方式高很多。對於ｃｐｕ的占用也不是很高；他只有在回調處理時處於阻塞態.
其實這種模型對應是半同步半異步模型
異步線程等待客戶端請求，同步線程處理客戶端事件；提高效率.
但對於任務隊列而言有一個加鎖和解鎖的操作感覺效率不高；
同步：提交請求->等待服務器處理->處理完畢返回 這個期間客戶端瀏覽器不能干任何事
異步: 請求通過事件觸發->服務器處理（這是瀏覽器仍然可以作其他事情）->處理完畢
雖然異步有很多好處但是如果開辟太多的線程會 造成ｃｐｕ占用率高，並且異步編程過於難晦澀難懂，ｃ＋＋ａｉｏ或者異步編程 推薦ｃ＋＋ 並發編程這本書 因此所以出現了協程這個東西。並且線程上下文切換也需要時間
協程就是用戶態線程，比內核線程低廉，切換阻塞成本低; 單調度器下，訪問共享資源無需上鎖，用於提高cpu單核的並發能力缺點是 無法利用多核資源，只能開多進程才行，不過現在使用協程的語言都用到了多調度器的架構，單進程下的協程也能用多核了協程可以用來解決很多問題，比如node js的嵌套回調，Erlang以及Golang的並發模型實現。並且所有協成同屬一個線程。因此不需要進行加鎖解鎖操作。
ｄｏｔｏ。。。。。。。。。。。。。。。。。。。。。。。。。。。