Go 1.4Beta1剛剛發(fā)布，在Go 1.4Beta1中，Go語(yǔ)言的stack處理方式由之前的"segmented stacks"改為了"continuous stacks"。關(guān)于Go語(yǔ)言對(duì)stack的處理機(jī)制、發(fā)展歷史、存在問(wèn)題等，CloudFlare的一篇官方blog進(jìn)行了系統(tǒng)的闡述，這里的內(nèi)容就是 翻譯自CloudFlare的那篇blog：《How Stacks are Handled in Go》。

在CloudFlare，我們使用Go語(yǔ)言實(shí)現(xiàn)各種服務(wù)和應(yīng)用。在這篇博文中，我們將帶領(lǐng)大家深入挖掘一些Go的某些紛繁復(fù)雜的技術(shù)細(xì)節(jié)。

Go語(yǔ)言的重要特性之一是goroutines。它們是代價(jià)低廉、協(xié)同調(diào)度的執(zhí)行線程，被用于實(shí)現(xiàn)各種操作，諸如timeout、生成器、相互競(jìng) 爭(zhēng)的后端程序。為了使goroutines可以適應(yīng)更多地任務(wù)，我們不僅需要保證每個(gè)goroutines的內(nèi)存最小占用量，還要保證人們可以使 用***配置將它們啟動(dòng)起來(lái)。

為了實(shí)現(xiàn)這個(gè)目標(biāo)，Go語(yǔ)言采用了棧管理，這一與其他編程語(yǔ)言類似的方案，但在具體實(shí)現(xiàn)層面，又與其他語(yǔ)言有著較大的不同。

一、線程棧(thread stacks)介紹

在我們研究Go的棧處理方式之前，我們先來(lái)看看傳統(tǒng)語(yǔ)言，比如C是如何進(jìn)行棧管理的。

當(dāng)你啟動(dòng)一個(gè)C實(shí)現(xiàn)的thread時(shí)，C標(biāo)準(zhǔn)庫(kù)會(huì)負(fù)責(zé)分配一塊內(nèi)存作為這個(gè)線程的棧。標(biāo)準(zhǔn)庫(kù)分配這塊內(nèi)存，告訴內(nèi)核它的位置并讓內(nèi)核處理這個(gè)線程 的執(zhí)行。不過(guò)當(dāng)這塊內(nèi)存不夠用時(shí)，問(wèn)題就來(lái)了，我們來(lái)看一下下面這個(gè)函數(shù)：

int a(int m, int n) { 
    if (m == 0) { 
        return n + 1; 
    } else if (m > 0 && n == 0) { 
        return a(m – 1, 1); 
    } else { 
        return a(m – 1, a(m, n – 1)); 
    } 
} 

這個(gè)函數(shù)大量使用遞歸，執(zhí)行a(4, 5)就會(huì)降所有棧內(nèi)存耗盡。要解決這個(gè)問(wèn)題，你可以調(diào)整標(biāo)準(zhǔn)庫(kù)給線程棧分配的內(nèi)存塊的大小。但是全線提高棧大小意味著每個(gè)線程都會(huì)提高棧的內(nèi)存使用量，即 便它們不是大量采用遞歸方式的。這樣一來(lái)，你將用光所有內(nèi)存，即便你的程序還尚未使用棧上的內(nèi)存。

另外一種可選的解決方法則是為每個(gè)線程單獨(dú)確定棧大小。這樣一來(lái)你就不得不完成這樣的任務(wù)：根據(jù)每個(gè)線程的需要，估算它們的棧內(nèi)存的大小。這將是 創(chuàng)建線程的難度超出我們的期望。想搞清楚一般情況下一個(gè)線程棧需要多少內(nèi)存是不可行的，即便是通常情況也是非常困難的。

二、Go是如何應(yīng)對(duì)這個(gè)問(wèn)題的

Go運(yùn)行時(shí)會(huì)試圖按需為goroutine提供它們所需要的?？臻g，而不是為每個(gè)goroutine分配一個(gè)固定大小的棧空間。這樣可以把程序員 們從決定棧空間大小的煩心事中解脫了出來(lái)。不過(guò)Go核心團(tuán)隊(duì)正在嘗試切換到另外一種方案，這里我將嘗試闡述舊方案以及它的缺點(diǎn)，新方案以及為何要 做出如此改變。

三、分段棧(Segmented Stacks)

