Go 語言中的零拷貝優(yōu)化

導(dǎo)言

相信那些曾經(jīng)使用 Go 寫過 proxy server 的同學(xué)應(yīng)該對 io.Copy()/io.CopyN()/io.CopyBuffer()/io.ReaderFrom 等接口和方法不陌生，它們是使用 Go 操作各類 I/O 進行數(shù)據(jù)傳輸經(jīng)常需要使用到的 API，其中基于 TCP 協(xié)議的 socket 在使用上述接口和方法進行數(shù)據(jù)傳輸時利用到了 Linux 的零拷貝技術(shù) sendfile 和 splice。

我前段時間為 Go 語言內(nèi)部的 Linux splice 零拷貝技術(shù)做了一點優(yōu)化：為 splice 系統(tǒng)調(diào)用實現(xiàn)了一個 pipe pool，復(fù)用管道，減少頻繁創(chuàng)建和銷毀 pipe buffers 所帶來的系統(tǒng)開銷，理論上來說能夠大幅提升 Go 的 io 標(biāo)準(zhǔn)庫中基于 splice 零拷貝實現(xiàn)的 API 的性能。因此，我想從這個優(yōu)化工作出發(fā)，分享一些我個人對多線程編程中的一些不成熟的優(yōu)化思路。

因本人才疏學(xué)淺，故行文之間恐有紕漏，望諸君海涵，不吝賜教，若能予以斧正，則感激不盡。

splice

縱觀 Linux 的零拷貝技術(shù)，相較于mmap、sendfile和 MSG_ZEROCOPY 等其他技術(shù)，splice 從使用成本、性能和適用范圍等維度綜合來看更適合在程序中作為一種通用的零拷貝方式。

splice() 系統(tǒng)調(diào)用函數(shù)定義如下：

#include <fcntl.h>
#include <unistd.h>

int pipe(int pipefd[2]);
int pipe2(int pipefd[2], int flags);

ssize_t splice(int fd_in, loff_t *off_in, int fd_out, loff_t *off_out, size_t len, unsigned int flags);

fd_in 和 fd_out 也是分別代表了輸入端和輸出端的文件描述符，這兩個文件描述符必須有一個是指向管道設(shè)備的，這算是一個不太友好的限制。

off_in 和 off_out 則分別是 fd_in 和 fd_out 的偏移量指針，指示內(nèi)核從哪里讀取和寫入數(shù)據(jù)，len 則指示了此次調(diào)用希望傳輸?shù)淖止?jié)數(shù)，最后的 flags 是系統(tǒng)調(diào)用的標(biāo)記選項位掩碼，用來設(shè)置系統(tǒng)調(diào)用的行為屬性的，由以下 0 個或者多個值通過『或』操作組合而成：

• SPLICE_F_MOVE：指示 splice() 嘗試僅僅是移動內(nèi)存頁面而不是復(fù)制，設(shè)置了這個值不代表就一定不會復(fù)制內(nèi)存頁面，復(fù)制還是移動取決于內(nèi)核能否從管道中移動內(nèi)存頁面，或者管道中的內(nèi)存頁面是否是完整的；這個標(biāo)記的初始實現(xiàn)有很多 bug，所以從 Linux 2.6.21 版本開始就已經(jīng)無效了，但還是保留了下來，因為在未來的版本里可能會重新被實現(xiàn)。
• SPLICE_F_NONBLOCK：指示 splice() 不要阻塞 I/O，也就是使得 splice() 調(diào)用成為一個非阻塞調(diào)用，可以用來實現(xiàn)異步數(shù)據(jù)傳輸，不過需要注意的是，數(shù)據(jù)傳輸?shù)膬蓚€文件描述符也最好是預(yù)先通過 O_NONBLOCK 標(biāo)記成非阻塞 I/O，不然 splice() 調(diào)用還是有可能被阻塞。
• SPLICE_F_MORE：通知內(nèi)核下一個 splice() 系統(tǒng)調(diào)用將會有更多的數(shù)據(jù)傳輸過來，這個標(biāo)記對于輸出端是 socket 的場景非常有用。

