Go中使用time.AfterFunc与runtime.SetFinalizer时如何避免内存泄漏？

在Go语言会话管理实现中，time.AfterFunc与runtime.SetFinalizer的组合使用可能引发内存泄漏问题。以下是拆解后的三个场景示例，其中示例1的行为尤为值得分析：

演示代码 #

package main

import (
    "fmt"
    "net/http"
    _ "net/http/pprof"
    "runtime"
    "sync"
    "time"
)

type SessionFactory struct {
    sessions map[string]*Session
}

var lock sync.Mutex

func (f *SessionFactory) DeleteSession(sessionID string) {
    lock.Lock()
    defer lock.Unlock()
    delete(f.sessions, sessionID)
    fmt.Println("Session deleted:", sessionID)
}

type Session struct {
    ID               string
    destructionTimer *time.Timer
}

// setDestructionTimerExample1 演示同时设置s.destructionTimer与runtime.SetFinalizer可能导致内存泄漏的场景
func setDestructionTimerExample1(s *Session, factory *SessionFactory, timeout time.Duration) {
    s.destructionTimer = time.AfterFunc(timeout, func() {
        factory.DeleteSession(s.ID)
    })
    runtime.SetFinalizer(s, func(s *Session) {
        fmt.Println("Session finalizer called for:", s.ID)
    })
}

// setDestructionTimerExample2 演示不会导致内存泄漏的场景，展示不直接将定时器赋值给Session结构体字段的替代方案
func setDestructionTimerExample2(s *Session, factory *SessionFactory, timeout time.Duration) {
    time.AfterFunc(timeout, func() {
        factory.DeleteSession(s.ID)
    })
    runtime.SetFinalizer(s, func(s *Session) {
        fmt.Println("Session finalizer called for:", s.ID)
    })
}

// setDestructionTimerExample3 演示通过不设置终结器来避免内存泄漏的场景，展示省略runtime.SetFinalizer调用的影响
func setDestructionTimerExample3(s *Session, factory *SessionFactory, timeout time.Duration) {
    s.destructionTimer = time.AfterFunc(timeout, func() {
        factory.DeleteSession(s.ID)
    })
    // 注意：本示例故意省略终结器以避免内存泄漏
}
func NewSession(factory *SessionFactory, id string, timeout time.Duration) *Session {
    lock.Lock()
    defer lock.Unlock()
    session := &Session{
        ID: id,
    }
    // 根据场景选择合适的示例函数使用
    setDestructionTimerExample1(session, factory, timeout)
    // setDestructionTimerExample2(session, factory, timeout)
    // setDestructionTimerExample3(session, factory, timeout)
    factory.sessions[id] = session // 在工厂中保留引用
    return session
}
func main() {
    factory := &SessionFactory{sessions: make(map[string]*Session)}
    var i = 0
    go func() {
        if err := http.ListenAndServe(":8080", nil); err != nil {
            fmt.Println("listen failed")
        }
    }()
    for {
        i += 1
        sessionID := fmt.Sprintf("session%d", i)
        NewSession(factory, sessionID, 300*time.Nanosecond)
        time.Sleep(300 * time.Nanosecond)
    }
}
// 运行与分析命令：
// go run main.go
// go tool pprof -http=:8081  http://localhost:8080/debug/pprof/heap

场景分析 #

示例1：内存泄漏的根源 #

当同时为Session设置destructionTimer字段和终结器时，会形成循环引用：

• Session结构体持有*time.Timer引用
• Timer内部持有回调函数的引用
• 回调函数引用了Session.ID，间接持有Session的引用

Go的垃圾回收器可以处理普通循环引用，但一旦对象关联了runtime.SetFinalizer，GC会将该对象标记为"需要执行终结器"，此时循环引用会让对象始终处于可达状态，终结器无法被触发，对象也永远不会被回收，最终导致内存泄漏。

示例2：无泄漏的替代方案 #

本示例不将Timer赋值给Session的字段，打破了循环引用：

• Timer是局部变量，仅回调函数持有Session的引用
• 当Timer触发回调、工厂删除Session后，Session不再有任何外部引用
• GC可以正确标记Session为不可达，执行终结器后回收对象，不会产生泄漏

示例3：省略终结器避免泄漏 #

这里虽然Session与Timer仍存在循环引用，但因为没有设置runtime.SetFinalizer，Go的GC可以正常处理这种循环引用：

• 当工厂删除Session后，循环引用内部的对象没有任何外部引用
• GC的三色标记算法可以识别这类无外部引用的循环结构，将其标记为可回收，因此不会产生内存泄漏

总结 #

• 避免在存在循环引用的对象上使用runtime.SetFinalizer，这会干扰GC对对象可达性的判定
• 若需同时使用定时器和终结器，不要让定时器成为会话对象的字段，打破循环引用链
• 仅使用定时器时，即使存在循环引用，Go GC也能正常回收对象，无需担心泄漏

内容的提问来源于stack exchange，提问作者ahdr