基于Golang的简单消息队列模拟_使用Channel实现异步处理

这是因channel使用不当导致的死锁：无缓冲channel需收发双方同时就绪，仅生产者写入或仅消费者读取均会阻塞；带缓冲channel才可暂存消息，且需注意关闭时机。

为什么一跑就报 fatal Error: all goroutines are asleep - deadlock

这是裸用 chan 做队列时最典型的错误：goroutine 全卡在 channel 操作上，没人读、没人写，或者节奏没对齐。无缓冲 channel 是同步点，不是队列；带缓冲的才可能“存住”消息。

• 只启动生产者往 messages 写，但没启消费者读 → 生产者阻塞，程序 panic
• 消费者先启动，for range messages 等数据，但生产者还没开始或已结束且未 close(messages) → 消费者永远等下去
• 用 make(chan String)（无缓冲）却想当队列用 → 每次 都要等对面 <code>，根本攒不了消息

解决办法很简单：用带缓冲的 make(chan string, N)，且确保至少一个 goroutine 在读、一个在写，或用 select 加兜底逻辑。

怎么选缓冲大小：10 还是 1000？

缓冲大小不是越大越好，它本质是在「内存占用」和「背压暴露」之间做权衡。

• make(chan string, 10)：适合调试、内部通知类场景；满时立刻暴露消费者处理慢的问题
• make(chan string, 1000)：看似抗压，实则掩盖瓶颈；若消费者持续落后，内存会涨，且无法感知积压恶化
• 真实服务中，建议从 10–100 起步，配合监控看 len(messages)（仅对 buffered channel 有效），再动态调整

别用 len(ch) 判断是否能写——它只是瞬时快照，且并发下不可靠。要用 select + default 或超时来控制行为边界。

立即学习“go语言免费学习笔记（深入）”；

如何安全地发送和接收：别裸写

裸写 messages 或 <code>msg := 在生产环境等于埋雷。必须用 <code>select 控制阻塞行为。

• 发送端加超时（防消费者宕机）：

  select { case messages <- "msg": fmt.Println("ok") case <-time.After(300 * time.Millisecond): fmt.Println("drop") }

• 接收端加 default（防空队列死等）：

  select { case msg := <-messages: handle(msg) default: fmt.Println("no msg now") }

• 关闭 channel 后不能再 send，否则 panic；但可以 continue receive 直到所有已入队消息被取完

记住：close() 是通知“不再有新消息”，不是“立刻停收”。消费者必须用 for range 或循环 + ok 判断来安全退出。

要不要封装成结构体？什么时候加 sync.Mutex？

直接裸用 chan 很快会遇到扩展瓶颈：没法统计长度、没法优雅关闭、没法加日志或重试。封装成结构体是必要一步。

• 把 chan 当私有字段藏起来，暴露 Send() 和 Receive() 方法，统一处理满/空/关闭逻辑
• sync.Mutex 不是用来保护 chan 的——channel 本身并发安全；它是为将来留钩子：比如加 count int 字段统计积压量，这时每次读写都得加锁
• 如果结构体里只有 messages chan Message，那 Send 和 Receive 方法里完全不用锁

真正容易被忽略的是：内存 channel 天然不持久、不跨进程、不支持重试和死信。一旦需要这些，就得切到 Redis 或 Kafka——不是优化，而是换范式。