splice() 是基于 Linux 的管道緩沖區(qū) (pipe buffer) 機制實現(xiàn)的，所以 splice() 的兩個入?yún)⑽募枋龇乓蟊仨氂幸粋€是管道設(shè)備，一個典型的 splice() 用法是：

int pfd[2];

pipe(pfd);

ssize_t bytes = splice(file_fd, NULL, pfd[1], NULL, 4096, SPLICE_F_MOVE);
assert(bytes != -1);

bytes = splice(pfd[0], NULL, socket_fd, NULL, bytes, SPLICE_F_MOVE | SPLICE_F_MORE);
assert(bytes != -1);

數(shù)據(jù)傳輸過程圖：

使用 splice() 完成一次磁盤文件到網(wǎng)卡的讀寫過程如下：

1. 用戶進程調(diào)用 pipe()，從用戶態(tài)陷入內(nèi)核態(tài)，創(chuàng)建匿名單向管道，pipe() 返回，上下文從內(nèi)核態(tài)切換回用戶態(tài)；
2. 用戶進程調(diào)用 splice()，從用戶態(tài)陷入內(nèi)核態(tài)；
3. DMA 控制器將數(shù)據(jù)從硬盤拷貝到內(nèi)核緩沖區(qū)，從管道的寫入端"拷貝"進管道，splice() 返回，上下文從內(nèi)核態(tài)回到用戶態(tài)；
4. 用戶進程再次調(diào)用 splice()，從用戶態(tài)陷入內(nèi)核態(tài)；
5. 內(nèi)核把數(shù)據(jù)從管道的讀取端"拷貝"到套接字緩沖區(qū)，DMA 控制器將數(shù)據(jù)從套接字緩沖區(qū)拷貝到網(wǎng)卡；
6. splice() 返回，上下文從內(nèi)核態(tài)切換回用戶態(tài)。

上面是 splice 的基本工作流程和原理，簡單來說就是在數(shù)據(jù)傳輸過程中傳遞內(nèi)存頁指針而非實際數(shù)據(jù)來實現(xiàn)零拷貝，如果有意了解其更底層的實現(xiàn)原理請移步：《Linux I/O 原理和 Zero-copy 技術(shù)全面揭秘》。

pipe pool for splice

pipe pool in HAProxy

從上面對 splice 的介紹可知，通過它實現(xiàn)數(shù)據(jù)零拷貝需要利用到一個媒介 -- pipe 管道（2005 年由 Linus 引入），大概是因為在 Linux 的 IPC 機制中對 pipe 的應(yīng)用已經(jīng)比較成熟，于是借助了 pipe 來實現(xiàn) splice，雖然 Linux Kernel 團隊曾在 splice 誕生之初便說過在未來可以移除掉 pipe 這個限制，但十幾年過去了也依然沒有付諸實施，因此 splice 至今還是和 pipe 死死綁定在一起。

那么問題就來了，如果僅僅是使用 splice 進行單次的大批量數(shù)據(jù)傳輸，則創(chuàng)建和銷毀 pipe 開銷幾乎可以忽略不計，但是如果是需要頻繁地使用 splice 來進行數(shù)據(jù)傳輸，比如需要處理大量網(wǎng)絡(luò) sockets 的數(shù)據(jù)轉(zhuǎn)發(fā)的場景，則 pipe 的創(chuàng)建和銷毀的頻次也會隨之水漲船高，每調(diào)用一次 splice 都創(chuàng)建一對 pipe 管道描述符，并在隨后銷毀掉，對一個網(wǎng)絡(luò)系統(tǒng)來說是一個巨大的消耗。

對于這問題的解決方案，自然而然就會想到 -- 『復(fù)用』，比如大名鼎鼎的 HAProxy。

“

