无缓冲channel一发就死锁,因其是同步通道:发送操作会立即阻塞,必须有另一goroutine同时执行接收操作才能配对完成,否则所有goroutine休眠触发deadlock。无缓冲 channel 为什么一发就死锁?因为它是同步通道:ch 这一行会卡死,直到有另一个 <a style="color:#f60; text-decoration:underline;" title="go" href="https://www.php.cn/zt/15863.html" target="_blank">go</a>routine 正好在执行 <code>。主 goroutine 自己不启接收协程,又没配对,结果所有 goroutine 都 asleep,直接报 <code>fatal error: all goroutines are asleep - deadlock!。必须配对:一个 goroutine 发,至少一个 goroutine 收(不能是同一个 goroutine 先发后收)调试时加 fmt.Println("before send") 和 fmt.Println("after send"),如果只看到前一句,基本就是卡在发送上了适合场景:goroutine 启动通知、任务完成信号、精确控制执行节奏(比如等某件事做完再继续)用 channel 做"完成信号"怎么写才安全?别用 ch := make(chan int) 然后 ch 就完事------接收端没启动,必死锁。正确做法是让 sender 和 receiver 在不同 goroutine 中,且 receiver 要提前或同步就位。典型模式:sender 发一个零值(如 struct{}{}),receiver 用 阻塞等待用 chan struct{} 而不是 chan int,省空间、语义清、零值无歧义关闭通道不是必须的;若要用,只由 sender 关闭,receiver 绝不调 close(ch)go func() { doWork() ch <- struct{}{} // 通知完成}()<-ch // 主 goroutine 等在这里select + default 为什么比纯阻塞更适合信号场景?纯 会无限等待,一旦信号没来,程序就卡住。而 <code>select 可以加超时或非阻塞兜底,避免逻辑僵死。default 分支让接收变成"尝试读",不阻塞,适合轮询或降级处理搭配 time.After 可实现带超时的等待,防止依赖方失联拖垮主流程注意:select 是随机选就绪分支,多个 case 都 ready 时不会按顺序执行select {case <-done: fmt.Println("收到完成信号")default: fmt.Println("没等到信号,继续干别的")}channel 关闭后还能读吗?怎么判断是不是真关了?能读,但行为分情况:无缓冲 channel 关闭后读,立刻返回零值 + false;有缓冲 channel 关闭后,先读完缓存数据,之后才返回零值 + false。 Mokker AI AI产品图添加背景
相关推荐
魔镜前的帅比2 小时前
(开源项目)x-claw (设计)1001101_QIA2 小时前
工控机网络配置ClouGence3 小时前
加一张临时表,OceanBase Oracle 写入居然快了 30 倍!程序员雷欧3 小时前
ThreadPoolExecutor 深度解析:从核心参数到源码实现的全面剖析tju23333 小时前
信创产业二十年:国产基础软件走到哪一步了?谢尔登3 小时前
分享一些我常用的Skill东方护航数据恢复(深圳)3 小时前
RAID5单盘故障后阵列状态分析与重建风险评估_东方护航数据恢复深圳店k4m7v2pz3 小时前
macOS 解压 40GB 分卷+中文密码固件镜像的五个深坑与解决方案小白学大数据4 小时前
Python 爬虫实战:抓取汽车之家二手车成交价格与里程数据