Go 1.2 值得關(guān)注的改動(dòng)：

• 為了提高安全性，Go 1.2 開始保證對(duì) nil 指針（包括指向結(jié)構(gòu)體、數(shù)組、接口、切片的 nil 指針）的解引用操作會(huì)觸發(fā)運(yùn)行時(shí) panic，避免了之前版本中可能存在的非法內(nèi)存訪問風(fēng)險(xiǎn)。編譯器可能會(huì)注入額外的檢查來實(shí)現(xiàn)這一點(diǎn)。
• 引入了三索引切片 (three-index slices) 語法 a[x:y:z]。其中 x 是起始索引（包含），y 是結(jié)束索引（不包含），決定了新切片的 length (y-x)。新增的 z 用于設(shè)置新切片的 capacity (z-x)，限制了新切片通過 reslicing 可訪問的底層數(shù)組范圍，且 z 不能超過原切片或數(shù)組的容量（相對(duì)于起始索引 x）。
• 調(diào)度器 (scheduler) 增加了搶占 (pre-emption) 功能。當(dāng)一個(gè) goroutine 進(jìn)入一個(gè)（非內(nèi)聯(lián)的）函數(shù)時(shí)，調(diào)度器有機(jī)會(huì)介入，允許其他 goroutine 獲得運(yùn)行機(jī)會(huì)，緩解了舊版本中沒有函數(shù)調(diào)用的緊密循環(huán) goroutine 可能餓死 (starve) 其他 goroutine 的問題（尤其在 GOMAXPROCS=1 時(shí)）。
• 引入了對(duì)單個(gè)程序可以創(chuàng)建的總操作系統(tǒng)線程數(shù)的限制（默認(rèn)為 10,000），以防止在某些環(huán)境下耗盡系統(tǒng)資源。這個(gè)限制可以通過 runtime/debug.SetMaxThreads 函數(shù)調(diào)整。注意這并不直接限制 goroutine 的數(shù)量，而是限制了同時(shí)阻塞在系統(tǒng)調(diào)用上的 goroutine 所需的線程數(shù)。
• goroutine 的最小棧空間從 4KB 增加到 8KB，以減少因棧頻繁增長切換段而帶來的性能損耗。同時(shí)，引入了最大?？臻g限制（64位系統(tǒng)默認(rèn)為 1GB，32位系統(tǒng)為 250MB），可通過 runtime/debug.SetMaxStack 設(shè)置，以防止無限遞歸等情況耗盡內(nèi)存。
• cgo 工具現(xiàn)在支持在鏈接的庫包含 C++ 代碼時(shí)調(diào)用 C++ 編譯器進(jìn)行構(gòu)建。
• Go 1.2 引入了測試覆蓋率 (test coverage) 工具。運(yùn)行 go test -cover 可以計(jì)算并報(bào)告語句覆蓋率百分比。通過安裝額外的 go tool cover 工具（位于 go.tools 子倉庫，需手動(dòng) go get code.google.com/p/go.tools/cmd/cover 安裝），可以生成和分析更詳細(xì)的覆蓋率報(bào)告文件 (coverage profile)。
• 新增了 encoding 包，定義了一組標(biāo)準(zhǔn)接口（BinaryMarshaler, BinaryUnmarshaler, TextMarshaler, TextUnmarshaler），用于統(tǒng)一自定義編組 (marshal) 和解組 (unmarshal) 邏輯，供 encoding/json、encoding/xml、encoding/binary 等包使用。

下面是一些值得展開的討論：

對(duì) nil 指針解引用會(huì) panic

在 Go 1.2 之前的版本中，對(duì)某些 nil 指針的解引用操作雖然邏輯上是錯(cuò)誤的，但可能不會(huì)立即導(dǎo)致程序崩潰。例如，考慮以下代碼：

package main

type T struct {
    X [1 << 24]byte // 一個(gè)非常大的數(shù)組，導(dǎo)致 Field 偏移量很大
    Field int32
}