HAProxy 是一個使用 C 語言編寫的自由及開放源代碼軟件，其提供高可用性、負載均衡，以及基于 TCP 和 HTTP 的應(yīng)用程序代理。它非常適用于那些有著極高網(wǎng)絡(luò)流量的 Web 站點。GitHub、Bitbucket、Stack Overflow、Reddit、Tumblr、Twitter 和 Tuenti 在內(nèi)的知名網(wǎng)站，及亞馬遜網(wǎng)絡(luò)服務(wù)系統(tǒng)都在使用 HAProxy。

”

因為需要做流量轉(zhuǎn)發(fā)，可想而知，HAProxy 不可避免地要高頻地使用 splice，因此對 splice 帶來的創(chuàng)建和銷毀 pipe buffers 的開銷無法忍受，從而需要實現(xiàn)一個 pipe pool，復(fù)用 pipe buffers 減少系統(tǒng)調(diào)用消耗，下面我們來詳細剖析一下 HAProxy 的 pipe pool 的設(shè)計思路。

首先我們來自己思考一下，一個最簡單的 pipe pool 應(yīng)該如何實現(xiàn)，最直接且簡單的實現(xiàn)無疑就是：一個單鏈表+一個互斥鎖。鏈表和數(shù)組是用來實現(xiàn) pool 的最簡單的數(shù)據(jù)結(jié)構(gòu)，數(shù)組因為數(shù)據(jù)在內(nèi)存分配上的連續(xù)性，能夠更好地利用 CPU 高速緩存加速訪問，但是首先，對于運行在某個 CPU 上的線程來說，一次只需要取一個 pipe buffer 使用，所以高速緩存在這里的作用并不十分明顯；其次，數(shù)組不僅是連續(xù)而且是固定大小的內(nèi)存區(qū)，需要預(yù)先分配好固定大小的內(nèi)存，而且還要動態(tài)伸縮這個內(nèi)存區(qū)，期間需要對數(shù)據(jù)進行搬遷等操作，增加額外的管理成本。鏈表則是更加適合的選擇，因為作為 pool 來說其中所有的資源都是等價的，并不需要隨機訪問去獲取其中某個特定的資源，而且鏈表天然是動態(tài)伸縮的，隨取隨棄。

鎖通常使用 mutex，在 Linux 上的早期實現(xiàn)是一種完全基于內(nèi)核態(tài)的 sleep-waiting 也就是休眠等待的鎖，kernel 維護一個對所有進程/線程都可見的共享資源對象 mutex，多線程/進程的加鎖解鎖其實就是對這個對象的競爭。如果現(xiàn)在有 AB 兩個進程/線程，A 首先進入 kernel space 檢查 mutex，看看有沒有別的進程/線程正在占用它，搶占 mutex 成功之后則直接進入臨界區(qū)，B 嘗試進入臨界區(qū)的時候，檢測到 mutex 已被占用，就由運行態(tài)切換成睡眠態(tài)，等待該共享對象釋放，A 出臨界區(qū)的時候，需要再次進入 kernel space 查看有沒有別的進程/線程在等待進入臨界區(qū)，然后 kernel 會喚醒等待的進程/線程并在合適的時間把 CPU 切換給該進程/線程運行。由于最初的 mutex 是一種完全內(nèi)核態(tài)的互斥量實現(xiàn)，在并發(fā)量大的情況下會產(chǎn)生大量的系統(tǒng)調(diào)用和上下文切換的開銷，在 Linux kernel 2.6.x 之后都是使用 futex (Fast Userspace Mutexes) 實現(xiàn)，也即是一種用戶態(tài)和內(nèi)核態(tài)混用的實現(xiàn)，通過在用戶態(tài)共享一段內(nèi)存，并利用原子操作讀取和修改信號量，在沒有競爭的時候只需檢查這個用戶態(tài)的信號量而無需陷入內(nèi)核，信號量存儲在進程內(nèi)的私有內(nèi)存則是線程鎖，存儲在通過 mmap 或者 shmat 創(chuàng)建的共享內(nèi)存中則是進程鎖。

