无缓冲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产品图添加背景
相关推荐
WL_Aurora28 分钟前
Python 算法基础篇之集合treesforest34 分钟前
IP精准定位服务:从城市轮廓到街道坐标,技术如何重塑空间感知大明者省36 分钟前
宝塔开了端口,Ubuntu 还得开相应端口才能打通头歌实践平台1 小时前
招聘大数据可视化Teable任意门互动1 小时前
AI原生开源多维表格有哪些?主流开源多维表格对比解析Cloud_Shy6182 小时前
Python 数据分析基础入门:《Excel Python:飞速搞定数据分析与处理》学习笔记系列(第八章 使用读写包操作 Excel 文件 上篇)TDengine (老段)2 小时前
MNode 内部机制深度解析 — SDB、事务引擎与 DDL 处理全链路这个DBA有点耶2 小时前
数据库上云 vs 自建:从成本到人力的三维对比与决策框架shizhan_cloud2 小时前
MySQL 索引优化 + 慢查询日志輕華2 小时前
uv工具详解——Python包与项目管理器完全指南