func main() {
    var x *T // x 是 nil
    // 在 Go 1.2 之前，這行代碼可能不會(huì) panic
    // 它會(huì)嘗試訪問地址 0 + offset(Field) (即 1<<24)
    // 這可能會(huì)訪問到非法的內(nèi)存區(qū)域，或者恰好訪問到其他數(shù)據(jù)
    // _ = x.Field 
    
    // 在 Go 1.2 及之后，對(duì) nil 指針 x 的 .Field 操作保證會(huì) panic
    // fmt.Println(x.Field) // 這行會(huì)觸發(fā) panic: runtime error: invalid memory address or nil pointer dereference
}

這種行為是危險(xiǎn)的，因?yàn)樗赡軐?dǎo)致難以察覺的數(shù)據(jù)損壞或安全漏洞。為了提高內(nèi)存安全，Go 1.2 明確規(guī)定，任何顯式或隱式地需要對(duì) nil 地址進(jìn)行求值的表達(dá)式都是一個(gè)錯(cuò)誤。這包括：

通過 nil 指針訪問字段或數(shù)組元素：

var p *struct{ v int } // p is nil
// _ = p.v // 會(huì) panic

var a *[5]int // a is nil
// _ = (*a)[0] // 會(huì) panic

對(duì) nil 切片進(jìn)行索引或切片操作（讀取長度除外）：

var s []int // s is nil
// _ = len(s) // OK, returns 0
// _ = cap(s) // OK, returns 0
// _ = s[0]   // 會(huì) panic: index out of range [0] with length 0 (注意：這里 panic 的原因是 index out of range, 但根本原因是 slice 為 nil 沒有底層數(shù)組)
// _ = s[:]   // 不會(huì) panic, 結(jié)果仍是 nil slice

更準(zhǔn)確地說，對(duì) nil 切片取 len 或 cap 是安全的，返回 0。訪問元素 s[i] 會(huì)因?yàn)?nbsp;i 超出范圍 [0, len(s)-1] 而 panic。如果嘗試獲取子切片 s[x:y]，只要 x 和 y 都是 0，就不會(huì) panic，否則會(huì)因?yàn)樗饕浇缍?nbsp;panic。

對(duì) nil 接口值進(jìn)行類型斷言：

var i interface{} // i is nil
// _, ok := i.(int) // 不會(huì) panic, ok 會(huì)是 false
// _ = i.(int)      // 會(huì) panic: interface conversion: interface {} is nil, not int

通過 nil 指針調(diào)用方法（如果方法接收者不是指針類型，或者方法內(nèi)部訪問了接收者的字段）：

type MyStruct struct { field int }
func (m *MyStruct) PtrMethod() { 
  // fmt.Println(m.field) // 如果取消注釋這行，調(diào)用 nil 接收者的 PtrMethod 會(huì) panic
} 
func (m MyStruct) ValMethod() {} // 值接收者

func main() {
  var ms *MyStruct // ms is nil
  ms.PtrMethod() // Go 1.2 及之后，即使方法體為空，也可能因運(yùn)行時(shí)檢查而 panic（具體行為可能演變，但訪問字段一定會(huì) panic）
  // ms.ValMethod() // 編譯錯(cuò)誤：cannot call pointer method ValMethod on *MyStruct
                 // 注意：不能直接在 nil 指針上調(diào)用值接收者方法
                 // 如果是 var i MyInterface = ms; i.ValMethod() 這樣通過接口調(diào)用，則會(huì) panic
}

Go 1.2 的編譯器和運(yùn)行時(shí)會(huì)確保這些非法操作能夠穩(wěn)定地觸發(fā)運(yùn)行時(shí) panic，從而讓錯(cuò)誤更早、更明確地暴露出來。依賴舊版本未定義行為的代碼需要修改以確保指針在使用前是非 nil 的。

調(diào)度器支持搶占