即便是基于 futex 的互斥鎖，如果是一個全局的鎖，這種最簡單的 pool + mutex 實現(xiàn)在競爭激烈的場景下會有可預(yù)見的性能瓶頸，因此需要進一步的優(yōu)化，優(yōu)化手段無非兩個：降低鎖的粒度或者減少搶(全局)鎖的頻次。因為 pipe pool 中的資源本來就是全局共享的，也就是無法對鎖的粒度進行降級，因此只能是盡量減少多線程搶鎖的頻次，而這種優(yōu)化常用方案就是在全局資源池之外引入本地資源池，對多線程訪問資源的操作進行錯開。

至于鎖本身的優(yōu)化，由于 mutex 是一種休眠等待鎖，即便是基于 futex 優(yōu)化之后在鎖競爭時依然需要涉及內(nèi)核態(tài)開銷，此時可以考慮使用自旋鎖（Spin Lock），也即是用戶態(tài)的鎖，共享資源對象存在用戶進程的內(nèi)存中，避免在鎖競爭的時候陷入到內(nèi)核態(tài)等待，自旋鎖比較適合臨界區(qū)極小的場景，而 pipe pool 的臨界區(qū)里只是對鏈表的增刪操作，非常匹配。

HAProxy 實現(xiàn)的 pipe pool 就是依據(jù)上述的思路進行設(shè)計的，將單一的全局資源池拆分成全局資源池+本地資源池。

全局資源池利用單鏈表和自旋鎖實現(xiàn)，本地資源池則是基于線程私有存儲（Thread Local Storage, TLS）實現(xiàn)，TLS 是一種線程的私有的變量，它的主要作用是在多線程編程中避免鎖競爭的開銷。TLS 由編譯器提供支持，我們知道編譯 C 程序得到的 obj 或者鏈接得到的 exe，其中的 .text 段保存代碼文本，.data 段保存已初始化的全局變量和已初始化的靜態(tài)變量，.bss 段則保存未初始化的全局變量和未初始化的局部靜態(tài)變量。

而 TLS 私有變量則會存入 TLS 幀，也就是 .tdata 和 .tboss 段，與.data 和 .bss 不同的是，運行時程序不會直接訪問這些段，而是在程序啟動后，動態(tài)鏈接器會對這兩個段進行動態(tài)初始化 （如果有聲明 TLS 的話），之后這兩個段不會再改變，而是作為 TLS 的初始鏡像保存起來。每次啟動一個新線程的時候都會將 TLS 塊作為線程堆棧的一部分進行分配并將初始的 TLS 鏡像拷貝過來，也就是說最終每個線程啟動時 TLS 塊中的內(nèi)容都是一樣的。

HAProxy 的 pipe pool 實現(xiàn)原理：

1. 聲明 thread_local 修飾的一個單鏈表，節(jié)點是 pipe buffer 的兩個管道描述符，那么每個需要使用 pipe buffer 的線程都會初始化一個基于 TLS 的單鏈表，用以存儲 pipe buffers；
2. 設(shè)置一個全局的 pipe pool，使用自旋鎖保護。

每個線程去取 pipe 的時候會先從自己的 TLS 中去嘗試獲取，獲取不到則加鎖進入全局 pipe pool 去找；使用 pipe buffer 過后將其放回：先嘗試放回 TLS，根據(jù)一定的策略計算當(dāng)前 TLS 的本地 pipe pool 鏈表中的節(jié)點是否已經(jīng)過多，是的話則放到全局的 pipe pool 中去，否則直接放回本地 pipe pool。

HAProxy 的 pipe pool 實現(xiàn)雖然只有短短的 100 多行代碼，但是其中蘊含的設(shè)計思想?yún)s包含了許多非常經(jīng)典的多線程優(yōu)化思路，值得細讀。

pipe pool in Go

