GO goroutine死锁

博客主要探讨了Go语言中协程死锁的问题。通过两个死锁现场的分析,发现主协程是否被阻塞是关键。经过多次实验得出,保证主协程不被阻塞、主协程中尽量不用chan可避免死锁。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

死锁现场1 :

package main
func main() {
	ch := make(chan int)

	<- ch
}

运行结果:

fatal error: all goroutines are asleep - deadlock!

分析:
只有一个主协程,在<-ch时就阻塞上了,并未检测到其它的活跃并相关的协程

死锁现场2 :

package main

import (
	"fmt"
	"time"
)

func main() {
	ch := make(chan int)

	ch <- 1
	ch <- 2
	ch <- 3


	go func(ch chan int) {
		//time.Sleep(time.Second)
		fmt.Println(<- ch)
		fmt.Println(<- ch)
		fmt.Println(<- ch)
	}(ch)


	time.Sleep(time.Second*5)
}

运行结果:

fatal error: all goroutines are asleep - deadlock!

分析:
在ch <- 1时主协程被阻塞了,并未执行到启动下面协程的代码。

为什么会有死锁的产生?

经过多次的实验发现,只要主协程没被锁上就不会有问题,上段代码来研究一下:

package main

import (
	"fmt"
	"time"
)

func main() {
	ch := make(chan int)

	go func(ch chan int) {
		//time.Sleep(time.Second)
		for j:=0;j<5 ;j++  {
			fmt.Println(<- ch)
		}
	}(ch)

	time.Sleep(time.Second)
	for i:=0;i<4 ;i++  {

		ch <- i
	}

	time.Sleep(time.Second*5)
}

分析:
1、上面代码中肯定是上面开启的协程被阻塞了,但是并不影响
2、如果把主协程中的输入放到开启线程前面,那先被阻塞的主协程,那这就死锁了
3、如果输入的数量多,输出的数据量,那最后等待被读取的肯定是主线程,那会死锁
4、如果输入的数量少,那是后开启的子协程被阻塞,没影响
5、把输入也给放到新的协程中,那么输入多或是输出多都没关系,因为主协程没被阻塞

结论:
1、保证主协程不被阻塞
2、主协程中尽量不要用chan

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值