Golang返回函数时的内存分配机制、效率及缺陷问题

你给出的示例代码本质是返回一个捕获了外部变量a的闭包：

func MyHandler(a int) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.WriteCode(a)
    })
}

内存视角的运行逻辑 #

Go里返回的函数如果是闭包，内存分配会拆分两部分处理，和返回普通值的逻辑完全不同：

• 函数指令部分：所有相同逻辑的闭包共享同一份编译生成的机器指令，这部分内容在编译期就确定，存放在进程的只读代码段，不会随MyHandler的每次调用重复分配，哪怕函数内部逻辑再复杂，这部分也只会占用一次内存。
• 闭包实例部分：每次调用MyHandler生成的闭包实例是一个极小的结构体，64位系统下仅占16字节：8字节存储对应函数指令的指针，剩下8字节存储闭包捕获的外部变量的上下文指针。

另外Go的逃逸分析会提前判定捕获变量的存储位置：如果返回的闭包只会在MyHandler栈帧存活期间使用，捕获的a会直接在栈上分配，闭包结构体存栈地址；如果闭包会在MyHandler退出后继续使用（比如示例里作为HTTP handler后续处理请求），a会逃逸到堆上分配，闭包结构体存a的堆地址。

实现效率 #

这种闭包返回的实现方式在绝大多数场景下效率很高：

• 闭包实例本身的内存占用和分配开销极低，哪怕每次HTTP请求生成一个，对性能的影响可以忽略不计
• 闭包的执行逻辑和普通函数调用完全一致，没有额外的运行时开销
• 只有当捕获的变量需要逃逸到堆时才会产生堆分配开销，若捕获的是int、bool这类小体积变量，带来的GC压力也极小

存在的缺点 #

该实现也存在部分场景下的短板：

• 若闭包捕获了大量大体积的外部变量，这些变量会因为被闭包引用从栈逃逸到堆，会增加GC的扫描和回收压力，高频调用场景下可能产生明显的性能损耗
• 若闭包的生命周期很长，被捕获的变量哪怕后续不会再被使用，也会被闭包一直持有无法被GC回收，容易引发隐性内存泄漏，比如闭包捕获了一个大切片，只要闭包还存活，整个切片占用的内存都不会被释放
• 极端高频调用场景下（比如每秒十万次以上的调用），大量重复创建闭包的微小时耗累计后可能成为性能瓶颈，这类场景可以考虑预创建闭包、用结构体携带参数代替闭包等方案优化

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