1. 簡(jiǎn)介

我們?cè)?Sync.Pool: 提高go語(yǔ)言程序性能的關(guān)鍵一步 一文中，已經(jīng)了解了使用sync.Pool來(lái)實(shí)現(xiàn)對(duì)象的復(fù)用以減少對(duì)象的頻繁創(chuàng)建和銷(xiāo)毀，以及使用sync.Pool的一些常見(jiàn)注意事項(xiàng)。

在這篇文章中，我們將剖析sync.Pool內(nèi)部實(shí)現(xiàn)中，介紹了sync.Pool比較巧妙的內(nèi)部設(shè)計(jì)思路以及其實(shí)現(xiàn)方式。在這個(gè)過(guò)程中，也間接介紹了為何不加鎖也能夠?qū)崿F(xiàn)線程安全。

主要會(huì)涉及到Go語(yǔ)言中實(shí)現(xiàn)并發(fā)的GMP模型以及其基本的調(diào)度原理，以及本地緩存的設(shè)計(jì)，無(wú)鎖隊(duì)列的使用這幾個(gè)部分的內(nèi)容，綜上這幾個(gè)方面的內(nèi)容實(shí)現(xiàn)了不加鎖也能夠保證線程安全。

2. GMP之間的綁定關(guān)系

為了之能夠幫助我們后續(xù)更好得理解sync.Pool的設(shè)計(jì)與實(shí)現(xiàn)，這里需要對(duì)GMP模型進(jìn)行簡(jiǎn)單的介紹。GMP模型是Go語(yǔ)言中的一種協(xié)作式調(diào)度模型，其中G表示Goroutine，M可以理解為內(nèi)核線程，P為邏輯處理器，簡(jiǎn)單理解其維護(hù)了一條Goroutine隊(duì)列。

2.1 M和P的關(guān)系

在GMP模型中，M和P可以動(dòng)態(tài)綁定，一個(gè)M可以在運(yùn)行時(shí)綁定到任意一個(gè)P上，而一個(gè)P也可以與任意一個(gè)M綁定。這種綁定方式是動(dòng)態(tài)的，可以根據(jù)實(shí)際情況進(jìn)行靈活調(diào)整，從而實(shí)現(xiàn)更加高效的協(xié)程調(diào)度。

盡管M和P可以動(dòng)態(tài)綁定，但在特定時(shí)間點(diǎn)，一個(gè)M只會(huì)對(duì)應(yīng)一個(gè)P。這是因?yàn)镸是操作系統(tǒng)線程，而P是Go語(yǔ)言的邏輯處理器，Go語(yǔ)言的邏輯處理器需要在某個(gè)操作系統(tǒng)線程中運(yùn)行，并且是被該邏輯處理器(P)單獨(dú)占用的。

P的數(shù)量一般是和CPU核數(shù)保持一致，每個(gè)P占用一個(gè)CPU核心來(lái)執(zhí)行，可以通過(guò)runtime.GOMAXPROCS函數(shù)來(lái)修改。不過(guò)在大多數(shù)情況下，不需要手動(dòng)修改，Go語(yǔ)言的調(diào)度器會(huì)根據(jù)實(shí)際情況自動(dòng)進(jìn)行調(diào)整。

2.2 P和G的關(guān)系

剛創(chuàng)建的Goroutine會(huì)被放入當(dāng)前線程對(duì)應(yīng)P的本地隊(duì)列中等待被執(zhí)行。如果本地隊(duì)列已滿，則會(huì)放入全局隊(duì)列中，供其他線程的P來(lái)?yè)屨紙?zhí)行。

當(dāng)P空閑時(shí)，會(huì)嘗試從全局隊(duì)列中獲取Goroutine來(lái)執(zhí)行。如果全局隊(duì)列中沒(méi)有Goroutine，則會(huì)從其他處理器的本地運(yùn)行隊(duì)列中"偷取"一些Goroutine來(lái)執(zhí)行。

