Go cgo 怎样安排 C 字符串释放

安排 cgo 字符串释放，关键不是记住一句“用完就 free”，而是先确认谁拥有这块内存。C.CString 会把 Go 字符串复制到 C 堆，并返回一份以 NUL 结尾的副本；这份内存不归 Go 垃圾回收器管理。普通同步调用最稳妥的写法，是在分配后立刻登记 C.free；如果 C 代码要保存指针，则必须把释放动作推迟到 C 明确结束使用之后。

官方文档：https://pkg.go.dev/cmd/cgo

一、先画清 CString 的所有权边界

Go 原字符串和 C.CString 返回的指针是两份数据。前者仍由 Go 管理，后者在 C 堆上，Cgo 文档明确要求调用方安排释放。可以把这次转换记成一条边界：Go 负责提供输入，C 负责使用副本，创建副本的一方先拥有释放责任。

这里的“拥有”要落到具体接口上。若 C 函数只在当前调用中读取参数，就是借用；若 C 函数把指针存入全局结构或异步任务，就是保存。两种情况的释放时机完全不同。

二、同步调用用 defer 立即登记释放

对只在本次调用内读取字符串的 C API，分配后马上登记释放最不容易漏掉异常路径。stdlib.h 提供 free 的声明，Go 侧把 *C.char 转成 unsafe.Pointer 后交给它。

package bridge

// #include 
// static void consume_text(const char *s) { (void)s; } // 只在调用期间读取字符串。
import "C"
import "unsafe"

func sendText(s string) {
	cs := C.CString(s) // 在 C 堆创建副本，Go GC 不负责回收它。
	defer C.free(unsafe.Pointer(cs)) // 立刻登记，异常返回也不会漏释放。
	C.consume_text(cs) // 该函数只能借用指针，不能把它保存到异步任务。
}

defer 不是让内存马上释放，而是把释放绑定到当前 Go 函数返回。对于同步读取来说，这正好覆盖 C 函数的使用区间。若中间出现返回、错误处理或 panic，释放仍会执行。不要把 C.CString 放进循环后只在循环末尾统一释放，那会让一批临时副本同时堆积。

三、C 侧保存指针时延后释放

如果 C API 会保存传入指针，立即 defer 就可能变成悬空指针。此时要先查 C API 的文档或源码：它是复制字符串，还是只保存地址；它是否提供与创建动作配对的销毁函数；销毁函数是否必须在同一 C 库中调用。

type cStringHandle struct {
	ptr *C.char // C 侧仍在使用时，句柄持有这块 C 堆内存。
}

func newCStringHandle(s string) *cStringHandle {
	return &cStringHandle{ptr: C.CString(s)} // 返回所有权，不在这里 defer。
}

func (h *cStringHandle) Close() {
	if h == nil || h.ptr == nil {
		return // Close 可重复调用，避免同一指针被释放两次。
	}
	C.free(unsafe.Pointer(h.ptr)) // 只有确认 C 侧不再读取后才能释放。
	h.ptr = nil // 清空句柄，阻止后续误用。
}

这个示例只表达生命周期思路：真实项目如果 C 库提供 library_destroy、release_name 之类的专用函数，应优先调用它，不要假设所有返回值都能用系统 free。跨动态库分配和释放器不匹配，可能比单纯泄漏更快暴露为崩溃。

四、转回 Go 前先复制再释放

当 C 函数返回一个以 NUL 结尾的字符串时，先确认它的分配契约，再用 C.GoString 复制到 Go 内存。复制完成后，只有在该指针确实由 malloc 或 C.CString 这类与 free 配对的方式产生时，才能调用 C.free。如果文档要求专用释放函数，就按专用函数处理。

func readAndRelease(p *C.char) string {
	if p == nil {
		return "" // C 返回 NULL 时先处理空指针，避免传入不明契约。
	}
	result := C.GoString(p) // 先复制到 Go 堆，后续不再依赖 C 指针。
	C.free(unsafe.Pointer(p)) // 仅适用于明确由兼容分配器创建的返回值。
	return result
}

最常见的误区有三个：只释放 Go 变量而没有释放 C 副本；C 仍保存指针时过早释放；以及把 C 库专用返回值交给错误的释放器。排查时不要只看 unsafe.Pointer 的转换，它解决的是类型适配，不会自动解决所有权。

五、发布前按所有权清单排查

可以沿着每个 C.CString 逐项问四个问题：这块内存由谁分配？C 函数只借用还是会保存？谁在什么时刻释放？释放动作是否与分配器匹配？普通同步调用应看到“分配后立即 defer”；异步或长期保存应看到明确的 Close、destroy 或 release 契约；返回 Go 前应先完成复制。

长时间运行的服务还要把 C 堆增长纳入观察范围。Go 的 GC 日志或堆分析不能替代对 C 分配的检查；若 C 侧泄漏，Go 视角的对象可能已经消失，但进程的原生内存仍会持续上涨。

相关问题

C.CString 能不能直接依赖 Go GC 回收？

不能。它的结果在 C 堆，必须由匹配的 C 释放函数回收。

每次都用 defer C.free 可以吗？

只适合 C 函数同步借用指针的场景。C 保存指针或异步使用时，应把释放延后到明确的结束动作。

C.GoString 后还需要保留原指针吗？

如果只需要 Go 字符串，C.GoString 完成复制后即可按契约释放原 C 指针；返回值若有专用释放函数，必须使用它。