GO的一些易错踩坑点笔记

最近在看golang语言的代码,体会到了go语言的一些强大之处。

感觉融合了java,python等语言的优点,不想java那么臃肿,一些方法的定义和使用更加方便。

但是如果不深入了解一些特性的原理,可能会造成一些出乎意料的错误,尤其在一些细节上。

在这篇文章中,简单列举一些容易踩坑的点。

for range 与 goroutine

当我们执行下面样例时,预期的效果是打印数组中的每一个元素,,但是实际输出时却都是打印最后一个元素。

css 复制代码
func demo1() {
    var m = [...]int{1, 2, 3, 4, 5}
    for i, v := range m {
        go func() {
            time.Sleep(time.Second * 3)
            fmt.Println(i, v)
        }()
    }
    time.Sleep(time.Second * 10)
}

实际打印结果:

复制代码
4 5
4 5
4 5
4 5
4 5

这是为什么呢?

这是因为goroutine执行的闭包函数引用了它的外层包裹函数中的变量i,v,这样变量i,v在主goroutine和新启动的goroutine之间实现了共享。在各个gorountine中会先等待一段时间,这使i,v已经在外层被替换成新的值,所以没有像预期的那样输出值。

如果要达到预期的效果,应该怎样修改呢?

可以在每个gorountine创建时将当时的i,v进行绑定,或者先赋值给一个临时变量。

for range 进行元素复制

假设有这样一个场景,我们遍历一个切片,对切片中的元素放到一个指针切片

css 复制代码
list2 := []Demo{{"a"}, {"b"}}
    var alist []*Demo
    for _, test := range list2 {
        fmt.Printf("addr=%p\n", &test)
        alist = append(alist, &test)
    }
    fmt.Println(alist[0].Name, alist[1].Name)

打印结果:

ini 复制代码
addr=0x14000096230
addr=0x14000096230
b b

和预期的结果不符

每次遍历打印的内存地址都是相同,所以如果我们存放的是指针,本质上存储的都是同一块内存地址的内容,所以值相同。

如何想达到预期效果,我们只需将test赋值给一个临时变量即可,通过打印地址也可以发现临时变量temp的地址发生了变化。

css 复制代码
list2 := []Demo{{"a"}, {"b"}}
    var alist []*Demo
    for _, test := range list2 {
        temp := test
        fmt.Printf("addr=%p\n", &temp)
        alist = append(alist, &temp)
    }
    fmt.Println(alist[0].Name, alist[1].Name)

打印结果:

ini 复制代码
addr=0x14000010270
addr=0x14000010280
a b

更多具体类似的例子可以阅读该文章:github.com/golang/go/w...

for range与切片等元素修改

当我们在for range进行遍历的时候,如果我们对原先切片进行添加操作,后面再读取时并不会读取到最新添加的元素。

例如:

css 复制代码
var a = []int{1, 2, 3, 4, 5}
    var r = make([]int, 0)
    for i, v := range a {
        if i == 0 {
            a = append(a, 6, 7)
        }
        r = append(r, v)
    }
    fmt.Println("r = ", r)
    fmt.Println("a = ", a)

打印结果:

ini 复制代码
r =  [1 2 3 4 5]
a =  [1 2 3 4 5 6 7]

从上面可以看出并没有将新添加的元素 "6,7"添加到新的切片r中。

因为循环遍历中的切片a只是原切片的一个副本。

相关推荐
用户28988180666422 小时前
Sarama消费组初始化阻塞问题排查
后端·go
qqxhb2 小时前
零基础设计模式——行为型模式 - 迭代器模式
java·设计模式·go·迭代器模式
Brian Xia3 小时前
Jaeger开源分布式追踪平台深度剖析(三)Jaeger默认存储Badger原理剖析
分布式·go·lsm-tree
江湖十年8 小时前
一行命令统计代码行数
后端·go·命令行
DemonAvenger8 小时前
Go 中 string 与 []byte 的内存处理与转换优化
性能优化·架构·go
程序员爱钓鱼9 小时前
Go并发模型与模式:context 上下文控制
后端·google·go
码一行1 天前
Go 1.24 Weak指针:内存管理的新利器
go
码一行1 天前
为什么 Go 语言不支持泛型方法?
后端·go
程序员爱钓鱼1 天前
Go语言并发模型与模式:Fan-out / Fan-in 模式
后端·go
喵个咪1 天前
开箱即用的GO后台管理系统 Kratos Admin - 后端权限控制
后端·go·api