如果協(xié)程執(zhí)行過(guò)程中遇到阻塞操作（比如等待I/O或者鎖），處理器（P）會(huì)立即將協(xié)程移出本地運(yùn)行隊(duì)列，并執(zhí)行其他協(xié)程，直到被阻塞的協(xié)程可以繼續(xù)執(zhí)行為止。被阻塞的協(xié)程會(huì)被放到相應(yīng)的等待隊(duì)列中等待事件發(fā)生后再次被喚醒并加入到運(yùn)行隊(duì)列中，但不一定還是放回原來(lái)的處理器(P)的等待隊(duì)列中。

從上述過(guò)程可以看出，G和P的綁定關(guān)系是動(dòng)態(tài)綁定的，在不同的時(shí)間點(diǎn)，同一個(gè)G可能在不同的P上執(zhí)行，同時(shí)，在不同的時(shí)間點(diǎn)，P也會(huì)調(diào)度執(zhí)行不同的G。

2.3 總結(jié)

每個(gè)P在某個(gè)時(shí)刻只能綁定一個(gè)M，而每個(gè)G在某個(gè)時(shí)刻也只存在于某個(gè)P的等待隊(duì)列中，等待被調(diào)度執(zhí)行。這是GMP模型的基本調(diào)度原理，也是Go語(yǔ)言高效調(diào)度的核心所在。通過(guò)動(dòng)態(tài)綁定和靈活調(diào)度，可以充分利用多核處理器的計(jì)算能力，從而實(shí)現(xiàn)高并發(fā)、高效率的協(xié)程調(diào)度。

通過(guò)對(duì)GMP模型的基本了解，能夠幫助我們后續(xù)更好得理解sync.Pool的設(shè)計(jì)與實(shí)現(xiàn)。

3.Sync.Pool與GMP模型

3.1 sync.Pool性能問(wèn)題

這里我們回到sync.Pool, 可以簡(jiǎn)單使用切片，存儲(chǔ)可復(fù)用的對(duì)象，在需要時(shí)從中取出對(duì)象，用完之后再重新放回池子中，實(shí)現(xiàn)對(duì)象的重復(fù)使用。

當(dāng)多個(gè)協(xié)程同時(shí)從 sync.Pool 中取對(duì)象時(shí)，會(huì)存在并發(fā)問(wèn)題，因此需要實(shí)現(xiàn)并發(fā)安全。一種簡(jiǎn)單的實(shí)現(xiàn)方式是加鎖，每個(gè)協(xié)程在取數(shù)據(jù)前先加鎖，然后獲取數(shù)據(jù)，再解鎖，實(shí)現(xiàn)串行讀取的效果。但是這種方式在并發(fā)比較大的場(chǎng)景下容易導(dǎo)致大量協(xié)程進(jìn)入阻塞狀態(tài)，從而進(jìn)一步降低性能。

因此，為了提高程序的性能，我們需要尋找一種減少并發(fā)沖突的方式。有什么方式能夠減少并發(fā)沖突呢?

3.2 基于GMP模型的改進(jìn)

回到GMP模型，從第二節(jié)對(duì)GMP模型的介紹中，我們知道協(xié)程(G)需要在邏輯處理器(P)上執(zhí)行，而邏輯處理器的數(shù)量是有限的，一般與CPU核心數(shù)相同。而之前的sync.Pool實(shí)現(xiàn)方式是所有P競(jìng)爭(zhēng)同一份數(shù)據(jù)，容易導(dǎo)致大量協(xié)程進(jìn)入阻塞狀態(tài)，影響程序性能。

那我們這里，是不是能夠?qū)?sync.Pool 分成多個(gè)小的存儲(chǔ)池，每個(gè)P都用擁有一個(gè)小的存儲(chǔ)池呢? 在每個(gè)小存儲(chǔ)池中分別使用獨(dú)立的鎖進(jìn)行并發(fā)控制。這樣可以避免多個(gè)協(xié)程同時(shí)競(jìng)爭(zhēng)同一個(gè)全局鎖的情況，降低鎖的粒度，從而減少并發(fā)沖突。

