死锁
死锁的4个条件
不可剥夺
线程已经获得的资源，在未使用完之前，不能被其他线程剥夺，只能在使用完后自己释放。
请求保持
线程 T1 保持了一个资源 R1 占用，但是又提出另外一个资源 R2 请求，此时，资源 R2 被线程 T2 占用，于是 T1 线程必须等待，但又对自己保持的 R1 资源不释放。
循环等待
死锁发生时，必然存在一个 “进程-资源环形链”，例如 进程p0 等待 p1 占用资源，p1 等待 p2 占用的资源， p2 等待 p0 占用的资源，形成了一个环形链。
互斥
线程对资源访问是排斥的，如果一个线程占用了资源，那么其他线程必须处于等待状态，直到资源释放。
如何避免死锁
如果并发的查询多个表，要约定好访问顺序
不能线程 T1 先访问表 A 后访问表 B，线程T2 先访问 表B 后访问 表A, 这个情况极容易死锁。
在同一个事务中，尽可能一次锁定获取所需要的资源
对于容易产生死锁的业务场景， 尝试升级锁的力度
采用分布式锁或者使用乐观锁
死锁代码
package sync
import (
"fmt"
"runtime"
"sync"
"testing"
"time"
)
type value struct {
memAccess sync.Mutex
value int
}
func TestDeadLock(t *testing.T) {
runtime.GOMAXPROCS(3)
var wg sync.WaitGroup
sum := func(v1, v2 *value) {
defer wg.Done()
v1.memAccess.Lock() // 锁 v1
time.Sleep(2 * time.Second)
v2.memAccess.Lock() //锁 v2
fmt.Printf("sum = %d\n", v1.value+v2.value)
v2.memAccess.Unlock()
v1.memAccess.Unlock()
}
product := func(v1, v2 *value) {
defer wg.Done()
v2.memAccess.Lock() // 锁 v2
time.Sleep(2 * time.Second)
v1.memAccess.Lock() // 锁 v1
fmt.Printf("product = %d\n", v1.value*v2.value)
v1.memAccess.Unlock()
v2.memAccess.Unlock()
}
var v1, v2 value
v1.value = 1
v2.value = 1
wg.Add(2)
go sum(&v1, &v2)
go product(&v1, &v2)
wg.Wait()
}
运行结果
=== RUN TestDeadLock fatal error: all goroutines are asleep - deadlock!
goroutine 1 [chan receive]: testing.(*T).Run(0xc000122480, 0x116dd2c, 0xc, 0x1176e68, 0x1084de6) /usr/local/go/src/testing/testing.go:1240 +0x2da testing.runTests.func1(0xc000122300) /usr/local/go/src/testing/testing.go:1512 +0x78 testing.tRunner(0xc000122300, 0xc00012dde0) /usr/local/go/src/testing/testing.go:1194 +0xef testing.runTests(0xc0001320d8, 0x12540e0, 0x1, 0x1, 0x0, 0x0, 0x0, 0x116e218) /usr/local/go/src/testing/testing.go:1510 +0x2fe testing.(*M).Run(0xc00014c080, 0x0) /usr/local/go/src/testing/testing.go:1418 +0x1eb main.main() _testmain.go:51 +0x138
可以看到上述运行结果中出现 fatal error: all goroutines are asleep - deadlock! 线程T1 先获得v1 ,然后获得v2, 线程T2 先获得v2，然后获得v1。这样满足了死锁循环等待等条件，会造成死锁。
到此这篇关于Go 语言中的死锁问题解决的文章就介绍到这了,更多相关Go 死锁内容请搜索M135模板网以前的文章或继续浏览下面的相关文章希望大家以后多多支持M135模板网！
广告
广告
