golang sync.pool對象復用 并發原理 緩存池

在go http每一次go serve(l)都會構建Request數據結構。在大量數據請求或高并發的場景中，頻繁創建銷毀對象，會導致GC壓力。解決辦法之一就是使用對象復用技術。在http協議層之下，使用對象復用技術創建Request數據結構。在http協議層之上，可以使用對象復用技術創建(w,*r,ctx)數據結構。這樣即可以回快TCP層讀包之后的解析速度，也可也加快請求處理的速度。

創新互聯是由多位在大型網絡公司、廣告設計公司的優秀設計人員和策劃人員組成的一個具有豐富經驗的團隊，其中包括網站策劃、網頁美工、網站程序員、網頁設計師、平面廣告設計師、網絡營銷人員及形象策劃。承接：網站建設、網站設計、網站改版、網頁設計制作、網站建設與維護、網絡推廣、數據庫開發,以高性價比制作企業網站、行業門戶平臺等全方位的服務。

先上一個測試：

結論是這樣的：

貌似使用池化，性能弱爆了？？？這似乎與net/http使用sync.pool池化Request來優化性能的選擇相違背。這同時也說明了一個問題，好的東西，如果濫用反而造成了性能成倍的下降。在看過pool原理之后，結合實例，將給出正確的使用方法，并給出預期的效果。

sync.Pool是一個 協程安全 的 臨時對象池 。數據結構如下：

local 成員的真實類型是一個 poolLocal 數組，localSize 是數組長度。這涉及到Pool實現，pool為每個P分配了一個對象，P數量設置為runtime.GOMAXPROCS(0)。在并發讀寫時，goroutine綁定的P有對象，先用自己的，沒有去偷其它P的。go語言將數據分散在了各個真正運行的P中，降低了鎖競爭，提高了并發能力。

不要習慣性地誤認為New是一個關鍵字，這里的New是Pool的一個字段，也是一個閉包名稱。其API：

如果不指定New字段，對象池為空時會返回nil，而不是一個新構建的對象。Get()到的對象是隨機的。

原生sync.Pool的問題是，Pool中的對象會被GC清理掉，這使得sync.Pool只適合做簡單地對象池，不適合作連接池。

pool創建時不能指定大小，沒有數量限制。pool中對象會被GC清掉，只存在于兩次GC之間。實現是pool的init方法注冊了一個poolCleanup()函數，這個方法在GC之前執行，清空pool中的所有緩存對象。

為使多協程使用同一個POOL。最基本的想法就是每個協程，加鎖去操作共享的POOL，這顯然是低效的。而進一步改進，類似于ConcurrentHashMap（JDK7）的分Segment，提高其并發性可以一定程度性緩解。

注意到pool中的對象是無差異性的，加鎖或者分段加鎖都不是較好的做法。go的做法是為每一個綁定協程的P都分配一個子池。每個子池又分為私有池和共享列表。共享列表是分別存放在各個P之上的共享區域，而不是各個P共享的一塊內存。協程拿自己P里的子池對象不需要加鎖，拿共享列表中的就需要加鎖了。

Get對象過程：

Put過程：

如何解決Get最壞情況遍歷所有P才獲取得對象呢：

方法1止前sync.pool并沒有這樣的設置。方法2由于goroutine被分配到哪個P由調度器調度不可控，無法確保其平衡。

由于不可控的GC導致生命周期過短，且池大小不可控，因而不適合作連接池。僅適用于增加對象重用機率，減少GC負擔。2

執行結果:

單線程情況下，遍歷其它無元素的P，長時間加鎖性能低下。啟用協程改善。

結果：

測試場景在goroutines遠大于GOMAXPROCS情況下，與非池化性能差異巨大。

測試結果

可以看到同樣使用*sync.pool，較大池大小的命中率較高，性能遠高于空池。

結論：pool在一定的使用條件下提高并發性能，條件1是協程數遠大于GOMAXPROCS，條件2是池中對象遠大于GOMAXPROCS。歸結成一個原因就是使對象在各個P中均勻分布。

池pool和緩存cache的區別。池的意思是，池內對象是可以互換的，不關心具體值，甚至不需要區分是新建的還是從池中拿出的。緩存指的是KV映射，緩存里的值互不相同，清除機制更為復雜。緩存清除算法如LRU、LIRS緩存算法。

