dongtan8122 2015-06-23 19:26
浏览 38
已采纳

Go中的终结器测试

TLDR: Is there any way to reasonably write test cases to test finalizer behaviors?

I'm trying to implement a memory-sensitive canonicalizing map / cache in Go. Since there is no notion of "soft reference" (and because my object graph will always form a DAG), I'm accomplishing this with a tiny interface/framework that tracks counts of references in the userland:

type ReferenceCounted interface {
   RefCount() int
   IncRef()
   DecRef() (bool, error)
}

type Finalizable interface {
   ReferenceCounted
   Finalize()
}

type AbstractCounted struct {
     // unexported fields
}

The way this works is that you have a struct which embeds AbstractCounted, and implement Finalizable.Finalize() - these together make that struct receive the Finalizable interface. Then there is a function func MakeRef(obj Finalizable) *Reference which returns a pointer to a struct which receives a method func Get() Finalizable, which gets the reference target, and which is initialized by incrementing the ref count on the unerlying object, then setting a finalizer (via runtime.SetFinalizer()) which will decrement the reference. AbstractCounted's Finalizable implementation in turn calls Finalize() on the struct which embeds it when the ref count reaches zero.

So, everything is set up to work very much like soft references / ref queues in Java would now, with the exception that it's reference counting and not a mark/sweep rooted in active lexical scopes that is finding things "softly" reachable.

It seems to work great! But - I would like to write a test case...

I understand fully that finalizer invocation is deferred, and that no guarantees are made about running them per the reflect package docs. The situation is the same in other languages with runtime gc and finalizers (C#, VB, Java, Python, etc) as well.

However, in all of those other languages, requesting explicit GC (here through the runtime.GC() function) does seem to cause finalizers to get run. Since that's not the case in Go, I cannot figure out a way to write a test case that will trigger the finalizers.

Is there any trick or code fragment (I'm OK with this being current-implementation dependent, ie. could-break-in-future!) that will reliably trigger those finalizers so I can write my test?

  • 写回答

1条回答 默认 最新

  • duanhegn231318 2015-06-23 20:23
    关注

    You can't explicitly trigger a Finalizer, so the best you can manage is to make sure the GC is started with runtime.GC(), and wait for the finalizer to run.

    If you look at runtime/mfinal_test.go, there are some tests that wait for finalizer calls via a channel:

    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")
    }
    
    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论

报告相同问题?

悬赏问题

  • ¥15 无线电能传输系统MATLAB仿真问题
  • ¥50 如何用脚本实现输入法的热键设置
  • ¥20 我想使用一些网络协议或者部分协议也行,主要想实现类似于traceroute的一定步长内的路由拓扑功能
  • ¥30 深度学习,前后端连接
  • ¥15 孟德尔随机化结果不一致
  • ¥15 apm2.8飞控罗盘bad health,加速度计校准失败
  • ¥15 求解O-S方程的特征值问题给出边界层布拉休斯平行流的中性曲线
  • ¥15 谁有desed数据集呀
  • ¥20 手写数字识别运行c仿真时,程序报错错误代码sim211-100
  • ¥15 关于#hadoop#的问题