Go 初学者，有没有老哥能告诉我在写代码的时候应该如何避免内存泄漏的问题

目前已经写完一个项目，即将上服务器（有固定人流量），所以有点紧张，想临上线前看看有没有出一些愚蠢低级的错误（）

go 有 gc ，何来内存泄漏一说。逻辑问题你只能写代码时看清楚吧。

定时重启 /狗头

@GeekGao 谢谢好心人，我对照着自查一下！
@ashin 难道他真是天才？？！

线上默认把 pprof 打开，别到时候发现泄露了还得重新编译

你不用 unsafe ，不用 arena 之类的东西的话一般不会有内存泄漏。一般泄漏的都是 fd 、socket 、goroutine 之类的东西。

写完让 ChatGpt 检查一下

一般使用 go 的一些静态检查分析工具，过滤掉大多数问题代码，go vet 工具

golang 能写出内存泄露，应该也挺不容易的吧

一般泄露的都是全局资源，小项目挺难遇到的

我唯一遇到过一次的 go 内存泄漏是 goroutine 工作完成后没有结束(被阻塞了) 然后相关的资源都没有释放, 别的基本遇不到内存泄漏

go 一般是资源泄露，用 goroutine 前想想这个东西的生命周期就能避免大多数情况。

go 的垃圾回收还是很健壮的，非常规问题不考虑内存泄漏

别再 for 里用 time.after

建议你使用 Java21 版本 和 graalvm.org 这种多语言虚拟机，可以管理多语言跑多语言，管理内存分配。

go lint 扫一下，profile 看看内存和协程数量

你在这发有啥用？赶紧上线啊。让用户帮你测试。

我 go 项目有用到 cgo ，没想到用的那个 cgo 库居然自带内存泄露。。。

一般不是搞一堆 goroutin 很难触发，注意使用 defer ，定时重启，go 原生程序重启真的很快

Go 不乱搞一般没有内存泄露，资源泄露排查一下打开的东西是不是没关

@Ipsum 这个问题在 1.23 版已经解决了，不会又问题了。

https://github.com/UltimateYhq/100-GO-mistakes

看这种常规错误避免，剩下 gc 帮你兜底应该问题不大。

1. checklist 各种，这里手打太麻烦了，你可以直接上网搜一下，主要还是协程泄露比较多，全局变量的泄露很少的，避免协程被 chan 阻塞，基本就可以了
2. 建立优雅重启的方案，如果你的程序一小时可以无损的重启一次，加上监控，内存大了起个新的实来接管流量，这个可以把影响降到最低
3.其实比起内存泄露，你更应该担心的是 panic 导致的进程异常退出，没处理好容易有各种的脏数据

懂了，先搞一个启动器，接管 tcp/udp ，启动主程序，并定时启动新的，关掉旧的……
客户端连接的时候映射到新启动的，旧的自然就不需要了。

完美~

等等，这不就是集群么

没用过 go ，真的有企业采用定时重启方案？震惊

@oneisall8955 企业不是定时重启，而是是版本迭代加 pgo 优化编译 人工狗头

@oneisall8955 #26 同样震惊

@oneisall8955 有，以前听过一个同事分享过，某大安全厂商旗下搜索引擎有个服务，第三方库搞不定内存泄露问题，就用重启大法了。

@mainjzb 好！谢谢老哥，我看看
@testcgd 恩恩，想问问大佬，如果协程只是执行一个函数（比如：更新数据库记录）这种不需要 channel 通信的，是不是基本不会有阻塞的问题？

@bunny189 基本不会，不过也要看实现，有时候不一定是阻塞，qps 高的时候慢查询也会有问题的，上线再说，有问题重启就好

@testcgd 明白了，谢谢您！

一般只需要注意 goroutine 结束不了的情况，比如一直阻塞。

- 统计 gorouting 使用场景并上报 metric 。如果是 HTTP 服务可以接口路径作为一个 label ，这样即使发生 goroutine 泄露也能快速定位是哪个场景的问题。
- 少修改全局变量。全局变量修改会涉及竞态问题也麻烦
- pprof 可以不开启，但是可以做个内部调用接口开启，在发生内存泄漏的时候开启然后收集即可，这样对性能影响也不大。

重启方案 当然是最简单实用的方案啊

线上默认把 pprof 打开就行了，我写了四五年 go 了，还从来没遇到过内存泄露。

一般 fd 、goroutine 之类的泄露比较多。

@GeekGao #30 我当年也遇到过，某个第三方库内存泄露了，一时半会搞不到，恰好又遇到双十一活动，上报 cto 后，协调了几十台几 T 内存的服务器过来硬扛了半个月，每天不同机器再轮流重启

@Jinnrry 2333 能解决业务问题就好。