无缓冲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产品图添加背景
相关推荐
Databend3 小时前
从湖仓升级为 Agent 时代的数据控制面,Snowflake 和 Databricks 有哪些布局ClouGence6 小时前
SQL Server CDC 能放到 Always On 备库读吗?一文讲透原理与实践你好潘先生7 小时前
别再记命令了,用 yeero do 说句人话就能跑脚本,而且不烧 tokenAgent_大师8 小时前
WebSocket 行情重连成功,K线缺口不会自动消失荣码8 小时前
LLM结构化输出:让AI返回JSON而不是废话,我踩了4个坑copyer_xyf8 小时前
FastAPI 如何连接 MySQLapocelipes21 小时前
常用编程语言和库的正则表达式性能对比先吃饱再说1 天前
存储的进化:从 MySQL 到浏览器缓存,数据到底住在哪?用户8356290780511 天前
使用 Python 在 PDF 中创建与管理书签Nturmoils1 天前
字段太多看不全,ksql 的展开模式和输出控制怎么用