協(xié)程運(yùn)行時(shí)都需要綁定一個(gè)邏輯處理器(P)，此時(shí)每個(gè)P都有自己的數(shù)據(jù)緩存，需要對(duì)象時(shí)從綁定的P的緩存中獲取，用完后重新放回。這種實(shí)現(xiàn)方式減少了協(xié)程競(jìng)爭(zhēng)同一份數(shù)據(jù)的情況，只有在同一個(gè)邏輯處理器上的協(xié)程才存在競(jìng)爭(zhēng)，從而減少并發(fā)沖突，提升性能。

3.3 能不能完全不加鎖

在上面的實(shí)現(xiàn)中，處于不同的P上的協(xié)程都是操作不同的數(shù)據(jù)，此時(shí)并不會(huì)出現(xiàn)并發(fā)問(wèn)題。唯一可能出現(xiàn)并發(fā)問(wèn)題的地方，為協(xié)程在獲取緩存對(duì)象時(shí)，邏輯處理器中途調(diào)度其他協(xié)程來(lái)執(zhí)行，此時(shí)才可能導(dǎo)致的并發(fā)問(wèn)題。那這里能不能避免并發(fā)呢?

那如果能夠?qū)f(xié)程固定到邏輯處理器P上，并且不允許被搶占，也就是該P(yáng)上永遠(yuǎn)都是執(zhí)行某一個(gè)協(xié)程，直到成功獲取緩存對(duì)象后，才允許邏輯處理器去調(diào)度執(zhí)行其他協(xié)程，那么就可以完全避免并發(fā)沖突的問(wèn)題了。

因此，如果我們能夠做到協(xié)程在讀取緩沖池中的數(shù)據(jù)時(shí)，能夠完全占用邏輯處理器P，不會(huì)被搶占，此時(shí)就不會(huì)出現(xiàn)并發(fā)了，也不需要加鎖了。

幸運(yùn)的是，runtime包中提供了runtime_procPin調(diào)用，可以將當(dāng)前協(xié)程固定到協(xié)程所在邏輯處理器P上，并且不允許被搶占，也就是邏輯處理器P一直都被當(dāng)前協(xié)程所獨(dú)享。在獲取緩存對(duì)象時(shí)，我們可以使用runtime_procPin將當(dāng)前協(xié)程固定到邏輯處理器P上，然后從該邏輯處理器P的緩存中獲取對(duì)象。這樣做不僅可以避免并發(fā)沖突，還可以避免上下文切換和鎖競(jìng)爭(zhēng)等性能問(wèn)題。

4. sync.Pool初步實(shí)現(xiàn)

下面來(lái)看看當(dāng)前sync.Pool的部分代碼，其原理便是上述所提到的方式。具體來(lái)說(shuō)，每個(gè)邏輯處理器P保存一份數(shù)據(jù)，并利用runtime_procPin來(lái)避免同一邏輯處理器P中的協(xié)程發(fā)生并發(fā)沖突。

需要注意的是，下面所展示的代碼只是部分代碼，并不包含完整的實(shí)現(xiàn)。但是這些代碼涵蓋了前面所提到的實(shí)現(xiàn)方式。同時(shí)，為了講述方便，也修改部分實(shí)現(xiàn)，后文會(huì)說(shuō)明當(dāng)前sync.Pool當(dāng)前真正的實(shí)現(xiàn)。

4.1 sync.Pool結(jié)構(gòu)體定義

type Pool struct {
   // 指向 poolLocal 結(jié)構(gòu)體切片的地址，長(zhǎng)度與cpu核心數(shù)保持一致
   local     unsafe.Pointer // local fixed-size per-P pool, actual type is [P]poolLocal
   // 記錄當(dāng)前 poolLocal 切片的長(zhǎng)度
   localSize uintptr        // size of the local array
   // New optionally specifies a function to generate
   // a value when Get would otherwise return nil.
   // It may not be changed concurrently with calls to Get.
   New func() any
}

