SystemVerilog 内存管理、对象生命周期与句柄陷阱
更新时间：2026-10-01。短用例看不出问题，一跑几万事务的长回归，内存悄悄涨到 OOM，多半是对象生命周期没管好。
本文要回答的问题
- 对象什么时候真正被释放，需要手动 delete 吗？
- 哪些写法会让仿真内存持续增长？
- 对象池怎么用“复用”替代“反复 new”？
- 静态与自动变量生命周期有何不同？
一、分配与可达性
new() 分配对象；当没有任何句柄再指向它，这块内存才可能被回收（SystemVerilog 不保证即时 GC，多数仿真器在过程结束或需要时回收）。因此“释放”的关键是让句柄消失：出作用域、置 null、从队列/关联数组里移除。
二、常见泄漏点
- 记分板只进不出：期望队列不断 push，事务处理完不 pop/delete，长回归线性涨内存。
- 关联数组当缓存不清理：
mem[addr]、历史记录无限累积。 - 波形/记录全开：
$recordfile、UVM transaction recording 保留所有对象引用。 - 静态容器持有对象：
static队列在整个仿真生命周期不释放。 - 循环引用：对象互相持有句柄，外部句柄虽清空仍不可回收（取决于工具）。
三、对象池：复用而非重建
频繁创建/回收同类对象有开销，用对象池预分配、用完归还：
systemverilog
class tr_pool;
transaction pool[$];
function transaction get();
if (pool.size()==0) return new();
get = pool.pop_back();
endfunction
function void put(transaction t); pool.push_back(t); endfunction
endclass高吞吐场景下显著减少分配抖动，也让内存占用平稳。
四、静态与自动生命周期
static变量/方法内变量：全仿真一份，跨调用保留值（注意并发共享）。automatic：每次进入作用域新建，退出即失效。类方法默认 automatic，module 的 task/function 默认 static（旧 Verilog 习惯），递归或多线程时要显式automatic。
五、生命周期与内存图
六、排查与卫生
- 给记分板设置“匹配即删除”，定期打印队列长度看是否只增不减。
- 长回归分段（每 N 个事务）记录内存，定位增长起点。
- 关闭不必要的 transaction recording 和全信号波形。
- 缓存设置上限或老化淘汰策略。
- 怀疑并发串值时，检查是否误用 static。
七、常见坑
- 记分板期望队列忘记清理，跑久了 OOM。
- 回调/订阅列表只 add 不 remove，回调对象被长期持有。
- module 下 task 默认 static，多线程调用互相覆盖局部变量。
- 对象池取回的对象带“上一次的脏字段”，复用前没 reset。
- 用
null赋局部句柄以为能释放，实则静态容器还持有它。
小结
总结
SystemVerilog 对象在 new() 时分配、当再无任何句柄可达时才可能被回收（不保证即时 GC），所以"释放"的本质是让句柄消失——出作用域、置 null、从容器移除；长回归内存线性上涨几乎都来自记分板期望队列只进不出、关联数组缓存不清理、波形/recording 与 static 容器长期持有引用及循环引用，对策是记分板"匹配即删"、给缓存设上限、用对象池复用对象（取出先 reset），并注意 module 下 task 默认 static 的串值陷阱。