无缓冲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产品图添加背景
相关推荐
做运维的阿瑞7 小时前
数据库增删改的安全写法蒸鱼Yuzheng7 小时前
设备端性能工件可靠导出:断点续传、哈希、manifest 与失败恢复程序边界7 小时前
迁移评估不再拍脑袋,这个数据迁移工具的量化报告把我救了(上)阿狗童鞋8 小时前
Redis实战指南圆圆讲门店8 小时前
挑选同城获客服务机构时需要考量的核心因素都有哪些?傻啦嘿哟8 小时前
Python的默认参数把我坑惨了,原来写[]和写None的区别这么大微小冷8 小时前
Python凸优化cvxpy初步在世修行8 小时前
干货:显式映射 vs 自动判据晨小安8 小时前
ThreadLocal及其内存泄漏问题深度解析xzal128 小时前
Python之简单理解栈和队列