type poolLocal struct {
   // 上文所說(shuō)的小緩沖池的實(shí)現(xiàn)
   private []any       // Can be used only by the respective P.
}

其中，New 函數(shù)用于創(chuàng)建一個(gè)新的對(duì)象，以便向池中添加對(duì)象。當(dāng)池中沒(méi)有可用對(duì)象時(shí)，會(huì)調(diào)用該函數(shù)。local 是指向 poolLocal 切片的指針，poolLocal 即為上文提到的小緩沖池，每個(gè)邏輯處理器都有一個(gè)。

4.2 Put方法

func (p *Pool) Put(x any) {
   if x == nil {
      return
   }
   // 這里調(diào)用pin方法,獲取到poolLocal
   l, _ := p.pin()
   // 將對(duì)象重新放入邏輯處理的小緩沖池當(dāng)中
   l.private = l.private.append(x)
   // 這個(gè)為解除 Proccssor的固定，Processor能夠調(diào)度其他協(xié)程去執(zhí)行
   runtime_procUnpin()
}

Put方法是用于將對(duì)象重新放入緩沖池，首先調(diào)用pin方法獲取到poolLocal,然后將對(duì)象放入到poolLocal當(dāng)中，然后再通過(guò)runtime_procUnpin調(diào)用，解除對(duì)當(dāng)前P的綁定。

可以發(fā)現(xiàn)，其中比較重要的邏輯，是調(diào)用pin方法獲取到P對(duì)應(yīng)的poolLocal,下面我們來(lái)看pin方法的實(shí)現(xiàn)。

func (p *Pool) pin() (*poolLocal, int) {
    // 調(diào)用runtime_procPin,占用Processor,不會(huì)被搶占
   pid := runtime_procPin()
   // 獲取localSize字段的值
   s := runtime_LoadAcquintptr(&p.localSize) // load-acquire
   // 獲取poolLocal切片
   l := p.local                              // load-consume
   // pid為協(xié)程編號(hào)，如果pid < localSize的值，說(shuō)明屬于該processor的緩沖池已經(jīng)創(chuàng)建好了
   if uintptr(pid) < s {
      // 根據(jù)pid獲取對(duì)應(yīng)的緩沖池
      return indexLocal(l, pid), pid
   }
   // 否則走下面邏輯
   return p.pinSlow()
}
func indexLocal(l unsafe.Pointer, i int) *poolLocal {
   // 直接通過(guò)Processor的編號(hào)，計(jì)算出偏移量獲取到對(duì)應(yīng)的poolLocal
   lp := unsafe.Pointer(uintptr(l) + uintptr(i)*unsafe.Sizeof(poolLocal{}))
   return (*poolLocal)(lp)
}

在函數(shù)開(kāi)始時(shí)，pin方法通過(guò)調(diào)用runtime_procPin方法，占用當(dāng)前goroutine所在的P，不允許其他goroutine搶占該P(yáng)，這里能夠避免處于同一等待隊(duì)列中的協(xié)程出現(xiàn)并發(fā)讀取poolLocal的數(shù)據(jù)的問(wèn)題。

同時(shí)runtime_procPin方法也會(huì)返回當(dāng)前P的編號(hào)，在系統(tǒng)內(nèi)部是唯一的，從0開(kāi)始依次遞增的整數(shù)。其將能夠作為poolLocal的切片下標(biāo)，來(lái)讀取poolLocal。

接下來(lái)，通過(guò)原子操作runtime_LoadAcquintptr讀取localSize字段的值，該字段表示當(dāng)前poolLocal實(shí)例切片的長(zhǎng)度。如果當(dāng)前的P編號(hào)小于localSize的值，則表示該P(yáng)的poolLocal實(shí)例已經(jīng)被創(chuàng)建，可以直接獲取該P(yáng)對(duì)應(yīng)的poolLocal實(shí)例并返回。

