有沒有辦法合理地編寫測試用例來測試終結器行為？我正在嘗試在 Go 中實現一個內存敏感的規(guī)范化映射/緩存。由于沒有“軟引用”的概念（并且因為我的對象圖將始終形成一個 DAG），因此我使用一個跟蹤用戶空間中引用計數的微小界面/框架來完成此操作：type ReferenceCounted interface { RefCount() int IncRef() DecRef() (bool, error)}type Finalizable interface { ReferenceCounted Finalize()}type AbstractCounted struct { // unexported fields}它的工作方式是你有一個嵌入 AbstractCounted 的結構，并實現Finalizable.Finalize()- 這些一起使該結構接收Finalizable接口。然后有一個函數func MakeRef(obj Finalizable) *Reference返回一個指向結構的指針，該結構接收一個方法func Get() Finalizable，它獲取引用目標，并通過增加底層對象的引用計數來初始化它，然后設置一個終結器（via runtime.SetFinalizer()）來減少引用。 AbstractCounted的Finalizable實現反過來調用Finalize()結構，當引用計數達到零時嵌入它。所以，一切都被設置得非常像 Java 中的軟引用/引用隊列，除了它是引用計數，而不是根植于活動詞法范圍的標記/掃描，它可以“軟”地找到可訪問的東西?？雌饋硇Ч芎?！但是 - 我想寫一個測試用例......我完全理解終結器調用被推遲，并且不保證按照reflect包文檔運行它們。在其他具有運行時 gc 和終結器（C#、VB、Java、Python 等）的語言中，情況也是如此。但是，在所有其他語言中，請求顯式 GC（此處通過runtime.GC()函數）似乎確實會導致終結器運行。由于在 Go 中不是這種情況，我無法想出一種方法來編寫將觸發(fā)終結器的測試用例。是否有任何技巧或代碼片段（我認為這取決于當前的實現，即可能在未來中斷?。┛梢钥煽康赜|發(fā)這些終結器，以便我可以編寫我的測試？
1 回答
jeck貓
TA貢獻1909條經驗 獲得超7個贊
您無法顯式觸發(fā)終結器，因此您可以管理的最佳方法是確保 GC 以 啟動runtime.GC()，并等待終結器運行。
如果您查看runtime/mfinal_test.go，有一些測試通過通道等待終結器調用：
runtime.SetFinalizer(y, func(z *objtype) { fin <- true })
runtime.GC()
select {
case <-fin:
case <-time.After(4 * time.Second):
t.Errorf("finalizer of next string in memory didn't run")
}
- 1 回答
- 0 關注
- 182 瀏覽
添加回答
舉報
0/150
提交
取消