在CGO回调场景中，禁用GC能否保证Go指针操作的安全性？

我正在将C库集成到Go程序中，需要使用一个带回调接口的C函数，该函数会接收一个指针并在调用回调时将其作为参数传回。由于直接传递Go回调给C函数会出现类型不匹配（提示回调不符合*[0]byte类型），我通过C包装层实现调用，代码如下：

/*
extern bool goCallback(void*);

static bool callback(void* data)
{
    return goCallback(data);
}

static WrapCall(void* data)
{
    return callRelevantCFunction(callback, data);
}
*/
import "C"

func goCallback(p unsafe.Pointer) {
    data := (*MyObjectType)(p)
    //do things
}

func main() {
    obj := &MyObjectType{}
    C.WrapCall(unsafe.Pointer(obj))
}

我了解正常情况下，若obj包含其他Go指针，解引用这些指针并不安全——GC可能移动指向的对象，或在引用被丢弃时将其回收。但回调所需数据是带有大量嵌套Go对象的大型结构，为避免将数据迁移到C内存的大量重构工作，仅在C函数调用（可能触发回调）期间禁用GC是否足够？

仅在C函数调用期间禁用GC无法保证操作安全，核心原因和可行方案如下：

为什么禁用GC不够？ #

• GC无法感知C代码持有Go指针：Go的垃圾回收器只会扫描Go栈、堆中的引用，不会遍历C内存中的指针。即便你在调用C函数时禁用了GC，一旦重新启用GC，若obj的嵌套Go对象在Go侧无其他强引用，GC会判定这些对象可被回收，哪怕C回调仍可能访问它们。
• 移动型GC的潜在风险：Go采用移动型垃圾回收器，对象可能在GC执行时被移动内存地址。虽然禁用GC期间不会触发移动，但如果C函数调用完成后重新启用GC，后续若有GC操作，之前被C持有的指针可能指向已失效的内存区域。

可行的替代方案 #

1. 在Go侧保留强引用：
   在C函数调用周期内，将obj及其嵌套的所有Go对象存入全局的切片或映射中，让GC能识别到这些引用的存在。等所有回调执行完毕、C函数调用结束后，再从全局容器中移除这些引用，允许GC回收。这种方式无需禁用GC，是最安全的方案。

2. 使用runtime.KeepAlive：
   如果C函数是同步阻塞调用（即C.WrapCall会阻塞到所有回调执行完成），可在C函数调用结束后对obj执行runtime.KeepAlive(obj)。该函数会告知GC，obj在当前代码点之前仍被使用，避免GC在C函数执行期间回收obj本身。但需注意：KeepAlive仅能保证obj不被回收，若嵌套对象未被obj强引用，仍存在回收风险；若C函数是异步执行（比如启动后台线程触发回调），KeepAlive无效，因为主线程的KeepAlive会在C函数返回后立即生效，而后台线程可能仍在运行。

注意事项 #

禁用GC是极端操作，会导致内存无法及时回收，长期运行极易引发内存溢出，除非没有其他可行方案，否则绝不建议使用。

内容的提问来源于stack exchange，提问作者sprw121