如果P編號(hào)大于等于localSize的值，此時(shí)說(shuō)明該P(yáng)對(duì)應(yīng)的poolLocal還沒(méi)創(chuàng)建，通過(guò)調(diào)用pinSlow()方法進(jìn)行初始化。下面繼續(xù)來(lái)看pinSlow方法的具體實(shí)現(xiàn)。

func (p *Pool) pinSlow(pid int) (*poolLocal, int) {
   // 獲取processor數(shù)量
   size := runtime.GOMAXPROCS(0)
   // 創(chuàng)建一個(gè)新的poolLocal切片
   local := make([]poolLocal, size)
   // 將切片地址存儲(chǔ)到local字段當(dāng)中
   atomic.StorePointer(&p.local, unsafe.Pointer(&local[0])) // store-release
   // 將切片數(shù)組長(zhǎng)度 存儲(chǔ)到 localSize 當(dāng)中
   runtime_StoreReluintptr(&p.localSize, uintptr(size))     // store-release
   // 根據(jù)pid,獲取到對(duì)應(yīng)的poolLocal
   return &local[pid], pid
}

首先調(diào)用 runtime.GOMAXPROCS(0) 獲取當(dāng)前程序可用的 processor 數(shù)量，并基于這個(gè)數(shù)量創(chuàng)建了一個(gè)新的 poolLocal 切片 local，這里也印證了我們之前所說(shuō)的，每一個(gè)Processor都有一個(gè)小緩沖池。

接著，使用原子操作 atomic.StorePointer 將指向 p.local 的指針修改為指向新創(chuàng)建的 local 切片的第一個(gè)元素的指針。然后使用 runtime_StoreReluintptr 原子操作將 p.localSize 修改為 size。到此為止，便完成了poolLocal切片的初始化操作。

最后返回當(dāng)前 processor 對(duì)應(yīng)的 poolLocal 指針和它的編號(hào) pid。由于這里新創(chuàng)建的 local 切片是局部變量，在 pinSlow 函數(shù)返回后，它就無(wú)法被訪問(wèn)了。但是，由于我們已經(jīng)將 p.local 修改為指向這個(gè)切片的第一個(gè)元素的指針，所以其他 processor在調(diào)用 pin 方法時(shí)，就能獲取到新創(chuàng)建的 poolLocal。

4.3 Get方法

func (p *Pool) Get() any {
   l, pid := p.pin()
   var x any
   if n := len(l.private); n > 0 {
       x = l.private[n-1]
       l.private[n-1] = nil // Just to be safe
       l.private = l.private[:n-1]
   }
   runtime_procUnpin()
   if x == nil && p.New != nil {
      x = p.New()
   }
   return x
}

首先調(diào)用pin()方法，獲得當(dāng)前協(xié)程綁定的緩存池local和協(xié)程編號(hào)pid。接著從local.private中嘗試取出對(duì)象，如果取出來(lái)是空，說(shuō)明緩沖池中沒(méi)有對(duì)象，此時(shí)調(diào)用runtime_procUnpin()方法解綁協(xié)程與處理器的綁定。

如果沒(méi)有從緩沖池中成功獲取對(duì)象，并且Pool結(jié)構(gòu)體的New字段非空，則調(diào)用New字段所指向的函數(shù)創(chuàng)建一個(gè)新對(duì)象并返回。

4.4 總結(jié)

到此為止，sync.Pool已經(jīng)通過(guò)結(jié)合GMP模型的特點(diǎn)，給每一個(gè)P設(shè)置一份緩存數(shù)據(jù)，當(dāng)邏輯處理器上的協(xié)程需要從sync.Pool獲取可重用對(duì)象時(shí)，此時(shí)將從邏輯處理器P對(duì)應(yīng)的緩存中取出對(duì)象，避免了不同邏輯處理器的競(jìng)爭(zhēng)。

此外，也通過(guò)調(diào)用runtime_procPin方法，讓協(xié)程能夠在某段時(shí)間獨(dú)占該邏輯處理器，避免了鎖的競(jìng)爭(zhēng)和不必要的上下文切換的消耗，從而提升性能。

