因为公司安排,我临时从Java项目组调往Go项目组,经过差不多5天业余时间对Go学习后,架构师让我给公司同事进行了Golang的分享和培训.
同事们很热爱技术, 本来预计40分钟的分享, 由于同事们积极的讨论和Go大佬同事的热情补充分享, 最终持续了2个多小时. 我把此次分享中几个讨论热烈的重要知识点记录下来, 方便大家入门GO的时候避坑.

go中的dealock主要分为两类:

1. channel相关的死锁

读写nil channel,导致的死锁

func main() {
 ch := make(chan int)
 ch <- 1 
}

goroutine 1 [chan send]:

2. 教科书式的死锁

这个是操作系统教科书中的死锁,互相等待对方释放锁。

var lock1 *sync.Mutex
var lock2 *sync.Mutex
func main() {
 lock1 = new(sync.Mutex)
 lock2 = new(sync.Mutex)
 go func() {
 lock1.Lock()
 fmt.Println("I'm a goroutine,I have lock1,and I need lock2.")
 time.Sleep(time.Second)
 lock2.Lock()
 lock2.Unlock()
 lock1.Unlock()
 }()
 lock2.Lock()
 fmt.Println("I'm the main goroutine,I have lock2,and I need lock1.")
 time.Sleep(time.Second)
 lock1.Lock()
 lock1.Unlock()
 lock2.Unlock()
 time.Sleep(5 * time.Second)
}

goroutine 1 [semacquire]:

易错点

Q: 是不是只要唯一的mian goroutine阻塞了,就会导致死锁
A: 不是,只有nil channel导致的阻塞,才会导致死锁. 由于其他原因导致的阻塞不会导致死锁,如下面这个例子.

func main() {
 log.Fatal(http.ListenAndServe(":8000", nil)) //block
 log.Print("This doesn't print")
 fmt.Println("Can't reach here.")
}

Q: 什么时候go的runtime会检索到deadlock
A: 只有当所有的goroutine都不能被访问时候, go的runtime会检测到这种情况,并抛出deadlock. (TODO,这个结论还是不太完善)

更多deadlock的例子: https://gitee.com/sicnu-yudidi/go/tree/master/go-3/deadlock

https://programming.guide/go/detect-deadlock.html
https://stackoverflow.com/questions/42432880/why-does-this-goroutine-block

有疑问加站长微信联系(非本文作者)

• 请尽量让自己的回复能够对别人有帮助
• 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
• 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
• 图片支持拖拽、截图粘贴等方式上传