索引：https://www.waterflow.link/articles/1666884810643
当我们打印错误的时候使用锁可能会带来意想不到的结果。
我们看下面的例子：
package main
import (
"fmt"
"sync"
)
type Courseware struct {
mutex sync.RWMutex
Id int64
Code string
Duration int
}
func (c *Courseware) UpdateDuration(duration int) error {
c.mutex.Lock() // 1
defer c.mutex.Unlock()
if duration < 60 {
return fmt.Errorf("课件时长必须大于等于60秒： %v", c) // 2
}
c.Duration = duration
return nil
}
// 3
func (c *Courseware) String() string {
c.mutex.RLock()
defer c.mutex.RUnlock()
return fmt.Sprintf("id %d, duration %d", c.Id, c.Duration)
}
func main() {
c := &Courseware{}
fmt.Println(c.UpdateDuration(0))
}
上面的代码看起来貌似没有什么问题，但是却会导致死锁：
- 更新课件时长的时候上锁，避免出现数据竞争
- 判断如果时长小于60秒的话，就报错。但是注意这里fmt.Errorf打印结构c会调用String()方法
- 我们看String方法里面，又使用了读锁，避免读取的时候数据被更新
因为对临界资源重复上锁，所以导致了死锁的问题。解决办法也很简单：
-
把锁放到错误判断之后：
func (c *Courseware) UpdateDuration(duration int) error { if duration < 60 { return fmt.Errorf("课件时长必须大于等于60秒： %v", c) // 2 } c.mutex.Lock() defer c.mutex.Unlock() c.Duration = duration return nil } -
不使用String方法，避免重复上锁：
package main import ( "fmt" "sync" ) type Courseware struct { mutex sync.RWMutex Id int64 Code string Duration int } func (c *Courseware) UpdateDuration(duration int) error { c.mutex.Lock() defer c.mutex.Unlock() if duration < 60 { return fmt.Errorf("课件时长必须大于等于60秒： %d， id: %d", c.Duration, c.Id) // 打印放在一个锁里面也能保证安全 } c.Duration = duration return nil } func main() { c := &Courseware{} fmt.Println(c.UpdateDuration(0)) }go run 10.go 课件时长必须大于等于60秒： 0， id: 0
我们再看一个切片的例子：
package main
import (
"fmt"
)
func main() {
s := make([]int, 1)
go func() {
s1 := append(s, 1)
fmt.Println(s1)
}()
go func() {
s2 := append(s, 1)
fmt.Println(s2)
}()
}
我们初始化了一个长度为1，容量为1的切片，然后分别在2个协程里面调用append往切片追加元素。这种情况会导致数据竞争么？
答案是不会。在其中一个协程里面，当我们append元素的时候，因为s的容量为1，所以底层会复制一个新的数组；同样另一个协程也是如此。
go run -race 10.go
[0 1]
[0 1]
注意：这里的关键就是，两个协程是否会同时访问一个内存空间，这时导致数据竞争的关键。
我们稍微修改下上面的例子：
package main
import (
"fmt"
)
func main() {
s := make([]int, 1, 10) // 1
go func() {
s1 := append(s, 1)
fmt.Println(s1)
}()
go func() {
s2 := append(s, 1)
fmt.Println(s2)
}()
}
- 我们给s加了一个足够大的容量
go run -race 10.go
[0 1]
==================
WARNING: DATA RACE
Write at 0x00c0000c0008 by goroutine 8:
main.main.func2()
...
可以看到这就产生了数据竞争的问题。因为s的容量足够大，所以两个协程有可能操作同一个底层数组的同一块内存。
解决办法也很简单，重新copy一个s就行了。
下面我们继续看一个map的例子：
package main
import (
"strconv"
"sync"
"time"
)
// 1
type User struct {
mu sync.RWMutex
online map[string]bool
}
// 2
func (u *User) AddOnline(id string) {
u.mu.Lock()
u.online[id] = true
u.mu.Unlock()
}
// 3
func (u *User) AllOnline() int {
u.mu.RLock()
online := u.online // 4
u.mu.RUnlock()
sum := 0
for _, o := range online { // 5
if o {
sum++
}
}
return sum
}
func main() {
u := &User{}
u.online = make(map[string]bool)
go func() {
for i := 0; i < 10000; i++ {
u.AddOnline("userid" + strconv.Itoa(i))
}
}()
go func() {
for i := 0; i < 10000; i++ {
u.AllOnline()
}
}()
time.Sleep(time.Second)
}
- 我们有一个用户的