基于condition_variable的同步异常：定时器触发后线程卡顿排查

核心原因：条件变量与会话类型不匹配，导致Send会话永远无法被唤醒 #

• Send会话的条件变量从未被触发：StartSendSession中等待的是cv_isSend，但定时器的async_wait回调里只调用了cv_isListen.notify_one()，完全没有对cv_isSend进行通知。当会话切换到Send状态时，线程会卡在cv_isSend.wait(lock)处，永远无法继续执行，这就是你看到的卡顿现象。
• 从输出验证问题：第二次循环输出2和Timer finished后没有Send --> Listen的打印，说明此时程序进入了StartSendSession，但因为cv_isSend从未被唤醒，线程一直阻塞在wait调用上。

次要问题：条件变量使用未遵循"谓词+wait"规范 #

代码中直接调用cv_isListen.wait(lock)和cv_isSend.wait(lock)，没有结合isTimerFinish等状态作为谓词，存在虚假唤醒的风险。即使修复了notify的问题，也可能因为系统虚假唤醒导致逻辑异常。正确的用法示例：

// Listen会话的正确wait写法
cv_isListen.wait(lock, [this](){ return isTimerFinish; });

额外逻辑漏洞：定时器重置与会话的时序问题 #

每次循环中设置定时器后直接进入会话等待，但如果前一次的定时器回调还未执行，expires_after会重置定时器，可能导致前一次的notify被延迟或丢弃。不过这不是当前卡顿的直接原因，但会影响时序稳定性。

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