Why finalizer is never called?

Question

var p = &sync.Pool{
    New: func() interface{} {
        return &serveconn{}
    },
}

func newServeConn() *serveconn {
    sc := p.Get().(*serveconn)
    runtime.SetFinalizer(sc, (*serveconn).finalize)
    fmt.Println(sc, "SetFinalizer")
    return sc
}

func (sc *serveconn) finalize() {
    fmt.Println(sc, "finalize")
    *sc = serveconn{}
    runtime.SetFinalizer(sc, nil)
    p.Put(sc)
}

The above code tries to reuse object by SetFinalizer, but after debug I found finalizer is never called, why?

UPDATE

This may be related:https://github.com/golang/go/issues/2368

Answer 1

The above code tries to reuse object by SetFinalizer, but after debug I found finalizer is never called, why?

The finalizer is only called on an object when the GC marks it as unused and then tries to sweep (free) at the end of the GC cycle.

As a corollary, if a GC cycle is never performed during the runtime of your program, the finalizers you set may never be called.

Just in case you might hold a wrong assumption about the Go's GC, it may worth noting that Go does not employ reference counting on values; instead, it uses GC which works in parallel with the program, and the sessions during which it works happen periodically and are triggered by certain parameters like pressure on the heap produced by allocations.

A couple assorted notes regarding finalizers:

• When the program terminates, no GC is forcibly run.

  A corollary of this is that a finalizer is not guaranteed to run at all.

• If the GC finds a finalizer on an object about to be freed, it calls the finalizer but does not free the object.

  The object itself will be freed only at the next GC cycle — wasting the memory.

All in all, you appear as trying to implement destructors. Please don't: make your objects implement the sort-of standard method called Close and state in the contract of your type that the programmer is required to call it when they're done with the object. When a programmer wants to call such a method no matter what, they use defer.

Note that this approach works perfectly for all types in the Go stdlib which wrap resources provided by the OS—file and socket descriptors. So there is no need to pretend your types are somehow different.

Another useful thing to keep in mind is that Go was explicitly engineered to be no-nonsense, no-frills, no-magic, in-your-face language, and you're just trying to add magic to it. Please don't, those who like decyphering layers of magic do program in Scala different languages.