在 Go 1.1 及更早版本中，Go 的調(diào)度器采用協(xié)作式調(diào)度。這意味著一個(gè) goroutine 只有在執(zhí)行到某些特定的點(diǎn)（如系統(tǒng)調(diào)用、通道操作、顯式調(diào)用 runtime.Gosched() 等）時(shí)，才會(huì)主動(dòng)讓出 CPU，讓調(diào)度器有機(jī)會(huì)運(yùn)行其他 goroutine。如果一個(gè) goroutine 陷入了一個(gè)沒有這些讓出點(diǎn)的緊密循環(huán)（例如，純粹的計(jì)算密集型循環(huán)），它就會(huì)長時(shí)間霸占當(dāng)前的工作線程（P），導(dǎo)致綁定到同一個(gè) P 上的其他 goroutine 得不到執(zhí)行機(jī)會(huì)，即發(fā)生餓死現(xiàn)象。這在 GOMAXPROCS 設(shè)置為 1 時(shí)尤為嚴(yán)重，因?yàn)檎麄€(gè)程序只有一個(gè)用戶級(jí)線程在運(yùn)行。

package main

import (
 "fmt"
 "runtime"
 "time"
)

func busyLoop() {
 for {
  // 純計(jì)算，沒有函數(shù)調(diào)用、系統(tǒng)調(diào)用或通道操作
 }
}

// 一個(gè)簡單的非內(nèi)聯(lián)函數(shù)
//go:noinline
func someWork() {
 // 做一些微不足道的事情，關(guān)鍵是它是一個(gè)函數(shù)調(diào)用
}

func busyLoopWithFuncCall() {
 for {
  someWork() // 每次循環(huán)都調(diào)用一個(gè)函數(shù)
 }
}

func main() {
 runtime.GOMAXPROCS(1) // 限制只有一個(gè)操作系統(tǒng)線程執(zhí)行 Go 代碼

 go func() {
  fmt.Println("另一個(gè) Goroutine 開始")
  time.Sleep(1 * time.Second) // 等待一秒
  fmt.Println("另一個(gè) Goroutine 結(jié)束")
 }()

 fmt.Println("啟動(dòng)繁忙循環(huán) Goroutine")
 // 在 Go 1.1 中，如果運(yùn)行 busyLoop()，"另一個(gè) Goroutine 結(jié)束" 可能永遠(yuǎn)不會(huì)打印
 // go busyLoop() 

 // 在 Go 1.2 中，運(yùn)行 busyLoopWithFuncCall()，另一個(gè) Goroutine 可以被調(diào)度執(zhí)行
 go busyLoopWithFuncCall() 

 // 給另一個(gè) goroutine 足夠的時(shí)間運(yùn)行和打印
 time.Sleep(2 * time.Second) 
 fmt.Println("主 Goroutine 結(jié)束")
}

Go 1.2 對(duì)此問題進(jìn)行了部分解決，引入了基于函數(shù)調(diào)用的搶占機(jī)制。具體來說，當(dāng)一個(gè) goroutine 即將進(jìn)入一個(gè)函數(shù)（更準(zhǔn)確地說，是函數(shù)的入口處）時(shí)，運(yùn)行時(shí)會(huì)檢查該 goroutine 是否已經(jīng)運(yùn)行了足夠長的時(shí)間（例如，超過一個(gè)時(shí)間片，通常是 10ms）。如果運(yùn)行時(shí)間過長，運(yùn)行時(shí)就會(huì)暫停該 goroutine，并將其放回全局運(yùn)行隊(duì)列，讓調(diào)度器有機(jī)會(huì)選擇并運(yùn)行其他 goroutine。

這意味著，只要一個(gè)循環(huán)中包含（非內(nèi)聯(lián)的）函數(shù)調(diào)用，即使這個(gè)函數(shù)本身很簡單，循環(huán)所在的 goroutine 也有機(jī)會(huì)被搶占。如上面的 busyLoopWithFuncCall 例子所示，因?yàn)檠h(huán)體內(nèi)有 someWork() 函數(shù)調(diào)用，即使 GOMAXPROCS=1，另一個(gè) goroutine 也能獲得執(zhí)行機(jī)會(huì)。