5. sync.Pool實(shí)現(xiàn)優(yōu)化

5.1 問(wèn)題描述

在sync.Pool的初步實(shí)現(xiàn)中，我們讓每一個(gè)邏輯處理器P都擁有一個(gè)小緩沖池，讓各個(gè)邏輯處理器P上的協(xié)程從sync.Pool獲取對(duì)象時(shí)不會(huì)競(jìng)爭(zhēng)，從而提升性能。

現(xiàn)在可能存在的問(wèn)題，在于每個(gè) Processor 都保存一份緩存數(shù)據(jù)，那么當(dāng)某個(gè) Processor 上的 goroutine 需要使用緩存時(shí)，可能會(huì)發(fā)現(xiàn)它所在的 Processor 上的緩存池為空的，而其他 Processor 上的緩存對(duì)象卻沒(méi)有被利用。這樣就浪費(fèi)了其他 Processor 上的資源。

回到sync.Pool的設(shè)計(jì)初衷來(lái)看，首先是提升程序性能，減少重復(fù)創(chuàng)建和銷(xiāo)毀對(duì)象的開(kāi)銷(xiāo)；其次是減少內(nèi)存壓力，通過(guò)對(duì)象復(fù)用，從而降低程序GC頻次。從這兩個(gè)方面來(lái)看，上面sync.Pool的初步實(shí)現(xiàn)其實(shí)存在一些優(yōu)化空間的。

這里就陷入了一個(gè)兩難的境地，如果多個(gè)Processor共享同一個(gè)緩沖池，會(huì)存在容易導(dǎo)致大量協(xié)程進(jìn)入阻塞狀態(tài)，進(jìn)一步降低性能。每個(gè) Processor 都保存一份緩存數(shù)據(jù)的話，此時(shí)也容易陷入資源浪費(fèi)的問(wèn)題。那能怎么辦呢?

5.2 實(shí)現(xiàn)優(yōu)化

很多時(shí)候，可能并沒(méi)有十全十美的事情，我們往往需要折中。比如上面多個(gè)Processor共享同一個(gè)緩沖池，會(huì)降低性能；而每個(gè) Processor 都保存一份緩存數(shù)據(jù)的話，容易陷入資源浪費(fèi)的問(wèn)題。

這個(gè)時(shí)候，我們可以折中一下，不采用完全共享的模式，也不采用完全獨(dú)占的模式。而采用部分獨(dú)有、部分共享的模式。每個(gè) Processor 獨(dú)占一部分緩存，可以避免不同 Processor 之間的競(jìng)爭(zhēng)，提高并發(fā)性能。同時(shí)，每個(gè) Processor 也可以共享其他 Processor 上的緩存，避免了浪費(fèi)。相對(duì)于完全共享和完全獨(dú)立的模式，這種設(shè)計(jì)方式是不是能夠更好地平衡并發(fā)性能和緩存利用效率。

同時(shí)，也可以基于部分獨(dú)有，部分共享的模式的基礎(chǔ)上，再對(duì)其進(jìn)行優(yōu)化。對(duì)于共享部分的資源，可以使用多個(gè)緩沖池來(lái)存儲(chǔ)，是將其給了所有的Processor，每個(gè)Processor保留一部分共享數(shù)據(jù)。

當(dāng)Processor讀取數(shù)據(jù)時(shí)，此時(shí)先從自身的私有緩沖中讀取，讀取不到再到自身的共享緩存中讀取，讀取不到才到其他Processor讀取其共享部分。這樣子能夠避免了多個(gè)Processor同時(shí)競(jìng)爭(zhēng)一個(gè)池導(dǎo)致的性能問(wèn)題。同時(shí)，共享部分也可以被充分利用，避免了資源浪費(fèi)。

6.Sync.Pool最終實(shí)現(xiàn)

6.1 sync.Pool結(jié)構(gòu)體定義

