Boost Beast WebSocket多线程场景下的规范关闭方法问询

这是异步网络编程里很常见的资源清理场景，结合Boost Beast和Asio的特性，我推荐一套能避免竞态、安全取消异步操作的实现方式：

核心思路 #

利用Boost Asio的strand序列化所有WebSocket操作（读写、关闭），同时结合**取消信号（cancellation_signal）**来终止未完成的异步请求，从根本上避免"取消前刚好启动读取"的竞态问题——因为strand保证同一时间只有一个任务在执行，关闭指令和异步操作不会交叉触发。

具体实现步骤 #

1. 给WebSocket会话绑定strand和取消信号 #

在你的WebSocket会话类（类似官方示例里的session）中，添加strand和取消信号成员，确保所有异步操作都通过strand执行并绑定取消槽：

class websocket_session : public std::enable_shared_from_this<websocket_session>
{
public:
    // 构造函数中初始化strand和ws对象
    explicit websocket_session(boost::asio::io_context& ioc)
        : strand_(boost::asio::make_strand(ioc)),
          ws_(strand_)
    {}

    // ... 其他公开方法（如启动连接、写入数据等） ...

private:
    boost::asio::strand<boost::asio::io_context::executor_type> strand_;
    boost::asio::cancellation_signal cancel_signal_;
    boost::beast::websocket::stream<boost::beast::tcp_stream> ws_;
    boost::beast::flat_buffer buffer_;
    bool is_closed_ = false;

    // 异步读取的回调函数
    void on_read(boost::beast::error_code ec, std::size_t bytes_transferred)
    {
        // 优先检查是否被取消或已进入关闭状态
        if (ec == boost::asio::error::operation_aborted || is_closed_)
        {
            do_close();
            return;
        }

        // ... 正常处理读取到的数据逻辑 ...

        // 继续发起下一次异步读取，绑定strand和取消槽
        ws_.async_read(
            buffer_,
            boost::asio::bind_executor(
                strand_,
                boost::asio::bind_cancellation_slot(
                    cancel_signal_.slot(),
                    std::bind(
                        &websocket_session::on_read,
                        shared_from_this(),
                        std::placeholders::_1,
                        std::placeholders::_2
                    )
                )
            )
        );
    }

    // 统一执行关闭清理逻辑
    void do_close()
    {
        if (is_closed_) return;
        is_closed_ = true;

        // 发送WebSocket关闭帧（如果需要，忽略可能的错误）
        boost::beast::error_code ec;
        ws_.close(boost::beast::websocket::close_code::normal, ec);

        // 关闭底层TCP连接
        ws_.next_layer().close(ec);
    }
};

2. 主线程安全触发关闭 #

主线程绝对不能直接操作WebSocket对象或取消信号，必须通过strand提交关闭任务，确保操作在子线程的strand上下文中执行，避免线程安全问题：

// 假设你持有websocket_session的智能指针
void main_thread_trigger_close(std::shared_ptr<websocket_session> session)
{
    // 通过strand提交关闭任务，保证序列化执行
    boost::asio::post(
        session->strand_,
        [session]() {
            // 触发取消信号，终止所有未完成的异步操作
            session->cancel_signal_.emit(boost::asio::cancellation_type::all);
            // 执行最终的关闭清理
            session->do_close();
        }
    );
}

3. 处理异步操作的取消回调 #

在所有异步读写的handler中，首先检查错误码是否为operation_aborted（取消导致的错误），如果是则直接进入关闭流程，不再发起新的异步请求。这样就能保证一旦触发取消，整个异步操作链会被彻底中断。

为什么能避免竞态？ #

• strand的序列化机制：所有WebSocket相关的操作（包括关闭）都通过strand执行，同一时间只有一个任务在运行。也就是说，当主线程提交的关闭任务被执行时，当前正在运行的异步handler已经完成，不会出现"读取操作刚好在取消前启动"的情况——因为启动下一次async_read的逻辑是在当前handler的末尾，关闭任务会等当前handler执行完才会运行。
• 取消信号的即时性：一旦触发cancel_signal，所有绑定了该slot的未完成异步操作会立即被取消，handler会收到operation_aborted错误，进而终止操作链。

额外注意事项 #

• 确保所有异步操作都绑定strand和取消槽，不要遗漏任何async_read/async_write调用。
• 使用shared_from_this()来保证会话对象在异步操作完成前不会被意外销毁。
• 关闭时如果需要发送关闭帧，要确保在取消异步操作后执行，避免发送操作和取消操作的冲突。

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