C++如何使用Boost.Asio实现异步TCP服务端-C++-PHP中文网

async_accept一接受连接就立刻断开，大概率是tcp_connection对象生命周期失控；boost.asio异步操作不持有对象所有权，必须用shared_ptr确保其在回调执行期间有效。

c++如何使用boost.asio实现异步tcp服务端

常见现象是客户端连上后瞬间被关闭，async_accept 回调刚执行完连接就没了——大概率是 tcp_connection 对象生命周期失控。Boost.Asio 的异步操作不持有对象所有权，你必须确保 tcp_connection 实例在回调执行期间始终有效。

典型错误写法：tcp_connection conn(io_context, socket) 放在 accept_handler 栈上，回调返回即析构，底层 socket 被关闭。

正确做法：用 std::shared_ptr<tcp_connection></tcp_connection> 管理连接对象，在 async_accept 成功后 make_shared 并传入回调
务必在 tcp_connection 构造时调用 socket_.non_blocking(false)，避免后续 async_read 因 socket 处于非阻塞模式而立即失败
不要在 tcp_connection 的构造函数里直接调用 async_read，应在 start() 这类显式方法中触发，确保对象完全构造完毕

Boost.Asio 没有内置的“按行读取”或“按分隔符读取”的异步原语，async_read_until 是最接近的方案，但它依赖 dynamic_buffer 和预分配缓冲区，容易因缓冲区不足导致截断或死锁。

推荐组合使用 async_read + 自定义解析逻辑，尤其适合处理自定义协议（如 "LEN:123|DATA:..."）：

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

用 boost::asio::streambuf 作为接收缓冲区，每次 async_read 尽可能填满它
在回调中调用 streambuf.data() 获取 boost::asio::const_buffer，再用 boost::asio::buffer_cast<const char>(...)</const> 转为原始指针进行扫描
若未找到分隔符，保留已读数据（streambuf.commit(n)），再次 async_read；若找到，用 streambuf.consume(n) 清除已处理部分
注意：不要对 streambuf 频繁 commit/consume 小段数据，会引发内存碎片；建议单次读取至少 1KB 起

当用多线程跑 io_context::run() 时，从外部线程向 asio 投递任务，post 和 dispatch 行为差异极大，错用会导致竞态或意外同步阻塞。

post 总是把操作放入队列，由任意一个正在 run() 的线程异步执行，安全且推荐用于绝大多数场景
dispatch 会优先尝试在**当前线程**执行（如果当前线程正在该 io_context 的 run() 中），否则退化为 post；但若你在工作线程里误调用 dispatch 到主线程的 io_context，而主线程并未运行 run()，它就变成同步调用，卡住工作线程
跨线程发通知（如连接关闭日志、统计上报）一律用 post，别图省事用 dispatch
若需确保回调在某个固定线程（如专用 IO 线程）执行，可给该线程的 io_context 绑定 strand，再用 strand.post(...)

error_code 995 即 ERROR_OPERATION_ABORTED，不是网络错误，而是操作被主动取消。常见于以下情况：

在 async_accept 回调还没执行完时，又对同一个 acceptor 调用了 close() 或 cancel()
服务器 shutdown 流程中，先 acceptor.close()，再等待所有连接结束，但没等 async_accept 回调返回就强行退出
使用 boost::asio::steady_timer 做超时控制时，timer 过期回调里调用了 acceptor.cancel()，但此时 accept 操作其实已完成，只是回调尚未调度——cancel 仍会触发 995