受到 HAProxy 的 pipe pool 的啟發(fā)，我嘗試為 Golang 的 io 標(biāo)準(zhǔn)庫里底層的 splice 實現(xiàn)了一個 pipe pool，不過熟悉 Go 的同學(xué)應(yīng)該知道 Go 有一個 GMP 并發(fā)調(diào)度器，提供了強大并發(fā)調(diào)度能力的同時也屏蔽了操作系統(tǒng)層級的線程，所以 Go 沒有提供類似 TLS 的機制，倒是有一些開源的第三方庫提供了類似的功能，比如 gls，雖然實現(xiàn)很精巧，但畢竟不是官方標(biāo)準(zhǔn)庫而且會直接操作底層堆棧，所以其實也并不推薦在線上使用。

一開始，因為 Go 缺乏 TLS 機制，所以我提交的第一版 go pipe pool 就是一個很簡陋的單鏈表+全局互斥鎖的實現(xiàn)，因為這個方案在進程的生命周期中并不會去釋放資源池里的 pipe buffers（實際上 HAProxy 的 pipe pool 也會有這個問題），也就是說那些未被釋放的 pipe buffers 將一直存在于用戶進程的生命周期中，直到進程結(jié)束之后才由 kernel 進行釋放，這明顯不是一個令人信服的解決方案，結(jié)果不出意料地被 Go team 的核心大佬 Ian (委婉地)否決了，于是我馬上又想了兩個新的方案：

1. 基于這個現(xiàn)有的方案加上一個獨立的 goroutine 定時去掃描 pipe pool，關(guān)閉并釋放 pipe buffers；
2. 基于 sync.Pool 標(biāo)準(zhǔn)庫來實現(xiàn) pipe pool，并利用 runtime.SetFinalizer 來解決定期釋放 pipe buffers 的問題。

第一個方案需要引入額外的 goroutine，并且該 goroutine 也為這個設(shè)計增加了不確定的因素，而第二個方案則更加優(yōu)雅，首先因為基于 sync.Pool 實現(xiàn)，其底層也可以說是基于 TLS 的思想，其次利用了 Go 的 runtime 來解決定時釋放 pipe buffers 的問題，實現(xiàn)上更加的優(yōu)雅，所以很快，我和其他的 Go reviewers 就達成一致決定采用第二個方案。

sync.Pool 是 Go 語言提供的臨時對象緩存池，一般用來復(fù)用資源對象，減輕 GC 壓力，合理使用它能對程序的性能有顯著的提升。很多頂級的 Go 開源庫都會重度使用 sync.Pool 來提升性能，比如 Go 領(lǐng)域最流行的第三方 HTTP 框架 fasthttp 就在源碼中大量地使用了 sync.Pool，并且收獲了比 Go 標(biāo)準(zhǔn) HTTP 庫高出近 10 倍的性能提升（當(dāng)然不僅僅靠這一個優(yōu)化點，還有很多其他的），fasthttp 的作者 Aliaksandr Valialkin 作為 Go 領(lǐng)域的大神（Go contributor，給 Go 貢獻過很多代碼，也優(yōu)化過 sync.Pool），在 fasthttp 的 best practices 中極力推薦使用 sync.Pool，所以 Go 的 pipe pool 使用 sync.Pool 來實現(xiàn)也算是水到渠成。

sync.Pool 底層原理簡單來說就是：私有變量+共享雙向鏈表。

Google 了一張圖來展示 sync.Pool 的底層實現(xiàn)：

• 獲取對象時：當(dāng)某個 P 上的 goroutine 從 sync.Pool 嘗試獲取緩存的對象時，需要先把當(dāng)前的 goroutine 鎖死在 P 上，防止操作期間突然被調(diào)度走，然后先嘗試去取本地私有變量 private，如果沒有則去 shared 雙向鏈表的表頭取，該鏈表可以被其他 P 消費（或者說"偷"），如果當(dāng)前 P 上的 shared 是空則去"偷"其他 P 上的 shared 雙向鏈表的表尾，最后解除鎖定，如果還是沒有取到緩存的對象，則直接調(diào)用 New 創(chuàng)建一個返回。
• 放回對象時：先把當(dāng)前的 goroutine 鎖死在 P 上，如果本地的 private 為空，則直接將對象存入，否則就存入 shared 雙向鏈表的表頭，最后解除鎖定。

