使用boost::asio::post递归投递模拟循环时出现性能下降问题

性能下降的原因 #

• 任务投递的累积开销：每次调用boost::asio::post都会触发线程安全队列的锁操作、条件变量通知等系统级逻辑，700万次投递会把这些微小开销放大，直接导致系统耗时从0.132s暴涨到2.940s，同时用户态也会因为频繁的队列操作增加额外消耗。
• 并行能力完全丧失：原双线程方案中，事件循环线程和io_service线程是并行工作的，CPU利用率接近满负载（用户耗时34.123s几乎等于实际耗时34.282s）。改成单线程后，所有任务只能串行执行，天然就比双线程慢。
• 递归投递的额外成本：每次post都会生成新的lambda对象，涉及内存分配与销毁，再加上io_service的任务调度逻辑，累积下来进一步拉高了用户态耗时。

当前实现是否合理？ #

这个实现能解决线程共享数据的竞态问题，但性能层面极不合理：

• 优势：确实将所有任务收敛到单io_service线程中，彻底避免了多线程共享数据的问题，逻辑上是线程安全的。
• 劣势：完全放弃了并行处理能力，同时引入了大量不必要的任务投递开销，对于百万级别的事件处理场景来说，这种方式的额外成本过高。

更优方案 #

方案1：批量投递任务，减少post调用次数 #

不要处理一个事件就post一次，而是批量处理N个事件后再投递下一批任务，大幅降低post的调用频率，减少同步和调度开销：

void EventProcessor::processBatch(size_t batch_size)
{
    size_t processed = 0;
    while (processed < batch_size && there_is_next_event)
    {
        doProcessEvent();
        processed++;
    }
    if (there_is_next_event)
    {
        boost::asio::post(context, [this, batch_size]{ processBatch(batch_size); });
    }
}

可以根据实际场景调整batch_size（比如1000或10000），平衡单次处理的工作量和post的开销。

方案2：恢复并行能力+隔离数据共享 #

如果想重新利用多核CPU，同时避免共享数据问题，可以：

• 用无锁队列（比如boost::lockfree::queue）存放待处理事件。
• 单独开一个线程只负责读取事件并写入队列，不做处理。
• 启动多个io_service工作线程，每个线程从队列取事件处理，这样既保留并行性，又让处理阶段的线程各自操作独立数据，避免竞态。

方案3：直接在io_service线程中运行连续循环 #

如果必须用单线程io_service，直接把整个事件循环放到io_service的一个任务里，彻底消除多次post的开销：

void EventProcessor::startProcessing()
{
    boost::asio::post(context, [this](){
        while (there_is_next_event)
        {
            doProcessEvent();
        }
    });
}

这种方式和原双线程中的事件循环逻辑一致，只是把循环挪到了io_service线程中，既保证单线程处理的安全性，又没有额外的post开销，性能会接近原双线程中事件循环线程单独处理的水平。

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