最稳方案是用 std::chrono + condition_variable::wait_for 实现时间兜底，配合原子限流与共享锁的竞态防护，区分软/硬超时并避免互相干扰。
超时强制触发用 std::chrono + 定时器线程最稳
动态批处理服务里，不能等队列攒够才发，必须有“时间兜底”——比如最多等 100ms，不管有没有凑满就提交。直接用 std::this_thread::sleep_for 轮询会浪费 CPU，也难精确控制；用 std::condition_variable::wait_for 是更合理的选择。
关键点是：每次 push 新请求后，都要重置等待逻辑；超时唤醒后必须检查队列是否非空（避免虚假唤醒导致空提交）。
- 别用
std::alarm或信号，C++ 多线程下不可靠 - 定时器线程建议只负责唤醒，不直接调用业务 handler，避免阻塞影响下一轮计时
- 如果用
boost::asio::steady_timer，注意绑定的executor是否和 handler 同线程上下文
队列长度限制必须在入队前做原子判断
单纯在 push() 里加锁后检查 size，再丢弃或报错，容易被高并发打穿——两个线程同时通过检查、同时 push，结果超限。必须用原子计数 + CAS 或带容量的无锁队列（如 moodycamel::ConcurrentQueue 的 try_enqueue）。
常见错误是把限流逻辑放在业务层（比如 handler 里 throw exception），这已经晚了：请求已进队、资源已分配、甚至可能触发了下游预占。
立即学习“C++免费学习笔记（深入）”；
- 推荐在 producer 端封装一层
try_enqueue_with_backpressure()，返回false表示被拒，由调用方决定降级（如返回 429 或走直通路径） - 拒绝时最好记录
queue_size和rejected_count指标，否则压测时根本看不出是限流还是下游慢 - 不要用
std::queue配std::mutex做简单计数——size() 不是原子的，多线程下读到的值可能已过期
std::condition_variable::wait_for 和队列限长要共享同一把锁
超时等待和入队/出队操作必须共用同一个 std::mutex，否则会出现竞态：比如线程 A 刚检查完队列为空、正准备 wait，线程 B 迅速 push 并 notify_one，但 A 还没开始 wait 就错过了信号，导致死等。
典型结构是：所有对队列状态的读写（size、empty、push、pop、notify）都包裹在同一个 mutex 临界区内；wait_for 的 predicate 必须是“队列非空 || 超时”，且 predicate 内部不持有锁（wait 会自动释放并重获）。
- 别把 notify 写在 unlock 之后——必须在锁内 notify，否则 notify 可能早于 wait 执行
- 避免在 predicate 里调用耗时函数（如日志、网络请求），它会在每次唤醒时重复执行
- 如果使用
wait_until，注意系统时钟跳变会影响精度，优先用steady_clock
生产环境必须区分“软超时”和“硬超时”
所谓软超时（如 100ms）是为吞吐优化的启发式触发；硬超时（如 5s）是防止单批卡死的保底机制——比如某次 batch 提交后，回调迟迟不返回，整个队列就僵住了。硬超时必须独立于批处理逻辑，用 watchdog 线程监控每一批的生命周期。
- 软超时由条件变量驱动，硬超时要用单独的
std::thread+std::atomic<bool></bool>标记批次状态 - 硬超时触发时，不能简单 kill 线程（C++ 不支持安全线程中止），而应设置 cancel flag，让 handler 主动退出并清理资源
- 队列长度限制的阈值建议可配置，但上线前必须压测验证：设成 1024 未必比 512 更好，cache line false sharing 可能反而降低吞吐
