共计 4433 个字符，预计需要花费 12 分钟才能阅读完成。
索引：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)
}- 咱们有一个用户的机构，外面有个 online 字段是一个 map，外面保留了在线的用户信息
- 咱们有一个增加在线用户的办法 AddOnline，办法外面应用了锁，是因为 map 是并发不平安的
- 咱们还有一个统计所有在线用户的办法 AllOnline
- 在 AllOnline 中，咱们拜访 u.online 的 map，咱们加上了读锁。这里的想法是拜访以后在线用户的 map，并赋值给 online，而后开释读锁
- 遍历赋值的 online 查出在线用户的数量
可能咱们感觉这个是没问题的，然而当咱们运行程序的时候会发现这里存在数据竞争：
go run -race 10.go
==================
WARNING: DATA RACE
Write at 0x00c0000a0060 by goroutine 6:
runtime.mapassign_faststr()
...
==================
fatal error: concurrent map iteration and map write 这是因为，在 map 外部，是 hmap 构造，次要蕴含元数据（例如，计数器）和援用数据桶的指针。因而，online := u.online 不会复制理论数据，而是复制的指针，实际操作的还是同一片内存。
解决这个问题也不难：
-
咱们能够把锁的范畴扩充，像上面这样：
func (u *User) AllOnline() int {u.mu.RLock() defer u.mu.RUnlock() online := u.online sum := 0 for _, o := range online { if o {sum++} } return sum } -
另一种办法就是复制一个正本进去，像下面咱们说的切片一样：
func (u *User) AllOnline() int {u.mu.RLock() online := make(map[string]bool, len(u.online)) for s, b := range u.online {online[s] = b } u.mu.RUnlock() sum := 0 for _, o := range online { if o {sum++} } return sum }
下面的例子中咱们应用了 *User 定义了 2 个办法：
func (u *User) AddOnline(id string) {u.mu.Lock()
u.online[id] = true
u.mu.Unlock()}
func (u *User) AllOnline() int {u.mu.RLock()
online := make(map[string]bool, len(u.online))
for s, b := range u.online {online[s] = b
}
u.mu.RUnlock()
sum := 0
for _, o := range online {
if o {sum++}
}
return sum
}我当初咱们略微批改下下面的列子：
package main
import (
"strconv"
"sync"
"time"
)
type User struct {
mu sync.RWMutex
online map[string]bool
}
func (u User) AddOnline(id string) {u.mu.Lock()
u.online[id] = true
u.mu.Unlock()}
func (u User) AllOnline() int {u.mu.RLock()
online := make(map[string]bool, len(u.online))
for s, b := range u.online {online[s] = b
}
u.mu.RUnlock()
sum := 0
for _, o := range online {
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)
}当初咱们间接应用 User 构造体定义这两个办法，然而当咱们执行程序的时候，报了数据竞争的谬误：
go run -race 10.go
==================
WARNING: DATA RACE
Read at 0x00c00011e060 by goroutine 7:
main.User.AllOnline()这个又是什么起因造成的呢？这是因为，当我门应用 User 作为参数时，间接复制了 User 的正本，因而 sync.RWMutex 也会被复制。
因为锁被复制了，所以对于同一个临界资源，处于不同锁的读写操作能够同时拜访。