一.場景
dubbo底層使用netty，乙個boss執行緒，核心執行緒+1個worker。
讀寫io在worker執行緒去做。
每個worker會處理一部分socket讀寫。
高併發時，io執行緒不太會不足，原因是預設是核心執行緒+1。高併發時每個執行緒都會不斷的在處理讀寫事件，cpu一直是處於忙的狀態。這時增加io執行緒更多反而會因為cpu切換執行緒上下文而影響效能。
一般業務執行緒池不足可能性比較多，預設有200個執行緒。當然如果出現請求過多處理不過來，直接就拋錯了，問題倒比較好查。
當然也可能會是網路出現瓶頸，記憶體及cpu出現瓶頸，需要用相應的工具命令檢視。
之後會做實際測試。
而這裡主要講，worker執行緒在獲取到socket讀請求時，會從heap快取中獲取乙個buffer。由於是堆快取，不可避免一次核心到堆記憶體的拷貝。
二.原理
服務方處理消費方的呼叫流程如下：
1.乙個讀請求過來時,worker執行緒，首先從嘗試從direct快取區獲取乙個快取，最多儲存8塊，是softreference型別的乙個bytebuf陣列。
注：direct快取預設在full gc時才會進行**。如果沒有full gc
用softreference不用擔心由於快取的原因。
注：這裡如果沒有則會建立一塊direct快取。
2.將對應socket資料寫入到這塊direct快取
3.建立一塊heap記憶體，然後將direct快取的資料寫到這個堆記憶體
4.將之前建立的direct快取放回到快取池
5.將這個heap buffer交給後面的channelhandler處理。
後面會解碼，channel handler處理也在io執行緒。
6.handler都處理完成後，會將這個解碼後的訊息交給另外乙個執行緒池去做。這個執行緒池預設200個執行緒。
實際上還是發生了一次從direct快取拷貝到堆記憶體。
原始碼：
private boolean read(selectionkey k)
}failure = false;
} catch (closedchannelexception e) catch (throwable t)
if (readbytes > 0) else
if (ret < 0 || failure)
return true;
}
二.問題
1.最壞的情況下，這裡direct快取最大記憶體占用有多少？
底層用的是動態預計大小，
類：adaptivereceivebuffersizepredictor
adaptivereceivebuffersizepredictor最大限制是：6k。
也就是說direct dubbo用到最多6k*當前worker個數。
2.如果優化怎麼優化？
在處理讀請求時，最終還是會有一次direct快取到heap堆的拷貝。
優化的話，這裡要換成netty4，使用direct快取池。
Dubbo 介面呼叫結果快取的實現分析
結果快取，用於加速熱門資料的訪問速度，dubbo提供宣告式快取，以減少使用者加快取的工作量。配置如 inte ce com.foo.barservice cache lru 或 inte ce com.foo.barservice name findbar cache lru dubbo refer...
介面呼叫處理，http請求405錯誤
每個介面呼叫都有自己環境，先排查原因 問題使用者反饋，上傳文件非常緩慢 檢視實時日誌如下 分析日誌，發現乙個外調介面連線超時。介面 一直請求超時，網路許可權，是否開通有申請過網路許可權，這個原有常用位址，有許可權。curl命令訪問檢視，405方法不允許，顯示get請求不允許 排查介面對接，是否不是p...
php處理非同步請求 PHP實現非同步呼叫方法研究
瀏覽器和伺服器之間是通過 http 協議進行連線通訊的。這是一種基於請求和響應模型的協議。瀏覽器通過 url 向伺服器發起請求，web 伺服器接收到請求，執行一段程式，然後做出響應，傳送相應的html 給客戶端。這就有了乙個問題，web 伺服器執行一段程式，可能幾毫秒就完成，也可能幾分鐘都完不成。如...