type Pool struct {
   noCopy noCopy
   // 1. 指向poolLocal切片的指針
   local     unsafe.Pointer // local fixed-size per-P pool, actual type is [P]poolLocal
   // 2. 對(duì)應(yīng)local切片的長(zhǎng)度
   localSize uintptr        // size of the local array
   // 3. 緩存池中沒(méi)對(duì)象時(shí)，調(diào)用設(shè)置的New函數(shù)來(lái)創(chuàng)建對(duì)象
   New func() any
   // 部分與此次講述無(wú)關(guān)內(nèi)容,未被包含進(jìn)來(lái)
   // ....
}

// 每個(gè)Processor都會(huì)對(duì)應(yīng)一個(gè)poolLocal
type poolLocal struct {
   // 存儲(chǔ)緩存對(duì)象的數(shù)據(jù)結(jié)構(gòu)
   poolLocalInternal
   // 用于內(nèi)存對(duì)齊
   pad [128 - unsafe.Sizeof(poolLocalInternal{})%128]byte
}

// Local per-P Pool appendix.
type poolLocalInternal struct {
   // 存儲(chǔ)每個(gè)Processor獨(dú)享的對(duì)象
   private any       // Can be used only by the respective P.
   // 存儲(chǔ)Processor共享的對(duì)象，這個(gè)是一個(gè)無(wú)鎖隊(duì)列
   shared  poolChain // Local P can pushHead/popHead; any P can popTail.
}

首先說(shuō)明poolLocal結(jié)構(gòu)體，可以認(rèn)為是一個(gè)小緩沖池，每個(gè)Processor都會(huì)有對(duì)應(yīng)的poolLocal對(duì)象。poolLocal中對(duì)象的存儲(chǔ)通過(guò)poolLocalInternal來(lái)實(shí)現(xiàn)，至于poolLocal中的pad字段只是用于內(nèi)存對(duì)其。

poolLocalInternal其中包含private字段和shared字段，private字段保存了上文所說(shuō)的Processor獨(dú)占的緩存對(duì)象，而shared字段，也就是我們上文所說(shuō)的共享緩沖池組成的一部分，是允許Processor之間相互讀取的。shared字段的類型為poolChain，是一個(gè)無(wú)鎖隊(duì)列，調(diào)用pushHead能夠?qū)?shù)據(jù)放入共享緩沖池，調(diào)用popHead能夠從緩沖池中取出數(shù)據(jù)，無(wú)需加鎖也是并發(fā)安全的，這個(gè)并非今日的重點(diǎn)，在此簡(jiǎn)單描述一下。

Pool結(jié)構(gòu)體中local字段，指向了poolLocal結(jié)構(gòu)體切片的地址，而localSize字段的值，為前面poolLocal切片的長(zhǎng)度。

6.2 Get方法

func (p *Pool) Get() any {
   l, pid := p.pin()
   x := l.private
   l.private = nil
   if x == nil {
      // Try to pop the head of the local shard. We prefer
      // the head over the tail for temporal locality of
      // reuse.
      x, _ = l.shared.popHead()
      if x == nil {
         x = p.getSlow(pid)
      }
   }
   runtime_procUnpin()
   if x == nil && p.New != nil {
      x = p.New()
   }
   return x
}

首先調(diào)用pin()方法，獲取當(dāng)前Processor對(duì)應(yīng)的poolLocal對(duì)象和協(xié)程編號(hào)pid，同時(shí)占用該P(yáng)rocessor。

開(kāi)始嘗試獲取對(duì)象，首先從poolLocal對(duì)象中獲取私有緩存private。如果私有緩存為空，則嘗試從共享緩存shared的頭部彈出一個(gè)元素x，并賦值給x。如果共享緩存也為空，則調(diào)用getSlow()方法從其他Processor的共享緩存或New方法中獲取元素x。釋放當(dāng)前Processor的占用。如果元素x不為空，則返回x，否則如果New方法不為空，則調(diào)用New方法生成一個(gè)新的元素x并返回，否則返回nil。

