无缓冲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 分钟前
FastAPI 进阶实战:请求体、文件上传、响应模型与数据校验Dicky-_-zhang34 分钟前
分布式事务解决方案TCC实战雨辰AI1 小时前
人大金仓 V9 生产级专用监控大盘(含 120 + 指标 + 告警规则 + 一键导入)ZhengEnCi1 小时前
09a-斯坦福 CS336 作业一:BPE 分词器测试员周周1 小时前
【Appium 系列】第18节-重试与容错 — 移动端测试的稳定性保障还是鼠鼠1 小时前
AI掘金头条新闻系统 (Toutiao News)-用户注册-创建用户灰灰勇闯IT1 小时前
DeepSeek-R1 在 CANN 上的推理部署l1t1 小时前
Hy-MT2-1.8B总结的pgvector 0.8.2解决了并行HNSW索引构建漏洞我是一颗柠檬2 小时前
【MySQL全面教学】MySQL条件查询与排序Day4(2026年)丷丩2 小时前
Postgresql基础实践教程(四)