tokio::sync::mpsc::channel异常：len()为0但is_empty()返回false

结合你提到的“32次循环后触发”这个关键点，以及tokio mpsc默认缓冲区容量为32的特性，从以下几个方向排查：

1. 并发竞态条件
   若你在多任务/线程环境下分开调用len()和is_empty()，两个调用之间的通道状态可能发生变化：

   • 调用len()时队列确实为空（返回0），但紧接着有发送方成功写入一条消息，此时调用is_empty()就会返回false（队列已非空）。
   • 这种情况属于无同步的并发读取，两个方法的结果无法保证一致性。解决方式是在同一临界区内同时获取两个值，比如用tokio::sync::Mutex包裹Receiver，确保状态读取的原子性。

2. tokio版本与方法逻辑差异
   如果你使用的是较旧版本的tokio（比如0.1.x系列的早期版本），is_empty()的实现可能和len()并非强绑定。比如早期部分版本中，is_empty()会考虑发送端的活跃状态——即使队列为空，只要有未关闭的发送方就返回false，但这种逻辑在1.x稳定版中已修正为is_empty() = len() == 0。建议检查tokio依赖版本，升级到最新稳定版后再测试。

3. 通道非法操作导致的状态混乱（极小概率）
   若你的代码存在非法操作（比如手动unsafe修改通道内部状态、重复drop同一个Receiver），可能导致队列计数逻辑混乱。但这种情况通常会伴随panic或其他异常报错，若你未看到额外错误，该可能性极低。

另外，建议在复现场景中同时打印len()、is_empty()和is_closed()的结果，is_closed()可告知所有发送端是否已关闭，能帮助区分是“队列为空但仍有活跃发送方”还是真的状态不一致。

内容的提问来源于stack exchange，提问作者Daniel O'Leary