什么是內(nèi)聯(lián)函數(shù) (inlined function)？

內(nèi)聯(lián)是一種編譯器優(yōu)化技術(shù)，它將函數(shù)調(diào)用的地方直接替換為被調(diào)用函數(shù)的實(shí)際代碼體。這樣做的好處是可以消除函數(shù)調(diào)用的開銷（如參數(shù)傳遞、棧幀建立和銷毀、跳轉(zhuǎn)等），從而提高程序的執(zhí)行速度。

什么函數(shù)會(huì)被判定為內(nèi)聯(lián)？

Go 編譯器會(huì)根據(jù)一系列啟發(fā)式規(guī)則自動(dòng)決定是否對(duì)一個(gè)函數(shù)進(jìn)行內(nèi)聯(lián)。這些規(guī)則通?？紤]：

• 函數(shù)體的大小/復(fù)雜度： 太大或太復(fù)雜的函數(shù)通常不會(huì)被內(nèi)聯(lián)，因?yàn)閮?nèi)聯(lián)它們可能會(huì)導(dǎo)致代碼體積顯著增大，反而降低緩存效率。
• 函數(shù)是否包含特殊語句： 包含 defer、recover、select、閉包調(diào)用等的函數(shù)通常不會(huì)被內(nèi)聯(lián)。
• 遞歸函數(shù)： 遞歸函數(shù)通常不會(huì)被內(nèi)聯(lián)（或者只有有限層級(jí)的內(nèi)聯(lián)）。
• 調(diào)用者和被調(diào)用者的關(guān)系： 例如，對(duì)接口方法的調(diào)用通常不能內(nèi)聯(lián)，因?yàn)樵诰幾g時(shí)不知道具體會(huì)調(diào)用哪個(gè)實(shí)現(xiàn)。

開發(fā)者可以通過 go build -gcflags="-m" 命令查看編譯器的內(nèi)聯(lián)決策。也可以使用 //go:noinline 編譯指令強(qiáng)制阻止一個(gè)函數(shù)被內(nèi)聯(lián)，這在調(diào)試或需要確保函數(shù)調(diào)用作為搶占點(diǎn)時(shí)很有用。

需要注意的是，Go 1.2 的搶占機(jī)制是基于 非內(nèi)聯(lián) 函數(shù)調(diào)用的。如果 busyLoopWithFuncCall 中的 someWork 函數(shù)被編譯器內(nèi)聯(lián)了，那么這個(gè)循環(huán)的行為就可能變回和 busyLoop 類似，仍然可能導(dǎo)致其他 goroutine 餓死。因此，這個(gè)搶占機(jī)制只是部分解決了問題，后續(xù) Go 版本（如 Go 1.14）引入了更完善的異步搶占機(jī)制，不再強(qiáng)依賴函數(shù)調(diào)用。

線程與棧大小限制 (Thread and Stack Size Limits)

Go 1.2 在運(yùn)行時(shí)層面引入了對(duì)操作系統(tǒng)線程 (OS threads) 數(shù)量和 goroutine 棧 (stack) 大小的管理和限制，旨在提高程序的健壯性、資源利用的可預(yù)測性以及防止因資源耗盡導(dǎo)致的崩潰。

1. 操作系統(tǒng)線程數(shù)限制