分段棧(segmented stacks)是Go語(yǔ)言最初用來(lái)處理?xiàng)５姆桨?。?dāng)創(chuàng)建一個(gè)goroutine時(shí)，Go運(yùn)行時(shí)會(huì)分配一段8K字節(jié)的內(nèi)存用于棧供goroutine運(yùn)行使 用，我們讓goroutine在這個(gè)棧上完成其任務(wù)處理。

當(dāng)我們用光這8K字節(jié)的?？臻g后，問(wèn)題隨之而來(lái)。為了解決這個(gè)問(wèn)題，每個(gè)go函數(shù)在函數(shù)入口處都會(huì)有一小段代碼(called prologue)，這段代碼會(huì)檢查是否用光了已分配的?？臻g，如果用光了，這段代碼會(huì)調(diào)用morestack函數(shù)。

morestack函數(shù)會(huì)分配一段新內(nèi)存用作?？臻g，接下來(lái)它會(huì)將有關(guān)棧的各種數(shù)據(jù)信息寫入棧底的一個(gè)struct中(譯注：下圖中Stack info)，包括上一段棧的地址。有點(diǎn)我們擁有了一個(gè)新的棧段(stack segment)，我們將重啟goroutine，從導(dǎo)致棧空間用光的那個(gè)函數(shù)（譯注：下圖中的Foobar）開(kāi)始執(zhí)行。這就是所謂的“棧分裂 (stack split)”。

下面的棧示意圖剛好是我們進(jìn)行棧分裂后的情形：

在新棧的底部，我們插入了一個(gè)棧入口函數(shù)lessstack。我們不會(huì)調(diào)用該函數(shù)，設(shè)置這個(gè)函數(shù)就是用于我們從那個(gè)導(dǎo)致我們用光?？臻g的函數(shù)(譯 注：Foobar)返回時(shí)用的。當(dāng)那個(gè)函數(shù)(譯注：Foobar)返回時(shí)，我們回到lessstack（這個(gè)棧幀），lessstack會(huì)查找 stack底部的那個(gè)struct，并調(diào)整棧指針(stack pointer)，使得我們返回到前一段?？臻g。這樣做之后，我們就可以將這個(gè)新棧段(stack segment)釋放掉，并繼續(xù)執(zhí)行我們的程序了。

四、分段棧(Segmented stacks)的問(wèn)題

分段棧給了我們具備按需伸縮能力的棧。程序員們無(wú)需擔(dān)心計(jì)算棧的大小了，啟動(dòng)一個(gè)新的goroutine代價(jià)低廉并且程序員不會(huì)知道棧將增長(zhǎng)多 大。

這就是直到目前Go語(yǔ)言處理stack增長(zhǎng)的方法，但是這個(gè)方法有個(gè)瑕疵。那就是?？s小會(huì)是一個(gè)相對(duì)代價(jià)高昂的操作。如果你在一個(gè)循環(huán)遇到棧分裂 (stack split)，你會(huì)最有感觸。一個(gè)函數(shù)會(huì)增加?？臻g，做棧分裂，返回并釋放棧段(stack segment)。如果你在一個(gè)循環(huán)中進(jìn)行這些，你會(huì)付出很大的代價(jià)（性能方面）。

這就是所謂的“hot split”問(wèn)題。它也是Go核心開(kāi)發(fā)組更換到一個(gè)新的棧管理方案-棧拷貝(stack copying)的主要原因。

五、?？截?stack copying)

棧拷貝初始階段與分段棧類似。goroutine在棧上運(yùn)行著，當(dāng)用光?？臻g，它遇到與舊方案中相同的棧溢出檢查。但是與舊方案采用的保留一個(gè)返 回前一段棧的link不同，新方案創(chuàng)建一個(gè)兩倍于原stack大小的新stack，并將舊棧拷貝到其中。這意味著當(dāng)棧實(shí)際使用的空間縮小為原先的 大小時(shí)，go運(yùn)行時(shí)不用做任何事情。?？s小是一個(gè)無(wú)任何代價(jià)的操作。此外，當(dāng)棧再次增長(zhǎng)時(shí)，運(yùn)行時(shí)也無(wú)需做任何事情，我們只需要重用之前分配的空 閑空間即可。

六、棧是怎么拷貝的