池空間回收的幾種方式。一些是GC前回收，一些是基于時鐘或弱引用回收。最終確定在GC時回收Pool內對象，即不回避GC。用java的GC解釋弱引用。GC的四種引用：強引用、弱引用、軟引用、虛引用。虛引用即沒有引用，弱引用GC但有空間則保留，軟引用GC即清除。ThreadLocal的值為弱引用的例子。

regexp 包為了保證并發時使用同一個正則，而維護了一組狀態機。

fmt包做字串拼接，從sync.pool拿[]byte對象。避免頻繁構建再GC效率高很多。

golang sync.Pool的用法及實現

正如sycn.Pool的名字所示，這是go中實現的一個對象池，為什么要有這個池呢？首先go是自帶垃圾回收機制（也就是通常所說的gc）。gc會帶來運行時的開銷，對于高頻的內存申請與釋放，如果將不用的對象存放在一個池子中，用的時候從池子中取出一個對象，用完了再還回去，這樣就能減輕gc的壓力。

對于池這個概念，之前可能聽說過連接池。能否用sync.Pool實現一個連接池呢？答案是不能的。因為對于sync.Pool而言，我們無法保證每次放回去再取出來的對象是與之前一致的，對象的內存存在著唄銷毀的可能。因此，這個sync.Pool的存在僅僅是為了減緩gc的壓力而生的。

定義sync.Pool的時候只需要設置一個New成員，它是一個函數，類型為func() interface{}，當池子中沒有空閑的對象時就會調用New函數生成一個。由于pool中對象的數量不可控，因此并沒有傳遞任何與對象數量有關的參數。

然后，調用調用Get函數就可以取出一個對象，調用Put函數就可以將對象歸還到池子中。

Go語言設計與實現（上）

基本設計思路：

類型轉換、類型斷言、動態派發。iface，eface。

反射對象具有的方法：

編譯優化：

內部實現：

實現 Context 接口有以下幾個類型（空實現就忽略了）：

互斥鎖的控制邏輯：

設計思路：

（以上為寫被讀阻塞，下面是讀被寫阻塞）

總結，讀寫鎖的設計還是非常巧妙的：

設計思路：

WaitGroup 有三個暴露的函數:

部件：

設計思路：

結構：

Once 只暴露了一個方法：

實現：

三個關鍵點：

細節：

讓多協程任務的開始執行時間可控（按順序或歸一）。（Context 是控制結束時間）

設計思路： 通過一個鎖和內置的 notifyList 隊列實現，Wait() 會生成票據，并將等待協程信息加入鏈表中，等待控制協程中發送信號通知一個（Signal()）或所有（Boardcast()）等待者（內部實現是通過票據通知的）來控制協程解除阻塞。

暴露四個函數：

實現細節：

部件：

包： golang.org/x/sync/errgroup

作用：開啟 func() error 函數簽名的協程，在同 Group 下協程并發執行過程并收集首次 err 錯誤。通過 Context 的傳入，還可以控制在首次 err 出現時就終止組內各協程。

設計思路：

結構：

暴露的方法：

實現細節：

注意問題：

包： "golang.org/x/sync/semaphore"

作用：排隊借資源（如錢，有借有還）的一種場景。此包相當于對底層信號量的一種暴露。

設計思路：有一定數量的資源 Weight，每一個 waiter 攜帶一個 channel 和要借的數量 n。通過隊列排隊執行借貸。

結構：

暴露方法：

細節：

部件：

細節：

包： "golang.org/x/sync/singleflight"

作用：防擊穿。瞬時的相同請求只調用一次，response 被所有相同請求共享。

設計思路：按請求的 key 分組（一個 *call 是一個組，用 map 映射存儲組），每個組只進行一次訪問，組內每個協程會獲得對應結果的一個拷貝。

結構：

邏輯：

細節：

部件：

如有錯誤，請批評指正。

當前題目：go語言設計模式對象池 go的設計模式
轉載注明：http://vcdvsql.cn/article48/hephep.html

成都網站建設公司_創新互聯，為您提供網站內鏈、網站策劃、網站排名、網頁設計公司、虛擬主機、品牌網站建設

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