shared 雙向鏈表的每個節(jié)點都是一個環(huán)形隊列，主要是為了高效復(fù)用內(nèi)存，共享雙向鏈表在 Go 1.13 之前使用互斥鎖 sync.Mutex 保護，Go 1.13 之后改用 atomic CAS 實現(xiàn)無鎖并發(fā)，原子操作無鎖并發(fā)適用于那些臨界區(qū)極小的場景，性能會被互斥鎖好很多，正好很貼合 sync.Pool 的場景，因為存取臨時對象的操作是非?？焖俚模绻褂?mutex，則在競爭時需要掛起那些搶鎖失敗的 goroutines 到 wait queue，等后續(xù)解鎖之后喚醒并放入 run queue，等待調(diào)度執(zhí)行，還不如直接忙輪詢等待，反正很快就能搶占到臨界區(qū)。

sync.Pool 的設(shè)計也具有部分的 TLS 思想，所以從某種意義上來說它是就 Go 語言的 TLS 機制。

sync.Pool 基于 victim cache 會保證緩存在其中的資源對象最多不超過兩個 GC 周期就會被回收掉。

因此我使用了 sync.Pool 來實現(xiàn) Go 的 pipe pool，把 pipe 的管道文件描述符對存儲在其中，并發(fā)之時進行復(fù)用，而且會定期自動回收，但是還有一個問題，當(dāng) sync.Pool 中的對象被回收的時候，只是回收了管道的文件描述符對，也就是兩個整型的 fd 數(shù)，并沒有在操作系統(tǒng)層面關(guān)閉掉 pipe 管道。

因此，還需要有一個方法來關(guān)閉 pipe 管道，這時候可以利用 runtime.SetFinalizer 來實現(xiàn)。這個方法其實就是對一個即將放入 sync.Pool 的資源對象設(shè)置一個回調(diào)函數(shù)，當(dāng) Go 的三色標(biāo)記 GC 算法檢測到 sync.Pool 中的對象已經(jīng)變成白色（unreachable，也就是垃圾）并準(zhǔn)備回收時，如果該白色對象已經(jīng)綁定了一個關(guān)聯(lián)的回調(diào)函數(shù)，則 GC 會先解綁該回調(diào)函數(shù)并啟動一個獨立的 goroutine 去執(zhí)行該回調(diào)函數(shù)，因為回調(diào)函數(shù)使用該對象作為函數(shù)入?yún)ⅲ簿褪菚玫皆搶ο?，那么就會?dǎo)致該對象重新變成一個 reachable 的對象，所以在本輪 GC 中不會被回收，從而使得這個對象的生命得以延續(xù)一個 GC 周期。

在每一個 pipe buffer 放回 pipe pool 之前通過 runtime.SetFinalizer 指定一個回調(diào)函數(shù)，在函數(shù)中使用系統(tǒng)調(diào)用關(guān)閉管道，則可以利用 Go 的 GC 機制定期真正回收掉 pipe buffers，從而實現(xiàn)了一個優(yōu)雅的 pipe pool in Go，相關(guān)的 commits 如下：

• internal/poll: implement a pipe pool for splice() call
• internal/poll: fix the intermittent build failures with pipe pool
• internal/poll: ensure that newPoolPipe doesn't return a nil pointer
• internal/poll: cast off the last reference of SplicePipe in test

為 Go 的 splice 引入 pipe pool 之后，對性能的提升效果如下：

goos: linux
goarch: amd64
pkg: internal/poll
cpu: AMD EPYC 7K62 48-Core Processor