拷貝棧聽(tīng)起來(lái)簡(jiǎn)單，但實(shí)際上它是一件有難度的事情。因?yàn)镚o中棧上的變量都有自己的地址，一旦你擁有指向棧上變量的指針，這種情況下你就無(wú)法如你 所愿。當(dāng)你移動(dòng)棧時(shí)，指向原棧的指針都將變?yōu)闊o(wú)效指針。

幸運(yùn)的是，只有在棧上分配的指針才能指向棧上的地址。這點(diǎn)對(duì)于內(nèi)存安全是極其必要的，否則，程序可能會(huì)訪問(wèn)到已不再使用了的棧上的地址。

由于我們需要知道那些需要被垃圾收集器回收的指針的位置，因此我們知道棧上哪些部分是指針。當(dāng)我們移動(dòng)棧時(shí)，我們可以更新棧里地指針使其指向新的 目標(biāo)地址，并且所有相關(guān)的指針都要被照顧到。

由于我們使用垃圾回收的信息來(lái)協(xié)助完成?？截悾虼怂谐霈F(xiàn)在棧上的函數(shù)都必須具備這些信息。但事情不總是這樣的。因?yàn)镚o運(yùn)行時(shí)的大部分代碼是 用C編寫的，大量的運(yùn)行時(shí)調(diào)用沒(méi)有指針信息可用，這樣就無(wú)法進(jìn)行拷貝。一旦這種情況發(fā)生，我們又不得不退回到分段棧方案，并接受為其付出的高昂代 價(jià)。

這就是當(dāng)前Go運(yùn)行時(shí)開(kāi)發(fā)者大規(guī)模重寫Go runtime的原因。那些無(wú)法用Go重寫的代碼，比如調(diào)度器和垃圾收集器的內(nèi)核，將在一個(gè)特殊的棧上執(zhí)行，這個(gè)特殊棧的size由runtime開(kāi)發(fā)者 單獨(dú)計(jì)算確定。

除了讓?？截惓蔀榭赡苤?，這個(gè)方法還會(huì)使得我們?cè)谖磥?lái)能夠?qū)崿F(xiàn)出并發(fā)垃圾回收等特性。

七、關(guān)于虛擬內(nèi)存

另外一種不同的棧處理方式就是在虛擬內(nèi)存中分配大內(nèi)存段。由于物理內(nèi)存只是在真正使用時(shí)才會(huì)被分配，因此看起來(lái)好似你可以分配一個(gè)大內(nèi)存段并讓操 作系統(tǒng)處理它。下面是這種方法的一些問(wèn)題

首先，32位系統(tǒng)只能支持4G字節(jié)虛擬內(nèi)存，并且應(yīng)用只能用到其中的3G空間。由于同時(shí)運(yùn)行百萬(wàn)goroutines的情況并不少見(jiàn)，因此你很可 能用光虛擬內(nèi)存，即便我們假設(shè)每個(gè)goroutine的stack只有8K。

第二，然而我們可以在64位系統(tǒng)中分配大內(nèi)存，它依賴于過(guò)量?jī)?nèi)存使用。所謂過(guò)量使用是指當(dāng)你分配的內(nèi)存大小超出物理內(nèi)存大小時(shí)，依賴操作系統(tǒng)保證 在需要時(shí)能夠分配出物理內(nèi)存。然而，允許過(guò)量使用可能會(huì)導(dǎo)致一些風(fēng)險(xiǎn)。由于一些進(jìn)程分配了超出機(jī)器物理內(nèi)存大小的內(nèi)存，如果這些進(jìn)程使用更多內(nèi)存 時(shí)，操作系統(tǒng)將不得不為它們補(bǔ)充分配內(nèi)存。這會(huì)導(dǎo)致操作系統(tǒng)將一些內(nèi)存段放入磁盤緩存，這常常會(huì)增加不可預(yù)測(cè)的處理延遲。正是考慮到這個(gè)原因，一 些新系統(tǒng)關(guān)閉了對(duì)過(guò)量使用的支持。

八、結(jié)論

為了使goroutine使用代價(jià)更加低廉，更快速，適合更多task情況，Go開(kāi)發(fā)組做出了很多努力。棧管理只是其中一小部分。如果你想了解更 多關(guān)于?？截惖募?xì)節(jié)，可以參考其設(shè)計(jì)文檔。此外，如果你想了解更多有關(guān)Go運(yùn)行 時(shí)重寫的細(xì)節(jié)，這里有一個(gè)mail list。