For range 循环变量通过引用传递给 go 例程会导致内存泄漏
亲爱的编程学习爱好者,如果你点开了这篇文章,说明你对《For range 循环变量通过引用传递给 go 例程会导致内存泄漏》很感兴趣。本篇文章就来给大家详细解析一下,主要介绍一下,希望所有认真读完的童鞋们,都有实质性的提高。
重现问题的代码
go版本go1.19 darwin/amd64
package main
import (
"bytes"
"log"
"net/http"
_ "net/http/pprof"
"runtime"
"strconv"
"sync"
)
type teststruct struct {
m []byte
}
var lkmap sync.mutex
var tmap map[string]*teststruct
const objectcount = 1024 * 100
func main() {
tmap = make(map[string]*teststruct)
wg := &sync.waitgroup{}
wg.add(objectcount)
func1(wg)
wg.add(objectcount)
func2(wg)
wg.wait()
runtime.gc()
log.println(http.listenandserve("localhost:6060", nil))
}
//go:noinline
func func1(wg *sync.waitgroup) {
ts := []*teststruct{}
for i := 0; i < objectcount; i++ {
t := &teststruct{}
ts = append(ts, t)
lkmap.lock()
tmap[strconv.itoa(i)] = t
lkmap.unlock()
}
for i, t := range ts {
go func(t *teststruct, idx int) {
t.m = bytes.repeat([]byte{byte(32)}, 1024)
lkmap.lock()
delete(tmap, strconv.itoa(idx))
lkmap.unlock()
wg.done()
}(t, i) //pass by reference
}
}
//go:noinline
func func2(wg *sync.waitgroup) {
ts := []*teststruct{}
for i := 0; i < objectcount; i++ {
t := &teststruct{}
ts = append(ts, t)
lkmap.lock()
tmap[strconv.itoa(i+objectcount)] = t
lkmap.unlock()
}
for i, t := range ts {
tmp := t //capture here
idx := i
go func() {
tmp.m = bytes.repeat([]byte{byte(32)}, 1024)
lkmap.lock()
delete(tmap, strconv.itoa(idx+objectcount))
lkmap.unlock()
wg.done()
}()
}
}
运行此程序并使用 pprof 通过命令行获取堆:
go tool pprof http://localhost:6060/debug/pprof/heap
将生成如下图:
正如我所见,func1 明显泄漏。 func1 和 func2 之间的唯一区别是 func2 使用局部变量来捕获循环变量。
但是,如果我删除全局地图,两个功能都很好,没有人泄漏。
那么全局地图操作有什么关系吗?
感谢您的任何意见
编辑: 感谢@nipuna 指出,更改 main 函数中 func1 和 func2 的顺序将使 func2 显示在报告中。然而,func1 仍然占用最多的内存,即 51.32%,而 func2 则保留 19.33%
正确答案
我不认为分析器图是内存泄漏试验中的任何强有力的证据。
go 运行时可以比分析器更多地了解其内存分配。尝试使用 runtime.ReadMemStats 输出堆读数。
这是我的实验:https://go.dev/play/p/279du2yB3BZ
func printallocinfo(message string) {
var memstats runtime.memstats
runtime.readmemstats(&memstats)
fmt.println(message,
"heap alloc:", memstats.heapalloc,
"heap objects:", memstats.heapobjects)
}
func main() {
tmap = make(map[string]*teststruct)
wg := &sync.waitgroup{}
for i := 0; i < 10; i++ {
wg.add(objectcount)
printallocinfo("before func2:")
func2(wg)
wg.wait()
runtime.gc()
printallocinfo("after func2: ")
}
println("----------------------------")
for i := 0; i < 10; i++ {
wg.add(objectcount)
printallocinfo("before func1:")
func1(wg)
wg.wait()
runtime.gc()
printallocinfo("after func1: ")
}
println("----------------------------")
runtime.gc()
printallocinfo("after gc: ")
println("----------------------------")
}
输出为
before func1: heap alloc: 260880 heap objects: 1224 after func1: heap alloc: 1317904 heap objects: 2749 before func1: heap alloc: 1319288 heap objects: 2757 after func1: heap alloc: 1576656 heap objects: 3425 before func1: heap alloc: 1578040 heap objects: 3433 after func1: heap alloc: 1858408 heap objects: 4197 before func1: heap alloc: 1859792 heap objects: 4205 after func1: heap alloc: 2210760 heap objects: 4909 before func1: heap alloc: 2212144 heap objects: 4917 after func1: heap alloc: 2213200 heap objects: 4799 before func1: heap alloc: 2214584 heap objects: 4807 after func1: heap alloc: 2247480 heap objects: 5045 before func1: heap alloc: 2248864 heap objects: 5053 after func1: heap alloc: 2298840 heap objects: 5158 before func1: heap alloc: 2300224 heap objects: 5166 after func1: heap alloc: 2297144 heap objects: 5047 before func1: heap alloc: 2298528 heap objects: 5055 after func1: heap alloc: 2316712 heap objects: 5154 before func1: heap alloc: 2318096 heap objects: 5162 after func1: heap alloc: 3083256 heap objects: 7208 ---------------------------- before func2: heap alloc: 3084640 heap objects: 7216 after func2: heap alloc: 3075816 heap objects: 7057 before func2: heap alloc: 3077200 heap objects: 7065 after func2: heap alloc: 3102896 heap objects: 7270 before func2: heap alloc: 3104280 heap objects: 7278 after func2: heap alloc: 3127728 heap objects: 7461 before func2: heap alloc: 3129112 heap objects: 7469 after func2: heap alloc: 3128352 heap objects: 7401 before func2: heap alloc: 3129736 heap objects: 7409 after func2: heap alloc: 3121152 heap objects: 7263 before func2: heap alloc: 3122536 heap objects: 7271 after func2: heap alloc: 3167872 heap objects: 7703 before func2: heap alloc: 3169256 heap objects: 7711 after func2: heap alloc: 3163120 heap objects: 7595 before func2: heap alloc: 3164504 heap objects: 7603 after func2: heap alloc: 3157376 heap objects: 7470 before func2: heap alloc: 3158760 heap objects: 7478 after func2: heap alloc: 3160496 heap objects: 7450 before func2: heap alloc: 3161880 heap objects: 7458 after func2: heap alloc: 3221024 heap objects: 7754 ---------------------------- after gc: heap alloc: 3222200 heap objects: 7750 ----------------------------
看起来你是对的 - 每次迭代时堆中的对象数量都在不断增长。
但是如果我们交换 func1 和 func2 会怎样?让我们在 func1 之前调用 func2:https://go.dev/play/p/ABFq1O11bIl
Before func2: Heap Alloc: 261456 Heap objects: 1227 After func2: Heap Alloc: 1330584 Heap objects: 2529 Before func2: Heap Alloc: 1331968 Heap objects: 2537 After func2: Heap Alloc: 1739280 Heap objects: 3755 Before func2: Heap Alloc: 1740664 Heap objects: 3763 After func2: Heap Alloc: 2251824 Heap objects: 5017 Before func2: Heap Alloc: 2253208 Heap objects: 5025 After func2: Heap Alloc: 2244400 Heap objects: 4802 Before func2: Heap Alloc: 2245784 Heap objects: 4810 After func2: Heap Alloc: 2287816 Heap objects: 5135 Before func2: Heap Alloc: 2289200 Heap objects: 5143 After func2: Heap Alloc: 2726136 Heap objects: 6375 Before func2: Heap Alloc: 2727520 Heap objects: 6383 After func2: Heap Alloc: 2834520 Heap objects: 6276 Before func2: Heap Alloc: 2835904 Heap objects: 6284 After func2: Heap Alloc: 2855496 Heap objects: 6393 Before func2: Heap Alloc: 2856880 Heap objects: 6401 After func2: Heap Alloc: 2873064 Heap objects: 6478 Before func2: Heap Alloc: 2874448 Heap objects: 6486 After func2: Heap Alloc: 2923560 Heap objects: 6913 ---------------------------- Before func1: Heap Alloc: 2924944 Heap objects: 6921 After func1: Heap Alloc: 2933416 Heap objects: 6934 Before func1: Heap Alloc: 2934800 Heap objects: 6942 After func1: Heap Alloc: 2916520 Heap objects: 6676 Before func1: Heap Alloc: 2917904 Heap objects: 6684 After func1: Heap Alloc: 2941816 Heap objects: 6864 Before func1: Heap Alloc: 2943200 Heap objects: 6872 After func1: Heap Alloc: 2968184 Heap objects: 7078 Before func1: Heap Alloc: 2969568 Heap objects: 7086 After func1: Heap Alloc: 2955056 Heap objects: 6885 Before func1: Heap Alloc: 2956440 Heap objects: 6893 After func1: Heap Alloc: 2961056 Heap objects: 6893 Before func1: Heap Alloc: 2962440 Heap objects: 6901 After func1: Heap Alloc: 2967680 Heap objects: 6903 Before func1: Heap Alloc: 2969064 Heap objects: 6911 After func1: Heap Alloc: 3005856 Heap objects: 7266 Before func1: Heap Alloc: 3007240 Heap objects: 7274 After func1: Heap Alloc: 3033696 Heap objects: 7514 Before func1: Heap Alloc: 3035080 Heap objects: 7522 After func1: Heap Alloc: 3028432 Heap objects: 7423 ---------------------------- after GC: Heap Alloc: 3029608 Heap objects: 7419 ----------------------------
func2 堆的增长速度几乎与 func1 一样快,而位于第二位的 func1 的行为与 func2 完全相同 - 仅向堆添加 500 个对象。
从这两个例子来看,我不同意 func1 正在泄漏,而 func2 没有泄漏。我想说,它们的泄漏程度相同。
终于介绍完啦!小伙伴们,这篇关于《For range 循环变量通过引用传递给 go 例程会导致内存泄漏》的介绍应该让你收获多多了吧!欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识,快来关注吧!
详细解释 PHP 如何验证手机浏览器的方法
- 上一篇
- 详细解释 PHP 如何验证手机浏览器的方法
- 下一篇
- 哪种方法是恰当的错误处理方式
-
- Golang · Go问答 | 7小时前 | go · Go GODEBUG 构建缓存 gocacheverify
- Go GODEBUG gocacheverify 校验缓存一致性
- 313浏览 收藏
-
- Golang · Go问答 | 7小时前 |
- Go build 缓存命中异常时的清理与定位
- 226浏览 收藏
-
- Golang · Go问答 | 18小时前 |
- Go cgo.Handle 管理 Go 值跨语言传递
- 403浏览 收藏
-
- Golang · Go问答 | 18小时前 | CGO · 内存管理 · Go问答 · Go CGO unsafe.Pointer cgo.Handle runtime.Pinner
- Go cgo 指针规则导致 panic 的边界定位
- 223浏览 收藏
-
- Golang · Go问答 | 19小时前 | go ·
- Go GOMAXPROCS 变化对并发吞吐的影响
- 417浏览 收藏
-
- Golang · Go问答 | 19小时前 | go · pprof · Go alloc_space inuse_space heap profile
- Go heap profile inuse_space 与 alloc_space 的选择
- 350浏览 收藏
-
- Golang · Go问答 | 20小时前 | go · 性能排查 ·
- Go runtime/trace 观察阻塞区域的阅读方式
- 283浏览 收藏
-
- Golang · Go问答 | 20小时前 | Go问答 · Go pprof 性能剖析 goroutine泄漏 并发排查
- Go pprof goroutine 泄漏剖析的采样方法
- 104浏览 收藏
-
- Golang · Go问答 | 20小时前 | 垃圾回收 · 资源管理 · Go问答 · Go 资源释放 AddCleanup close SetFinalizer
- Go SetFinalizer 不适合资源关闭的替代方案
- 439浏览 收藏
-
- Golang · Go问答 | 21小时前 |
- Go runtime.KeepAlive 防止句柄过早回收
- 489浏览 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 485次学习
-
- PubMedQA
- 深入了解PubMedQA生物医学问答数据集,涵盖其核心功能、使用方法及在临床决策、药物研发等场景的应用,助力提升NLP模型性能。
- 297次使用
-
- H2O EvalGPT
- H2O EvalGPT是H2O.ai推出的开源LLM评估平台,提供详细的大模型性能排行榜、行业特定基准测试及A/B测试功能,助您快速选择最适合项目的高性能大语言模型。
- 352次使用
-
- LMArena
- LMArena是加州大学伯克利分校推出的AI模型匿名评测平台。通过盲测投票机制,用户可对比不同大模型回答并生成实时排行榜,助力开发者优化模型及用户选择最佳AI工具。
- 353次使用
-
- HELM
- 深入了解斯坦福推出的HELM(Holistic Evaluation of Language Models)大模型评测体系。本文解析其核心功能、安装配置步骤及应用场景,涵盖准确性、公平性、鲁棒性等多维度指标,助力开发者全面优化语言模型性能。
- 318次使用
-
- MMBench
- MMBench是由上海人工智能实验室等机构联合推出的多模态基准测试平台,提供细粒度能力评估、大规模数据集及VLMEvalKit工具。本文详细介绍其核心功能、安装使用方法及应用场景,助力开发者全面评估多模态模型性能。
- 136次使用
-
- 用Nginx反向代理部署go写的网站。
- 2023-01-17 502浏览
-
- GoLand调式动态执行代码
- 2023-01-13 502浏览
-
- Go tls.GetCertificate 为什么收不到空 ServerName 请求
- 2026-09-27 501浏览
-
- Go sql.Tx提交成功前读取结果导致事务边界混乱的修复方法
- 2026-09-20 501浏览
-
- Go select 用 time.After 做超时有什么资源代价
- 2026-09-10 501浏览