可以看出來(lái)，在Get方法的外層，主要是嘗試從Proessor對(duì)應(yīng)的poolLocal中獲取數(shù)據(jù)，讀取不到，則調(diào)用getSlow方法，嘗試從其他Processor的共享數(shù)據(jù)中獲取。下面來(lái)看getSlow方法的邏輯:

func (p *Pool) getSlow(pid int) any {
   // See the comment in pin regarding ordering of the loads.
   size := runtime_LoadAcquintptr(&p.localSize) // load-acquire
   locals := p.local                            // load-consume
   // Try to steal one element from other procs.
   for i := 0; i < int(size); i++ {
      // 獲取poolLocal
      l := indexLocal(locals, (pid+i+1)%int(size))
      // poolLocal中的shared是一個(gè)無(wú)鎖隊(duì)列，無(wú)需加鎖，也能夠保證線程安全
      if x, _ := l.shared.popTail(); x != nil {
         return x
      }
   }
   // 與sync.Pool對(duì)象回收的相關(guān)邏輯先刪除,與此次講述并無(wú)太大關(guān)系
   // ....

   return nil
}

getSlow方法實(shí)現(xiàn)較為簡(jiǎn)單，首先讀取Pool結(jié)構(gòu)體中localSize字段的值，得知當(dāng)前有多少個(gè)poolLocal。然后對(duì)所有的poolLocal進(jìn)行遍歷，嘗試從其他poolLocal的共享緩存中獲取數(shù)據(jù)，成功獲取則直接返回。

6.3 Put方法

func (p *Pool) Put(x any) {
   if x == nil {
      return
   }
   l, _ := p.pin()
   if l.private == nil {
      l.private = x
      x = nil
   }
   if x != nil {
      l.shared.pushHead(x)
   }
   runtime_procUnpin()
}

首先調(diào)用pin方法，獲取當(dāng)前Processor對(duì)應(yīng)的poolLocal，然后將x放到該poolLocal的private字段中，也就是放到當(dāng)前Processor的私有緩存中。如果private字段不為空，說(shuō)明已經(jīng)有對(duì)象放到private中了，那么x則會(huì)放到poolLocal的shared字段中，通過(guò)無(wú)鎖隊(duì)列的方式加入到共享資源池中。

6.4 總結(jié)

到此為止，在sync.Pool原本的實(shí)現(xiàn)上，對(duì)緩存數(shù)據(jù)的設(shè)計(jì)進(jìn)行了優(yōu)化，將緩存數(shù)據(jù)中區(qū)分為私有緩存部分和共享部分。此時(shí)在一定程度上避免不同 Processor 之間的競(jìng)爭(zhēng)，提高并發(fā)性能。同時(shí)，每個(gè) Processor 也可以共享其他 Processor 上的緩存，避免了內(nèi)存的浪費(fèi)。

7.總結(jié)

這篇文章，我們其實(shí)主要介紹了sync.Pool的實(shí)現(xiàn)原理。

我們首先基于GMP模型完成sync.Pool的一個(gè)實(shí)現(xiàn)，基于該實(shí)現(xiàn)，引出了部分獨(dú)有、部分共享的模式的優(yōu)化。在這個(gè)過(guò)程中，也展示了sync.Pool的部分源碼，以便能夠更好得理解sync.Pool的實(shí)現(xiàn)。

同時(shí)，基于實(shí)現(xiàn)的講述，我們也間接得解答了sync.Pool為何不需要加鎖也保證了線程安全的問(wèn)題。

這次講述sync.Pool的實(shí)現(xiàn)過(guò)程中，并沒(méi)有直接講述sync.Pool源碼的實(shí)現(xiàn)，而是一步一步得對(duì)現(xiàn)有實(shí)現(xiàn)進(jìn)行優(yōu)化，將其中比較好的點(diǎn)給描述出來(lái)，希望能夠有所幫助。

以上就是詳解Go語(yǔ)言Sync.Pool為何不加鎖也能夠?qū)崿F(xiàn)線程安全的詳細(xì)內(nèi)容，更多關(guān)于Go Sync.Pool的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！