runtime.setfinalizer 的 finalizer 不保证执行、不立即执行、不与对象生命周期强绑定，仅在gc发现对象不可达后异步调用，且受goroutine调度影响；传参类型必须严格匹配指针所指类型，否则panic；并发访问需自行同步；显式资源管理（如defer close）更可靠。
runtime.SetFinalizer 什么时候会被调用？
它不会在对象失去引用后立刻执行，也不保证一定执行——这是最常被误解的一点。Go 的垃圾回收器只在 GC 周期中扫描到对象不可达、且该对象注册了 finalizer 时，才把 finalizer 推入一个内部队列；真正执行要等另一个 goroutine 异步处理，且这个 goroutine 可能长期阻塞或延迟。
- finalizer 函数运行在独立 goroutine 中，不与你的主逻辑同步
- 如果 finalizer 执行时间过长（比如做了网络请求或锁等待），会拖慢整个 finalizer 队列，影响后续对象的回收节奏
- 程序退出前不保证 finalizer 已运行，
os.Exit()会直接终止所有 goroutine，包括 finalizer 执行协程
<pre class="brush:php;toolbar:false;">type Resource struct{ fd int }
func (r *Resource) Close() { syscall.Close(r.fd) }
<p>r := &Resource{fd: 123}
runtime.SetFinalizer(r, func(obj <em>Resource) {
obj.Close() // 这里 obj 是 </em>Resource 类型，必须匹配传入的指针类型
})为什么传参类型必须和对象指针类型严格一致？
runtime.SetFinalizer 的第二个参数（函数）签名里，第一个参数的类型必须和第一个参数（对象）的<strong>动态类型完全一致</strong>，否则 panic：<code>panic: runtime.SetFinalizer: pointer not in heap 或更隐蔽的 invalid memory address or nil pointer dereference。
- 如果你传的是
&r（<em>Resource</em>），finalizer 函数签名就必须是func(Resource)，不能是func(Resource)或func(interface{}) - 如果对象是接口类型变量（比如
var x interface{} = &Resource{}），不能直接对x调用SetFinalizer，因为接口值本身是栈上变量，底层指针可能不在堆上 - 切片、map、channel 等引用类型本身不是 GC 管理的“对象”，它们的底层数组/结构体才是，但你无法对这些底层结构注册 finalizer
并发环境下 finalizer 和对象生命周期怎么错位？
finalizer 不是析构函数，它和对象的“存活”没有强绑定关系。GC 可能在 finalizer 还没跑完时就复用内存，或者 finalizer 拿到的对象字段早已被其他 goroutine 修改甚至置为 nil。
- finalizer 函数内访问对象字段前，应自行加锁或确保该对象在此期间不会被并发修改
- 不要在 finalizer 里再调用
runtime.SetFinalizer试图“续命”，这不会阻止当前对象被回收，反而可能泄漏 finalizer 函数闭包捕获的变量 - 如果对象持有一个
sync.Pool返回的指针，别指望 finalizer 能安全归还——Pool 对象可能已被 GC 回收，而 finalizer 还在排队
替代方案比 SetFinalizer 更可靠
绝大多数场景下，你应该用显式资源管理：比如 defer r.Close()、实现 io.Closer、配合 context.WithCancel 控制生命周期。finalizer 只适合极少数兜底用途，例如：
立即学习“go语言免费学习笔记（深入）”；
- C 代码分配的内存（
C.malloc）需要确保释放，且无法靠业务逻辑 100% 覆盖路径 - 日志或监控埋点，允许“尽力而为”地记录对象销毁事件
- 测试中验证对象是否被正确释放（配合
runtime.GC()和runtime.ReadMemStats()）
finalizer 的最大陷阱在于：它让你误以为自己写了“自动清理”，其实只是挂了个不一定触发、不一定及时、不一定安全的钩子。真要控制对象生命周期，得靠代码结构，而不是依赖 GC 的偶然调度。
