Go 弱引用和清理機制優化：從 runtime.AddCleanup 到 weak.Pointer
今天給大家分享的兩個在垃圾回收（GC）方面挺有意思的新特性：runtime.AddCleanup清理函數和weak.Pointer弱指針。
這兩個功能不僅解決了傳統 finalizer 的痛點，還為內存管理和性能優化提供了全新的解決方案。一起來學習吧！
背景
在 Go 語言的發展歷程中，內存管理一直是個重要話題。我們有垃圾回收器幫助自動回收內存，但在某些場景下，比如需要管理系統資源（文件描述符、內存映射等）時，就需要更精細的控制。
之前主要依賴runtime.SetFinalizer來實現資源清理，但說實話，finalizer 使用起來真的很容易踩坑。
最大的問題就是對象復活（object resurrection）：finalizer 會讓原本應該被回收的對象"復活"，至少需要兩次 GC 周期才能真正回收內存，還容易造成循環引用問題。
runtime.AddCleanup：更好的資源清理方案
Go 團隊也意識到了這些問題。
隨著 Go 語言的不斷演進，推出了更優雅的解決方案：runtime.AddCleanup和weak.Pointer。
核心改進
runtime.AddCleanup的最大改進在于：清理函數不會接收原始對象作為參數。
這個設計直接解決了 finalizer 的兩大痛點：
- 避免對象復活問題。
- 支持循環引用的對象清理。
看個實際例子，用內存映射文件來演示：
//go:build unix
package main
import (
"os"
"runtime"
"syscall"
)
type MemoryMappedFile struct {
data []byte
}
func NewMemoryMappedFile(filename string) (*MemoryMappedFile, error) {
f, err := os.Open(filename)
if err != nil {
returnnil, err
}
defer f.Close()
// 獲取文件信息，主要是文件大小
fi, err := f.Stat()
if err != nil {
returnnil, err
}
// 提取文件描述符
conn, err := f.SyscallConn()
if err != nil {
returnnil, err
}
var data []byte
connErr := conn.Control(func(fd uintptr) {
// 創建內存映射
data, err = syscall.Mmap(int(fd), 0, int(fi.Size()),
syscall.PROT_READ, syscall.MAP_SHARED)
})
if connErr != nil {
returnnil, connErr
}
if err != nil {
returnnil, err
}
mf := &MemoryMappedFile{data: data}
// 關鍵來了：設置清理函數
cleanup := func(data []byte) {
syscall.Munmap(data) // 忽略錯誤
}
runtime.AddCleanup(mf, cleanup, data)
return mf, nil
}看到區別了嗎？runtime.AddCleanup接受三個參數：
- 要監控的對象：mf。
- 清理函數：cleanup。
- 清理參數：data。
當mf不再可達時，清理函數會被調用，但接收的參數是data，而不是mf本身。
這樣設計的好處是顯而易見的：
- mf對象可以立即被回收，不需要等待清理函數執行。
- 即使mf存在循環引用，也不會阻止清理函數的執行。
- 內存回收效率大大提高。
weak.Pointer：安全的弱引用
弱指針是另一個很重要的特性。
weak.Pointer允許我們引用一個對象，但不會阻止垃圾回收器回收它。
實際應用場景
繼續用內存映射文件的例子，假設我們的程序經常需要映射相同的文件，為了避免重復的系統調用開銷，我們想要建立一個緩存。
但如果用普通的 map 來緩存，就會面臨一個問題：什么時候刪除緩存 k/v？
弱指針完美解決了這個問題：
package main
import (
"runtime"
"sync"
"weak"
)
var cache sync.Map // map[string]weak.Pointer[MemoryMappedFile]
func NewCachedMemoryMappedFile(filename string) (*MemoryMappedFile, error) {
var newFile *MemoryMappedFile
for {
// 嘗試從緩存加載現有值
value, ok := cache.Load(filename)
if !ok {
// 沒找到緩存，需要時創建新的映射文件
if newFile == nil {
var err error
newFile, err = NewMemoryMappedFile(filename)
if err != nil {
returnnil, err
}
}
// 嘗試安裝新的映射文件
wp := weak.Make(newFile)
var loaded bool
value, loaded = cache.LoadOrStore(filename, wp)
if !loaded {
// 成功安裝，設置清理函數來刪除緩存條目
runtime.AddCleanup(newFile, func(filename string, wp weak.Pointer[MemoryMappedFile]) {
// 只有當弱指針相等時才刪除，防止誤刪
cache.CompareAndDelete(filename, wp)
}, filename, wp)
return newFile, nil
}
// 有人搶先安裝了文件，繼續循環檢查
}
// 檢查緩存條目是否有效
if mf := value.(weak.Pointer[MemoryMappedFile]).Value(); mf != nil {
return mf, nil
}
// 發現了等待清理的空條目，主動刪除
cache.CompareAndDelete(filename, value)
}
}這個實現很巧妙：
- 弱指針緩存：緩存中存儲的是弱指針，不會阻止對象被回收
- 自動清理：當對象不再可達時，清理函數會自動刪除緩存條目
- 并發安全：使用sync.Map和CompareAndDelete確保并發安全
弱指針的關鍵特性
通過這個例子，我們可以看到弱指針的幾個重要特性：
- 可比較性：弱指針是可比較的，即使指向的對象已經被回收
- 穩定身份：每個弱指針都有獨立的身份標識
- 安全訪問：通過Value()方法安全訪問，返回 nil 表示對象已被回收
通用緩存實現
基于這些特性，我們甚至可以實現一個通用的弱引用緩存：
type Cache[K comparable, V any] struct {
create func(K) (*V, error)
m sync.Map
}
func NewCache[K comparable, V any](create func(K) (*V, error)) *Cache[K, V] {
return &Cache[K, V]{create: create}
}
func (c *Cache[K, V]) Get(key K) (*V, error) {
var newValue *V
for {
value, ok := c.m.Load(key)
if !ok {
if newValue == nil {
var err error
newValue, err = c.create(key)
if err != nil {
returnnil, err
}
}
wp := weak.Make(newValue)
var loaded bool
value, loaded = c.m.LoadOrStore(key, wp)
if !loaded {
runtime.AddCleanup(newValue, func(key K, wp weak.Pointer[V]) {
c.m.CompareAndDelete(key, wp)
}, key, wp)
return newValue, nil
}
}
if v := value.(weak.Pointer[V]).Value(); v != nil {
return v, nil
}
c.m.CompareAndDelete(key, value)
}
}簡單來說，這就是一個可以自動清理過期條目的緩存，非常適合那些創建成本較高但生命周期不確定的對象。
小心 “坑”
雖然這兩個新特性很強大，但使用時還是要注意以下講到的幾個坑。
1. 避免循環引用
清理函數不能捕獲要監控的對象，否則清理函數永遠不會執行：
// 錯誤示例：清理函數捕獲了mf
runtime.AddCleanup(mf, func() {
// 這里引用了mf，會導致清理函數永遠不執行
fmt.Printf("清理 %p\n", mf)
}, nil)
// 正確示例：通過參數傳遞需要的信息
runtime.AddCleanup(mf, func(addr uintptr) {
fmt.Printf("清理 %p\n", unsafe.Pointer(addr))
}, uintptr(unsafe.Pointer(mf)))2. 弱指針作為 map 鍵的陷阱
當弱指針作為 map 鍵時，被引用的對象不能從對應的值可達，否則對象永遠不會被回收：
// 有問題的設計
type Node struct {
name string
}
var registry = make(map[weak.Pointer[Node]]*Node)
// 這樣會導致Node永遠不被回收
func badRegister(n *Node) {
wp := weak.Make(n)
registry[wp] = n // 值直接引用了對象
}3. 非確定性行為
清理函數和弱指針的行為是非確定性的，依賴于垃圾回收器的運行時機。
測試這類代碼時需要特別小心，可能需要主動觸發 GC：
func TestCleanup(t *testing.T) {
// 創建對象并設置清理
var cleaned bool
obj := &MyObject{}
runtime.AddCleanup(obj, func() {
cleaned = true
})
// 移除強引用
obj = nil
// 強制觸發GC
runtime.GC()
runtime.GC() // 可能需要多次
if !cleaned {
t.Error("清理函數未執行")
}
}總結
這兩個新特性真的很實用，核心原因在于：
- runtime.AddCleanup：比傳統 finalizer 更高效，避免了對象復活問題
- weak.Pointer 提供了安全的弱引用機制，非常適合構建緩存和避免內存泄漏
- 組合使用：可以構建出強大的內存管理模式，比如自清理緩存
雖然這些是高級特性，使用時需要格外小心，但對于那些對性能有極致要求的場景，它們提供了前所未有的靈活性。
