Rust tokio异步Mutex场景下handle_write内match分支无法执行

核心原因 #

你遇到的问题本质是锁申请时机差+跨await长持有锁+串行调用逻辑共同导致的handle_write中spawn的任务永远拿不到stream锁，stream.lock().await永久挂起，后续match分支自然永远无法执行，完全匹配你观察到的现象：

• spawn内第一行打印在申请锁之前，不需要等待锁，只要任务被调度就能执行，因此可以看到输出
• 执行到stream.lock().await时任务进入锁等待状态，但永远抢不到锁，后续两个分支代码都不会被调度执行
• handle_read中的同一段逻辑可以正常执行，是因为handle_read是在当前串行流程中直接申请锁，没有spawn的调度延迟，永远比spawn出去的写任务先拿到锁

具体触发流程：

1. 你的主循环是串行阻塞式调用：必须等timeout(handle_read())执行完（无论是成功还是超时返回），才会跑handle_queue，再跑handle_write
2. handle_read拿到stream锁之后，直接跨await执行读操作——如果对端暂时没有数据，读操作会一直挂起，直到handle_read的timeout触发，handle_read的future被drop，锁的RAII guard才会被释放
3. 执行到handle_write时，你用tokio::spawn把写逻辑提交到运行时任务队列，handle_write本身立刻返回，主循环马上进入下一轮，第一时间调用handle_read再次申请stream锁
4. 而spawn出去的写任务需要等运行时调度，执行到stream.lock().await的时间永远晚于下一轮handle_read申请锁的时间，锁永远被handle_read抢先拿走
5. 上述流程无限循环，写任务永远在等锁，永远到不了match分支

快速验证方法 #

在handle_read拿到锁之后、执行读操作之前，加一行tokio::time::sleep(tokio::time::Duration::from_millis(10)).await;，给spawn的写任务留足调度时间，让它先进入锁等待队列，你会发现handle_write里的match分支打印可以正常输出。

修复方案 #

• 禁止持有tokio::sync::Mutex锁跨await执行长时间IO操作：这是tokio官方明确不推荐的写法，拿到锁后只做必要的内存操作（比如从队列取数据、拿到stream的可变引用），立刻释放锁，再做IO
• 去掉handle_write里多余的tokio::spawn：handle_write本身就是async函数，直接在函数体内写拿锁、写数据的逻辑即可，不要把逻辑扔到独立spawn任务里导致调度时序不可控
• 最优方案：直接用TcpStream::split()把TCP流拆成独立的读、写半部分，读半部分专属读任务，写半部分专属写任务，两个半部分可以安全并发操作，完全不需要加锁，从根源上避免锁竞争
• 不要在单循环里串行等读超时再处理写：把读、写逻辑分别spawn成独立的循环任务，让运行时独立调度两个任务，不会出现读逻辑长期占住资源导致写逻辑饿死的情况

内容的提问来源于stack exchange，提问作者Sergio Ivanuzzo