• 背景： 在 Go 1.2 之前，雖然 Go 的 M:N 調(diào)度模型旨在用少量線程運(yùn)行大量 goroutine，但當(dāng)大量 goroutine 同時(shí)阻塞在系統(tǒng)調(diào)用（如文件 I/O、網(wǎng)絡(luò) I/O、cgo 調(diào)用）時(shí)，運(yùn)行時(shí)會(huì)創(chuàng)建新的操作系統(tǒng)線程來服務(wù)這些阻塞的 goroutine 以及運(yùn)行其他未阻塞的 goroutine。如果并發(fā)阻塞的 goroutine 數(shù)量非常大，可能會(huì)導(dǎo)致創(chuàng)建過多的操作系統(tǒng)線程，耗盡系統(tǒng)資源（如內(nèi)存、進(jìn)程可創(chuàng)建的線程數(shù)限制），最終導(dǎo)致程序甚至系統(tǒng)不穩(wěn)定。
• Go 1.2 變化： 引入了一個(gè)可配置的程序級(jí)別線程數(shù)上限，默認(rèn)值為 10,000。當(dāng)程序試圖創(chuàng)建超過此限制的線程時(shí)（通常是運(yùn)行時(shí)為了服務(wù)新的阻塞 goroutine 而需要?jiǎng)?chuàng)建線程時(shí)），程序會(huì) panic。這個(gè)限制可以通過 runtime/debug.SetMaxThreads 函數(shù)進(jìn)行調(diào)整。
• 代碼對(duì)比 (Go 1.1 vs Go 1.2):

package main

import (
    "fmt"
    "runtime"
    "runtime/debug" // 需要導(dǎo)入以使用 SetMaxThreads
    "sync"
    "time"
)

// 一個(gè)永遠(yuǎn)阻塞的 goroutine，模擬長時(shí)間系統(tǒng)調(diào)用
func blockingGoroutine(wg *sync.WaitGroup) {
    defer wg.Done()
    select {} // 永久阻塞
}

func main() {
    // 在 Go 1.2 或更高版本中，可以取消注釋來調(diào)整線程限制
    // ok := debug.SetMaxThreads(15000)
    // if !ok {
    //  fmt.Println("Failed to set max threads")
    // }

    numGoroutines := 11000 // 設(shè)置一個(gè)大于默認(rèn)限制 10000 的數(shù)量
    var wg sync.WaitGroup

    fmt.Printf("Attempting to start %d blocking goroutines...\n", numGoroutines)

    startTime := time.Now()
    createdCount := 0
    for i := 0; i < numGoroutines; i++ {
        wg.Add(1)
        go blockingGoroutine(&wg)
        createdCount++
        // 在 Go 1.2 中，當(dāng)運(yùn)行時(shí)需要?jiǎng)?chuàng)建第 10001 個(gè)線程時(shí)，很可能會(huì) panic
        // 為了更容易觀察到效果，可以稍微減慢 goroutine 創(chuàng)建速度
        if i%500 == 0 && i > 0 {
            fmt.Printf("Started %d goroutines\n", i)
            time.Sleep(10 * time.Millisecond) 
        }
    }
    // 執(zhí)行到這里所需的時(shí)間和是否能到達(dá)這里，在兩個(gè)版本下可能不同
    fmt.Printf("Finished requesting %d goroutines after %v\n", createdCount, time.Since(startTime))

    // 模擬程序繼續(xù)運(yùn)行
    time.Sleep(5 * time.Second) 
    fmt.Println("Program finished (or survived).")
}

a.在 Go 1.1 下運(yùn)行： 程序會(huì)嘗試創(chuàng)建 numGoroutines 個(gè) goroutine。由于它們都阻塞了，運(yùn)行時(shí)會(huì)不斷創(chuàng)建新的操作系統(tǒng)線程來嘗試服務(wù)它們。如果操作系統(tǒng)資源允許，它可能會(huì)成功創(chuàng)建超過 10,000 個(gè)線程，消耗大量系統(tǒng)資源，或者在達(dá)到某個(gè)操作系統(tǒng)的硬限制時(shí)失敗或崩潰。程序本身不會(huì)因?yàn)榫€程數(shù)過多而主動(dòng) panic。

