Mutex和上厕所居然有这么多异曲同工之妙
本文采取对话形式，有两个登场人物，左边是导师：欧阳狂霸，右边是实习生：三多。 提示：浅色主题阅读体验更佳。
Mutex介绍
欧阳狂霸小课堂
<<< 左右滑动见更多 >>>
func concurIncr() {
var wg sync.WaitGroup
wg.Add(10)
var a int
for i := 0; i < 10; i++ {
go func() {
defer wg.Done()
for j := 0; j < 1000; j++ {
a++
}
}()
}
wg.Wait()
println(a) // 小于10000的随机数。
}
欧阳狂霸小课堂
<<< 左右滑动见更多 >>>
CAS用来保证加锁过程中的原子性，会比较地址指针是否为old，
为old说明操作期间没有被打断，
就地址值替换为new，返回true,
不为old, 代表操作期间被其他线程打断了，返回false。
CAS伪代码：
bool Cas(int32 *val, int32 old, int32 new)
Atomically:
if(*val == old){
*val = new;
return 1;
}else
return 0;
CAS汇编码：
TEXT runtime∕internal∕atomic·Cas(SB), NOSPLIT, $0-13
MOVL ptr+0(FP), BX
MOVL old+4(FP), AX
MOVL new+8(FP), CX
LOCK
CMPXCHGL CX, 0(BX)
SETEQ ret+12(FP)
RET
func main() {
a := 1
var mu sync.Mutex
go func() {
mu.Lock()
println("lock")
a += 2
//time.Sleep(time.Second)
time.Sleep(time.Second)
println("unlock")
mu.Unlock()
}()
go func() {
println("other")
a += 3
println("done")
}()
time.Sleep(time.Second * 5)
}
//print :
// lock
// other
// done
// unlock
Mutex使用
- 等待的goroutine执行的顺序是什么
- 非cpu中的goroutine的切换是有性能损耗的，正处于cpu切换的goroutine的切换不需要做上下文切换，如何设计以获得更好的性能
- 如果某个goroutine一直得不到调度怎么办
- 有的协程临界资源可能很快，但如果恰好其他线程抢锁没抢到，那它就要去排队吗？有没有啥方法让这个协程多抢一会
欧阳狂霸小课堂
<<< 左右滑动见更多 >>>
func main() {
a := 1
var mu sync.Mutex
go func() {
mu.Lock()
println("lock")
a += 2
//time.Sleep(time.Second)
time.Sleep(time.Second)
}()
go func() {
a += 3
println("unlock")
println(a)
mu.Unlock()
}()
time.Sleep(time.Second * 5)
}
func concurIncr() {
var wg sync.WaitGroup
var mu sync.Mutex
wg.Add(10)
var a int
for i := 0; i < 10; i++ {
go func() {
defer wg.Done()
for j := 0; j < 1000; j++ {
mu.Lock()
a++
mu.Unlock()
}
}()
}
wg.Wait()
println(a) // 10000
}
type SafeCounter struct {
mu sync.Mutex
v map[string]int
}
func (c *SafeCounter) Inc(key string) {
c.mu.Lock()
// Lock so only one goroutine at a time can access the map c.v.
c.v[key]++
c.mu.Unlock()
}
func (c *SafeCounter) Value(key string) int {
c.mu.Lock()
// Lock so only one goroutine at a time can access the map c.v.
defer c.mu.Unlock()
return c.v[key]
}
func foo() {
mu.Lock()
defer mu.Unlock()
// 如果不用defer
err := ...
if err != nil{
//log error
return //需要在这里Unlock()
}
return //需要在这里Unlock()
}
func (t *Transport) CloseIdleConnections() {
t.nextProtoOnce.Do(t.onceSetNextProtoDefaults)
t.idleMu.Lock()
m := t.idleConn
t.idleConn = nil
t.closeIdle = true // close newly idle connections
t.idleLRU = connLRU{}
t.idleMu.Unlock()
for _, conns := range m {
for _, pconn := range conns {
pconn.close(errCloseIdleConns)
}
}
if t2 := t.h2transport; t2 != nil {
t2.CloseIdleConnections()
}
}
Mutex易错点
Panic
func misuse() {
var mu sync.Mutex
mu.Unlock() // fatal error: sync: unlock of unlocked mutex
}
死锁
死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。
type DataStore struct {
sync.Mutex // ← this mutex protects the cache below
cache map[string]string
}
func (ds *DataStore) get(key string) string {
ds.Lock()
defer ds.Unlock()
if ds.count() > 0 { <-- count() also takes a lock!
item := ds.cache[key]
return item
}
return ""
}
func (ds *DataStore) count() int {
ds.Lock()
defer ds.Unlock()
return len(ds.cache)
}
锁的粒度
// Don't do the following if you can avoid it
func doSomething() {
mu.Lock()
item := cache["myKey"]
http.Get() // Some expensive io call
mu.Unlock()
}
// Instead do the following where possible
func doSomething(){
mu.Lock()
item := cache["myKey"]
mu.Unlock()
http.Get() // This can take awhile and it's okay!
}
本文参与 腾讯云自媒体分享计划，分享自微信公众号。
原始发表：2021-06-20，如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读
目录