Go语言是否应复用context.Background()？内存影响分析

两种写法没有任何内存层面的差异，完全没必要专门维护一个全局emptyCtx变量，每次调用context.WithDeadline(context.Background(), ...)是完全可行的无额外开销写法，不会成为内存泄漏的诱因。

• 标准库中context.Background()返回的本来就是全局单例的emptyCtx实例，属于包级初始化的全局指针，每一次调用context.Background()都只是返回这个固定地址，不会产生任何新的内存分配，也不会生成新的对象。
• 自定义全局变量var emptyCtx = context.Background()本质只是把这个全局单例指针多存了一份副本。两种写法传给context.WithDeadline的父节点是完全相同的内存地址，派生出来的子上下文（timerCtx类型）的内存结构、父指针指向、生命周期绑定逻辑完全一致，不存在内存占用、GC行为上的区别。

不要在父节点选全局变量还是Background()上浪费排查时间，gRPC场景下context相关的内存泄漏绝大多数来自以下问题：

• 派生上下文后漏调cancel函数：所有WithDeadline/WithTimeout/WithCancel返回的cancel函数，必须在请求逻辑结束时通过defer cancel()主动调用。哪怕设置了明确的截止时间，主动调用cancel会立刻终止关联的定时器、释放timerCtx占用的资源，不需要等定时器到超时时间才触发回收。如果漏写cancel，大量长超时的未释放timerCtx堆积在运行时定时器堆里，是高并发下内存暴涨的最常见原因。
• 过期上下文被意外持有引用：检查是否有代码在请求结束后，仍然持有已经cancel/过期的context指针，导致关联的done channel、存储在context中的值、timer对象无法被GC回收。
• 错误使用长生命周期context派生请求上下文：如果父节点不是不携带值、永不cancel的emptyCtx，而是绑定了服务生命周期、或者携带大对象value的长生命周期context，大量派生的子context会隐式持有父节点引用，可能导致父节点关联的大对象无法回收——但这个问题在使用Background()或者全局emptyCtx作为父节点时不会存在，因为emptyCtx本身不携带任何值，属于全局常驻内存对象，不存在回收问题。

不要自己实现自定义的emptyCtx类型，标准库的emptyCtx做了特殊逻辑优化（比如done channel直接返回nil、无额外定时器关联逻辑），自定义实现反而可能引入额外开销或者逻辑异常。

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