b.在 Go 1.2 下運(yùn)行 (默認(rèn)設(shè)置)： 當(dāng)運(yùn)行時(shí)需要?jiǎng)?chuàng)建大約第 10,001 個(gè)線程時(shí)（這個(gè)數(shù)字不是絕對(duì)精確的，因?yàn)檫\(yùn)行時(shí)還有一些內(nèi)部線程），程序會(huì)檢測到超出了默認(rèn)的 10,000 線程限制，并觸發(fā)一個(gè) panic，通常帶有類似 "thread limit exceeded" 的信息。這阻止了程序無限制地消耗線程資源。如果調(diào)用 debug.SetMaxThreads(15000) 提高了限制，則程序可以創(chuàng)建更多線程，直到達(dá)到新的限制或操作系統(tǒng)限制。

2. Goroutine 棧大小調(diào)整

• 背景：

a.最小棧大?。?/span> Go 1.1 中 goroutine 的初始棧大小為 4KB。對(duì)于許多實(shí)際應(yīng)用來說，這個(gè)大小偏小，導(dǎo)致 goroutine 在執(zhí)行過程中需要頻繁地進(jìn)行棧增長（分配新的、更大的棧段并復(fù)制舊棧內(nèi)容），這是一個(gè)相對(duì)昂貴的操作，尤其在性能敏感的代碼中會(huì)造成可觀的開銷。

b.最大棧限制： Go 1.1 沒有對(duì)單個(gè) goroutine 的棧大小設(shè)置上限。如果一個(gè) goroutine 因?yàn)闊o限遞歸或深度嵌套調(diào)用而需要巨大的棧空間，它會(huì)持續(xù)增長，直到耗盡所有可用內(nèi)存，導(dǎo)致整個(gè)程序甚至系統(tǒng)崩潰（OOM Killer）。

• Go 1.2 變化：
• 將 goroutine 的最小棧大小從 4KB 提升到了 8KB。這是基于實(shí)際性能測試得出的經(jīng)驗(yàn)值，旨在減少棧增長的頻率，提高性能。
• 引入了 runtime/debug.SetMaxStack 函數(shù)，用于設(shè)置單個(gè) goroutine 的最大棧大小限制。默認(rèn)值在 64 位系統(tǒng)上為 1GB，32 位系統(tǒng)上為 250MB。當(dāng) goroutine 的棧試圖增長超過這個(gè)限制時(shí)，會(huì)觸發(fā)一個(gè)棧溢出 (stack overflow) 的 panic。
• 代碼對(duì)比 (Go 1.1 vs Go 1.2):

a.無限遞歸場景

package main

import (
    "fmt"
    "runtime/debug" // 需要導(dǎo)入以使用 SetMaxStack (Go 1.2+)
    "time"
)

// 無限遞歸函數(shù)，每次調(diào)用會(huì)消耗一些?？臻g
func infiniteRecursion(depth int) {
    var space [1024]byte // 模擬棧上分配一些空間
    _ = space            // 防止編譯器優(yōu)化掉
    if depth%1000 == 0 { // 每隔1000層打印一次深度
        fmt.Printf("Recursion depth: %d\n", depth)
    }
    infiniteRecursion(depth + 1)
}

func main() {
    // 在 Go 1.2 或更高版本中，可以取消注釋來設(shè)置一個(gè)更小的棧限制，以便更快看到效果
    // debug.SetMaxStack(2 * 1024 * 1024) // 設(shè)置為 2MB

    fmt.Println("Starting infinite recursion...")
    go infiniteRecursion(0)

    // 保持主 goroutine 運(yùn)行，以便觀察另一個(gè) goroutine 的行為
    time.Sleep(10 * time.Second) 
    fmt.Println("Main finished (likely the recursive goroutine crashed/panicked).")
}

b. 大量 Goroutine 內(nèi)存占用場景

package main

import (
    "fmt"
    "runtime"
    "sync"
    "time"
)

func idleWorker(wg *sync.WaitGroup) {
    defer wg.Done()
    time.Sleep(10 * time.Second) // 保持 goroutine 活躍但不做太多事
}

