Go 1.2 值得關注的改動：

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

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

對 nil 指針解引用會 panic

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

package main

type T struct {
    X [1 << 24]byte // 一個非常大的數組，導致 Field 偏移量很大
    Field int32
}

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

這種行為是危險的，因為它可能導致難以察覺的數據損壞或安全漏洞。為了提高內存安全，Go 1.2 明確規定，任何顯式或隱式地需要對 nil 地址進行求值的表達式都是一個錯誤。這包括：

通過 nil 指針訪問字段或數組元素：

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

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

對 nil 切片進行索引或切片操作（讀取長度除外）：

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

更準確地說，對 nil 切片取 len 或 cap 是安全的，返回 0。訪問元素 s[i] 會因為 i 超出范圍 [0, len(s)-1] 而 panic。如果嘗試獲取子切片 s[x:y]，只要 x 和 y 都是 0，就不會 panic，否則會因為索引越界而 panic。

對 nil 接口值進行類型斷言：

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

通過 nil 指針調用方法（如果方法接收者不是指針類型，或者方法內部訪問了接收者的字段）：

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

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

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

調度器支持搶占

在 Go 1.1 及更早版本中，Go 的調度器采用協作式調度。這意味著一個 goroutine 只有在執行到某些特定的點（如系統調用、通道操作、顯式調用 runtime.Gosched() 等）時，才會主動讓出 CPU，讓調度器有機會運行其他 goroutine。如果一個 goroutine 陷入了一個沒有這些讓出點的緊密循環（例如，純粹的計算密集型循環），它就會長時間霸占當前的工作線程（P），導致綁定到同一個 P 上的其他 goroutine 得不到執行機會，即發生餓死現象。這在 GOMAXPROCS 設置為 1 時尤為嚴重，因為整個程序只有一個用戶級線程在運行。

package main

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

func busyLoop() {
 for {
  // 純計算，沒有函數調用、系統調用或通道操作
 }
}

// 一個簡單的非內聯函數
//go:noinline
func someWork() {
 // 做一些微不足道的事情，關鍵是它是一個函數調用
}

func busyLoopWithFuncCall() {
 for {
  someWork() // 每次循環都調用一個函數
 }
}

func main() {
 runtime.GOMAXPROCS(1) // 限制只有一個操作系統線程執行 Go 代碼

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

 fmt.Println("啟動繁忙循環 Goroutine")
 // 在 Go 1.1 中，如果運行 busyLoop()，"另一個 Goroutine 結束" 可能永遠不會打印
 // go busyLoop() 

 // 在 Go 1.2 中，運行 busyLoopWithFuncCall()，另一個 Goroutine 可以被調度執行
 go busyLoopWithFuncCall() 

 // 給另一個 goroutine 足夠的時間運行和打印
 time.Sleep(2 * time.Second) 
 fmt.Println("主 Goroutine 結束")
}

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

這意味著，只要一個循環中包含（非內聯的）函數調用，即使這個函數本身很簡單，循環所在的 goroutine 也有機會被搶占。如上面的 busyLoopWithFuncCall 例子所示，因為循環體內有 someWork() 函數調用，即使 GOMAXPROCS=1，另一個 goroutine 也能獲得執行機會。

什么是內聯函數 (inlined function)？

內聯是一種編譯器優化技術，它將函數調用的地方直接替換為被調用函數的實際代碼體。這樣做的好處是可以消除函數調用的開銷（如參數傳遞、棧幀建立和銷毀、跳轉等），從而提高程序的執行速度。

什么函數會被判定為內聯？

Go 編譯器會根據一系列啟發式規則自動決定是否對一個函數進行內聯。這些規則通常考慮：

• 函數體的大小/復雜度： 太大或太復雜的函數通常不會被內聯，因為內聯它們可能會導致代碼體積顯著增大，反而降低緩存效率。
• 函數是否包含特殊語句： 包含 defer、recover、select、閉包調用等的函數通常不會被內聯。
• 遞歸函數： 遞歸函數通常不會被內聯（或者只有有限層級的內聯）。
• 調用者和被調用者的關系： 例如，對接口方法的調用通常不能內聯，因為在編譯時不知道具體會調用哪個實現。

開發者可以通過 go build -gcflags="-m" 命令查看編譯器的內聯決策。也可以使用 //go:noinline 編譯指令強制阻止一個函數被內聯，這在調試或需要確保函數調用作為搶占點時很有用。

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

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

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

1. 操作系統線程數限制

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

package main

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

// 一個永遠阻塞的 goroutine，模擬長時間系統調用
func blockingGoroutine(wg *sync.WaitGroup) {
    defer wg.Done()
    select {} // 永久阻塞
}

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

    numGoroutines := 11000 // 設置一個大于默認限制 10000 的數量
    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 中，當運行時需要創建第 10001 個線程時，很可能會 panic
        // 為了更容易觀察到效果，可以稍微減慢 goroutine 創建速度
        if i%500 == 0 && i > 0 {
            fmt.Printf("Started %d goroutines\n", i)
            time.Sleep(10 * time.Millisecond) 
        }
    }
    // 執行到這里所需的時間和是否能到達這里，在兩個版本下可能不同
    fmt.Printf("Finished requesting %d goroutines after %v\n", createdCount, time.Since(startTime))

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

a.在 Go 1.1 下運行： 程序會嘗試創建 numGoroutines 個 goroutine。由于它們都阻塞了，運行時會不斷創建新的操作系統線程來嘗試服務它們。如果操作系統資源允許，它可能會成功創建超過 10,000 個線程，消耗大量系統資源，或者在達到某個操作系統的硬限制時失敗或崩潰。程序本身不會因為線程數過多而主動 panic。

b.在 Go 1.2 下運行 (默認設置)： 當運行時需要創建大約第 10,001 個線程時（這個數字不是絕對精確的，因為運行時還有一些內部線程），程序會檢測到超出了默認的 10,000 線程限制，并觸發一個 panic，通常帶有類似 "thread limit exceeded" 的信息。這阻止了程序無限制地消耗線程資源。如果調用 debug.SetMaxThreads(15000) 提高了限制，則程序可以創建更多線程，直到達到新的限制或操作系統限制。

2. Goroutine 棧大小調整

• 背景：

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

b.最大棧限制： Go 1.1 沒有對單個 goroutine 的棧大小設置上限。如果一個 goroutine 因為無限遞歸或深度嵌套調用而需要巨大的?？臻g，它會持續增長，直到耗盡所有可用內存，導致整個程序甚至系統崩潰（OOM Killer）。

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

a.無限遞歸場景

package main

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

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

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

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

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

b. 大量 Goroutine 內存占用場景

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 // 創建大量 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))

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

    // 等待所有 goroutine 完成（在這個例子中意義不大，因為它們只是 sleep）
    // wg.Wait() 
    fmt.Println("Program finished.")
}

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

總結： Go 1.2 中對線程數和棧大小的限制與調整，體現了 Go 在運行時層面對資源管理的加強。線程數限制提高了程序在面對大量阻塞操作時的穩定性，防止耗盡系統資源；而棧大小的調整則旨在平衡性能（減少棧增長開銷）和內存使用（增加最小棧，限制最大棧以防失控）。這些改動使得 Go 程序在資源使用方面更加可預測和健壯。