簡述 提取演算法中不變的部分封裝成方法，變化的部分延遲到子類。 延遲到子類 這個說法在學習設計模式的時候經常出現，實際就是利用多態在子類中重寫方法，使得實行時根據實例的類型調用不同的方法。 話不多說，看個案例。 優化案例 最初版v0 連接資料庫我們有很多種方式，JDBC、JNDI、ODBC等等。下麵是 ...
索引：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也會被覆制。
因為鎖被覆制了，所以對於同一個臨界資源，處於不同鎖的讀寫操作可以同時訪問。