func main() {
    numGoroutines := 50000 // 創(chuàng)建大量 goroutine
    var wg sync.WaitGroup
    wg.Add(numGoroutines)

    fmt.Printf("Starting %d idle goroutines...\n", numGoroutines)
    startTime := time.Now()
    for i := 0; i < numGoroutines; i++ {
        go idleWorker(&wg)
    }
    fmt.Printf("Finished starting goroutines after %v\n", time.Since(startTime))

    // 嘗試獲取內(nèi)存統(tǒng)計(jì)信息
    runtime.GC() // 建議進(jìn)行 GC 以獲得更穩(wěn)定的內(nèi)存讀數(shù)
    var memStats runtime.MemStats
    runtime.ReadMemStats(&memStats)
    // Sys 是從 OS 獲取的總內(nèi)存，HeapAlloc 是堆上分配的內(nèi)存
    // Goroutine 棧不直接計(jì)入 HeapAlloc，但會(huì)計(jì)入 Sys
    fmt.Printf("Memory Sys: %d MiB, HeapAlloc: %d MiB\n", memStats.Sys / 1024 / 1024, memStats.HeapAlloc / 1024 / 1024)

    // 等待所有 goroutine 完成（在這個(gè)例子中意義不大，因?yàn)樗鼈冎皇?sleep）
    // wg.Wait() 
    fmt.Println("Program finished.")
}

• 在 Go 1.1 下運(yùn)行： 創(chuàng)建 numGoroutines 個(gè) goroutine，每個(gè)初始棧大小為 4KB。總的初始棧內(nèi)存占用約為 numGoroutines * 4KB。觀察 runtime.MemStats 中的 Sys 指標(biāo)（代表從操作系統(tǒng)獲取的總內(nèi)存），它會(huì)反映這部分棧內(nèi)存以及其他運(yùn)行時(shí)開銷。
• 在 Go 1.2 下運(yùn)行： 創(chuàng)建 numGoroutines 個(gè) goroutine，每個(gè)初始棧大小為 8KB?？偟某跏紬?nèi)存占用約為 numGoroutines * 8KB。與 Go 1.1 相比，對(duì)于同樣數(shù)量的 goroutine，程序的總內(nèi)存占用（Sys）會(huì)更高。雖然單個(gè) goroutine 的性能可能因減少棧增長而提高，但創(chuàng)建大量 goroutine 的程序的基線內(nèi)存消耗會(huì)增加。
• 在 Go 1.1 下運(yùn)行： infiniteRecursion 函數(shù)會(huì)不斷調(diào)用自身，棧持續(xù)增長。最終，程序會(huì)耗盡所有可用內(nèi)存，被操作系統(tǒng)殺死（OOM），或者因無法分配更多內(nèi)存而崩潰。錯(cuò)誤信息通常與內(nèi)存耗盡相關(guān)，而不是明確的棧溢出。
• 在 Go 1.2 下運(yùn)行： goroutine 的棧會(huì)增長，但當(dāng)它嘗試超過默認(rèn)的最大棧限制（1GB/250MB）或通過 SetMaxStack 設(shè)置的限制時(shí)，運(yùn)行時(shí)會(huì)檢測到這種情況，并立即觸發(fā)一個(gè) panic，錯(cuò)誤類型為 runtime: goroutine stack exceeds limit（通常顯示為 runtime error: stack overflow）。程序會(huì)因此終止，但不會(huì)耗盡系統(tǒng)內(nèi)存。

總結(jié)： Go 1.2 中對(duì)線程數(shù)和棧大小的限制與調(diào)整，體現(xiàn)了 Go 在運(yùn)行時(shí)層面對(duì)資源管理的加強(qiáng)。線程數(shù)限制提高了程序在面對(duì)大量阻塞操作時(shí)的穩(wěn)定性，防止耗盡系統(tǒng)資源；而棧大小的調(diào)整則旨在平衡性能（減少棧增長開銷）和內(nèi)存使用（增加最小棧，限制最大棧以防失控）。這些改動(dòng)使得 Go 程序在資源使用方面更加可預(yù)測和健壯。