name                  old time/op    new time/op    delta
SplicePipe-8            1.36μs ± 1%    0.02μs ± 0%   -98.57%  (p=0.001 n=7+7)
SplicePipeParallel-8     747ns ± 4%       4ns ± 0%   -99.41%  (p=0.001 n=7+7)

name                  old alloc/op   new alloc/op   delta
SplicePipe-8             24.0B ± 0%      0.0B       -100.00%  (p=0.001 n=7+7)
SplicePipeParallel-8     24.0B ± 0%      0.0B       -100.00%  (p=0.001 n=7+7)

name                  old allocs/op  new allocs/op  delta
SplicePipe-8              1.00 ± 0%      0.00       -100.00%  (p=0.001 n=7+7)
SplicePipeParallel-8      1.00 ± 0%      0.00       -100.00%  (p=0.001 n=7+7)

基于 pipe pool 復(fù)用和直接創(chuàng)建&銷毀 pipe buffers 相比，耗時下降在 99% 以上，內(nèi)存使用則是下降了 100%。

當(dāng)然，這個 benchmark 只是一個純粹的存取操作，并未加入具體的業(yè)務(wù)邏輯，所以是一個非常理想化的壓測，不能完全代表生產(chǎn)環(huán)境，但是 pipe pool 的引入對使用 Go 的 io 標(biāo)準(zhǔn)庫并基于 splice 進行高頻的零拷貝操作的性能必定會有數(shù)量級的提升。

這個特性最快應(yīng)該會在今年下半年的 Go 1.17 版本發(fā)布，到時就可以享受到 pipe pool 帶來的性能提升了。

小結(jié)

通過給 Go 語言實現(xiàn)一個 pipe pool，期間涉及了多種并發(fā)、同步的優(yōu)化思路，我們再來歸納總結(jié)一下。

1. 資源復(fù)用，提升并發(fā)編程性能最有效的手段一定是資源復(fù)用，也是最立竿見影的優(yōu)化手段。
2. 數(shù)據(jù)結(jié)構(gòu)的選取，數(shù)組支持 O(1) 隨機訪問并且能更好地利用 CPU cache，但是這些優(yōu)勢在 pool 的場景下并不明顯，因為 pool 中的資源具有等價性和單個存取(非批量)操作，數(shù)組需要預(yù)先分配固定內(nèi)存并且伸縮的時候會有額外的內(nèi)存管理負擔(dān)，鏈表隨取隨棄，天然支持動態(tài)伸縮。
3. 全局鎖的優(yōu)化，兩種思路，一種是根據(jù)資源的特性嘗試對鎖的粒度進行降級，一種是通過引入本地緩存，嘗試錯開多線程對資源的訪問，減少競爭全局鎖的頻次；還有就是根據(jù)實際場景適當(dāng)?shù)剡x擇用戶態(tài)鎖。
4. 利用語言的 runtime，像 Go、Java 這類自帶一個龐大的 GC 的編程語言，在性能上一般不是 C/C++/Rust 這種無 GC 語言的對手，但是凡事有利有弊，自帶 runtime 的語言也具備獨特的優(yōu)勢，比如 HAProxy 的 pipe pool 是 C 實現(xiàn)的，在進程的生命周期中創(chuàng)建的 pipe buffers 會一直存在占用資源（除非主動關(guān)閉，但是很難準(zhǔn)確把控時機），而 Go 實現(xiàn)的 pipe pool 則可以利用自身的 runtime 進行定期的清理工作，進一步減少資源占用。

參考&延伸

• sync.Pool
• pipe pool in HAProxy
• internal/poll: implement a pipe pool for splice() call
• internal/poll: fix the intermittent build failures with pipe pool
• internal/poll: ensure that newPoolPipe doesn't return a nil pointer
• internal/poll: cast off the last reference of SplicePipe in test
• Use Thread-local Storage to Reduce Synchronization
• ELF Handling For Thread-Local Storage