会，但只在特定条件下。只要为某个对象注册了 runtime.SetFinalizer，GC 就不会立即回收该对象——它会先等 finalizer 执行完（或被取消），再进入下一轮回收；若 finalizer 内意外持有该对象引用（如闭包捕获、存入全局 map），则对象将永久无法回收。
runtime.SetFinalizer 会阻止对象被回收吗？
会，但只在特定条件下。只要为某个对象注册了 runtime.setfinalizer，gc 就不会立即回收该对象——它会先等 finalizer 执行完（或被取消），再进入下一轮回收。更关键的是：如果 finalizer 函数内部**意外持有了该对象的引用**（比如通过闭包捕获、赋值给全局变量、塞进 map/slice 等），对象就会变成“永远无法被回收”的状态。
finalizer 持有对象引用的典型错误写法
最常见陷阱是 finalizer 里把目标对象存到全局结构中，或者在闭包中隐式捕获。这类写法让 GC 认为对象仍被活跃引用，从而跳过回收。
错误示例：
var globalMap = make(map[*MyStruct]bool)
func setupFinalizer(obj *MyStruct) {
runtime.SetFinalizer(obj, func(o *MyStruct) {
// ❌ 错误：闭包捕获了 o，且写入全局 map
globalMap[o] = true
// 此时 o 的指针仍存在于 globalMap 中，GC 不敢回收 obj
})
}
正确做法是 finalizer 内只做清理（如关闭文件、释放 C 资源），不保留任何对该对象的强引用：
- 避免向全局变量、缓存、map、slice、channel 中写入该对象指针
- 避免在 finalizer 闭包中直接使用
obj或o变量（除非仅读取字段且不逃逸） - 若需记录日志或调试，用
fmt.Printf("%p", o)替代打印整个对象
finalizer 不保证执行时机和次数
runtime.SetFinalizer 注册的函数不保证一定会执行——程序退出时可能根本来不及触发；同一对象也最多执行一次 finalizer，且执行发生在任意 Goroutine 中，无顺序保障。
这意味着：
- 不能依赖 finalizer 做资源释放主逻辑（应优先用
defer+ 显式 Close） - finalizer 内不可调用阻塞操作（如网络请求、锁等待），否则可能卡住 GC 线程
- 不要在 finalizer 中修改对象字段或调用其方法（对象已处于“半销毁”状态）
- 注册 finalizer 的对象必须是堆上分配的指针类型；对局部变量或栈对象注册无效
如何验证 finalizer 是否导致内存泄漏？
用 runtime.ReadMemStats 和 pprof 是最直接的方式。重点观察 MemStats.HeapObjects 长期增长，且 pprof heap --inuse_space 中能看到大量未释放的自定义结构体实例。
调试建议：
- 在 finalizer 函数开头加
println("finalizer fired:", unsafe.Pointer(o))，确认是否真的被调用 - 用
go tool pprof -http=:8080 <binary> http://localhost:6060/debug/pprof/heap</binary>查看存活对象分布 - 检查所有注册点，确认没有把
*T存入任何长期存活的容器（包括 sync.Pool、lru.Cache、全局 map）
finalizer 是 GC 的“逃生舱”，不是资源管理的常规通道。一旦发现对象不回收，优先排查 finalizer 是否悄悄把它钉在了内存里。
