C++异步编程实战：从协程到Senders/Receivers的高性能服务器设计 1. 项目概述为什么我们需要重新审视C异步编程如果你是一名C开发者尤其是从事服务器、游戏引擎、高性能计算或者任何对响应时间和吞吐量有要求的领域那么“异步编程”这个词对你来说一定不陌生。它就像一把双刃剑用好了能让你的程序如虎添翼性能飙升用不好则会陷入回调地狱、数据竞争和难以调试的泥潭让代码变成一团乱麻。过去我们处理异步可能依赖于操作系统原生的线程、互斥锁和条件变量或者使用像std::async、std::future这样的标准库工具。但这些方案在面对复杂的依赖关系、取消操作、超时处理和资源管理时往往显得力不从心代码结构也容易变得支离破碎。后来以Boost.Asio以及后来的独立Asio库为代表的基于回调Callback或完成令牌Completion Token的异步I/O库成为了主流它们提供了强大的网络和定时器抽象但业务逻辑依然被分散在各个回调函数中。转折点出现在C20。协程Coroutines的引入为异步编程带来了语法层面的革命。co_await关键字让异步代码可以写得像同步代码一样直观、线性。与此同时标准委员会也在积极推动一个更为宏大的异步编程框架提案Executors和Senders/Receivers模型通常被合称为std::execution。这个模型旨在为C提供一套统一的、类型安全的、可组合的异步操作抽象。所以当看到“C异步编程从入门到精通实战”这个标题时我理解的不仅仅是一系列语法和API的罗列。它背后是一个正在发生深刻变革的领域我们正从“如何实现异步”向“如何优雅、安全、高效地表达异步”演进。本指南的目标就是带你穿越这片正在剧烈变化的技术版图从最基础的异步概念和C20协程入手逐步深入到Asio的实战应用最后触碰前沿的Senders/Receivers模型并通过综合案例让你拥有解决真实世界异步问题的能力。无论你是想优化现有服务还是为新的高性能项目选择技术栈这里的内容都将提供扎实的参考。2. 异步编程核心范式演进从回调到协程再到结构化并发要精通C异步编程绝不能只停留在某个库的API调用上。我们必须理解其背后范式的演变逻辑这决定了我们代码的架构和未来的可维护性。2.1 传统回调与Lambda表达式灵活但易失控这是最原始的模式。Asio早期的典型用法就是如此发起一个异步操作并传入一个回调函数现在常以Lambda表达式形式来处理结果。socket.async_read_some(buffer, [](std::error_code ec, std::size_t length) { if (!ec) { // 处理数据... process_data(buffer, length); // 可能继续发起下一个异步读形成链式回调 socket.async_read_some(buffer, /* 另一个Lambda */); } else { // 处理错误... } });优点极其灵活可以表达任何复杂的流程。致命缺点回调地狱Callback Hell当多个异步操作存在依赖时代码会向右缩进得非常深可读性急剧下降。状态管理困难所有需要在回调间共享的状态如socket、buffer都必须通过捕获列表[]或[]或外部变量来传递容易造成悬垂引用或生命周期管理错误。错误处理分散每个回调都需要单独处理错误难以实现统一的错误传播和资源清理。难以取消和组合实现“超时后取消所有关联操作”或“等待所有并行操作完成”这样的逻辑需要手动维护额外的控制结构代码复杂。2.2 C20协程以同步写法写异步代码C20协程通过co_await运算符将异步操作的“等待”过程在语法上隐藏起来。编译器会将一个协程函数返回类型满足“可等待”要求如asio::awaitable转换为一个状态机在异步操作挂起时保存现场恢复时继续执行。asio::awaitablevoid session(tcp::socket socket) { try { std::arraychar, 1024 data; for (;;) { // 看起来是“阻塞”的读实际上是异步挂起 std::size_t n co_await socket.async_read_some(asio::buffer(data), asio::use_awaitable); // 恢复执行后数据已经就绪 co_await async_process(data, n); // 另一个异步操作 } } catch (const std::exception e) { // 统一的错误处理点 std::cerr Session exception: e.what() \n; } }革命性进步线性逻辑代码顺序就是执行顺序极大提升了可读性和可维护性。自然的状态管理局部变量就是协程状态的一部分生命周期与协程绑定安全且直观。结构化错误处理可以使用try-catch来捕获整个异步链中的异常。易于组合co_await一个返回awaitable的函数天然就是组合。核心概念与实战要点协程帧Coroutine Frame这是理解开销的关键。每次调用协程函数编译器会在堆上除非优化掉分配一个帧用于存储局部变量、挂起点等信息。频繁创建销毁微小协程可能有开销需注意。承诺类型Promise Typeco_await、co_yield、co_return的行为都由协程返回类型关联的“承诺类型”控制。Asio的awaitable就自带了一套承诺类型实现。在实战中除非你要造轮子否则不建议自己从头定义承诺类型直接使用Asio或类似库提供的设施即可。调度器Schedulerco_await挂起后由谁、在哪个线程恢复执行这需要调度器。Asio的io_context就是一个调度器。你需要将协程“提交”co_spawn到某个执行器executor上运行。实操心得协程的“坑”与技巧生命周期陷阱虽然局部变量安全了但通过引用捕获外部变量尤其是在Lambda中启动协程仍需极度小心。确保协程执行期间被引用的对象一定存活。一个常见模式是使用std::shared_ptr来共享所有权。避免在协程中阻塞co_await是“异步等待”而std::this_thread::sleep_for或阻塞I/O是“同步阻塞”。绝对不要在协程函数中使用任何可能阻塞线程的操作这会卡住整个调度线程破坏异步系统的吞吐量。所有耗时操作都应包装成可co_await的形式。理解asio::detachedco_spawn时使用asio::detached作为完成令牌意味着你“放弃”了对这个协程的显式等待。它会在后台运行直到结束。这适用于不需要结果的后台任务但你必须自己处理好异常日志和资源清理否则异常会被默默吞掉。2.3 Senders/Receivers模型类型安全的结构化并发这是C标准提案和libunifex库所倡导的下一代异步模型。其核心思想是将一个异步操作抽象为三个部分Sender发送者描述一个异步操作及其产生的值/错误类型。它本身不执行任何操作只是一个描述符。Receiver接收者一个包含三个回调set_value,set_error,set_done的对象用于接收Sender操作的结果。Scheduler调度器一个可以生成“在某个执行上下文上执行”的Sender的工厂。操作通过管道|运算符和算法如then、let_value、when_all进行组合形成一个更大的Sender最后通过sync_wait或submit给某个执行器来启动。// 伪代码展示概念 auto work schedule_on(io_scheduler) // 在IO线程调度器上安排任务 | then([] { return async_read(socket); }) // 然后异步读 | let_value([](auto data) { // 读成功后处理数据并发起写 return async_write(socket, process(data)); }) | upon_error([](std::error_code ec) { // 任何步骤出错都会到这里 std::cerr Error: ec.message() \n; return just(); // 返回一个空的Sender继续链 }); // 同步等待整个异步链完成仅用于示例实际中可能异步提交 sync_wait(std::move(work));核心优势编译期类型检查整个异步操作的流水线Pipeline在编译期就确定了值类型和错误传播路径。如果类型不匹配编译器会报错将许多运行时错误提前到编译期。声明式与可组合性异步逻辑通过算法组合清晰声明依赖关系一目了然比手动编排的回调或嵌套的协程更易于模块化和测试。分离“描述”与“执行”Sender只描述“做什么”不关心“在哪做”和“怎么做”。这为优化如操作融合、调度优化提供了空间。当前局限与实战考量生态系统不成熟std::execution尚未正式进入C标准预计在C26或之后。libunifex是参考实现但如参考文章所说其工业级成熟度、文档和社区支持远不如Asio。学习曲线陡峭涉及大量的模板元编程、CPO定制点对象概念编译错误信息可能非常冗长晦涩。与协程的整合虽然可以将协程作为Receiver但两者在思维模型上仍有差异。目前更实用的做法是将Senders/Receivers作为底层抽象在其上构建更易用的协程接口这正是Asio正在做的。我的选择建议对于新项目尤其是需要复杂异步流、且团队愿意接受前沿技术的可以开始尝试基于Asio它正在集成Senders支持并关注std::execution进展。对于现有项目或需要最高稳定性和生产力的C20协程 Asio是目前最强大、最实用的组合能解决90%以上的异步编程痛点也是本指南后续实战的重点。3. 基于Asio与协程的实战架构设计理论说再多不如一行代码。让我们设计一个实战项目一个简易的异步TCP游戏服务器。它需要处理多个客户端连接进行低延迟的消息转发并管理一些后台定时任务。我们将采用“单线程异步I/O 协程”的经典高性能架构。3.1 项目结构与核心组件设计async_game_server/ ├── CMakeLists.txt ├── include/ │ ├── server.hpp // 服务器主类 │ ├── session.hpp // 客户端会话类 │ ├── game_room.hpp // 游戏房间逻辑 │ └── message.hpp // 协议消息定义 ├── src/ │ ├── main.cpp │ ├── server.cpp │ ├── session.cpp │ └── game_room.cpp └── third_party/ // 假设放置asio库核心组件职责server类管理asio::io_context监听端口接受新连接并创建session对象。session类代表一个客户端连接。使用协程处理该连接上的读、写、协议解析和业务逻辑。game_room类管理一组会话实现广播、匹配等游戏逻辑。它与session通过弱引用或消息队列交互。asio::io_context整个系统的引擎驱动所有异步操作。我们通常使用一个线程运行它run()。3.2 关键实现协程化的Session与异步生命周期管理session类是核心。我们需要安全地管理TCP socket和读/写缓冲区并优雅地处理连接断开。// session.hpp #pragma once #include asio.hpp #include memory #include queue #include message.hpp class game_room; // 前向声明 class session : public std::enable_shared_from_thissession { public: session(asio::ip::tcp::socket socket, std::weak_ptrgame_room room); ~session(); void start(); // 启动会话协程 void deliver(const game_message msg); // 向客户端发送消息线程安全 asio::ip::tcp::endpoint remote_endpoint() const; private: asio::awaitablevoid reader_loop(); // 读循环协程 asio::awaitablevoid writer_loop(); // 写循环协程 void stop(); // 停止会话 asio::ip::tcp::socket socket_; std::weak_ptrgame_room room_; // 读缓冲区与解析状态 asio::streambuf read_buffer_; // 写队列与线程安全保护 std::queuegame_message write_msgs_; asio::steady_timer write_timer_; // 用于写循环的等待 std::mutex write_queue_mutex_; bool stopped_{false}; };// session.cpp 关键部分 session::session(asio::ip::tcp::socket socket, std::weak_ptrgame_room room) : socket_(std::move(socket)) , room_(room) , write_timer_(socket_.get_executor()) { } void session::start() { // 使用 co_spawn 启动两个并行的协程 // 注意需要确保 session 对象在协程执行期间存活通过 shared_from_this asio::co_spawn(socket_.get_executor(), [self shared_from_this()]() - asio::awaitablevoid { co_await self-reader_loop(); }, asio::detached); // 读循环独立运行 asio::co_spawn(socket_.get_executor(), [self shared_from_this()]() - asio::awaitablevoid { co_await self-writer_loop(); }, asio::detached); } asio::awaitablevoid session::reader_loop() { try { while (!stopped_ socket_.is_open()) { // 异步读取直到遇到消息分隔符例如“\n” std::size_t n co_await asio::async_read_until( socket_, read_buffer_, \n, asio::use_awaitable ); // 从缓冲区中提取一行消息 std::istream is(read_buffer_); std::string line; std::getline(is, line); // 解析并处理消息 auto msg parse_message(line); if (auto room room_.lock()) { co_await room-handle_message(shared_from_this(), std::move(msg)); } } } catch (const std::exception e) { // 读取出错包括连接关闭 std::cerr Reader loop for remote_endpoint() exception: e.what() std::endl; } stop(); // 退出读循环触发会话停止 } asio::awaitablevoid session::writer_loop() { try { while (!stopped_) { // 等待写队列不为空或者超时避免空转 write_timer_.expires_after(std::chrono::seconds(1)); bool has_msg false; { std::lock_guardstd::mutex lock(write_queue_mutex_); has_msg !write_msgs_.empty(); } if (!has_msg) { // 队列为空等待一段时间再检查 asio::error_code ec; co_await write_timer_.async_wait(asio::redirect_error(asio::use_awaitable, ec)); if (ec asio::error::operation_aborted) { // 定时器被取消可能是stop()被调用退出循环 co_return; } continue; } // 取出消息并发送 game_message msg_to_send; { std::lock_guardstd::mutex lock(write_queue_mutex_); msg_to_send std::move(write_msgs_.front()); write_msgs_.pop(); } std::string formatted_msg format_message(msg_to_send); co_await asio::async_write(socket_, asio::buffer(formatted_msg), asio::use_awaitable); } } catch (const std::exception e) { std::cerr Writer loop for remote_endpoint() exception: e.what() std::endl; } // 写循环退出也会触发stop } void session::deliver(const game_message msg) { // 此函数可能被其他线程如游戏逻辑线程调用需要加锁 std::lock_guardstd::mutex lock(write_queue_mutex_); if (stopped_) return; write_msgs_.push(msg); // 可以取消写循环的定时器让其立即处理新消息 write_timer_.cancel_one(); } void session::stop() { if (stopped_.exchange(true)) return; // 防止重复调用 asio::post(socket_.get_executor(), [self shared_from_this()]() { // 在IO线程上执行清理 asio::error_code ec; self-socket_.shutdown(asio::ip::tcp::socket::shutdown_both, ec); self-socket_.close(ec); self-write_timer_.cancel(); if (auto room self-room_.lock()) { room-leave(self); } }); }实战精要为什么这样设计双循环分离读写这是经典模式。读循环专注于接收和解析写循环专注于发送。它们通过一个线程安全的队列write_msgs_通信。这避免了在单个协程中同时处理读写导致的复杂状态管理。shared_from_this与生命周期协程通过Lambda捕获self shared_from_this()来延长session对象的生命周期。确保在协程执行期间session对象不会被意外销毁。stop()函数是生命周期管理的总闸门。写循环的定时器技巧写循环使用一个定时器来等待而不是忙等待或条件变量。当deliver()有新消息时它取消定时器cancel_one使写循环立刻从async_wait中唤醒并发送消息。这比轮询队列高效得多。错误处理集中化reader_loop和writer_loop都将异常捕获在顶层并在异常发生时调用stop()进行统一清理。这保证了连接异常断开时资源能被正确释放并通知game_room移除该会话。3.3 集成游戏逻辑与定时任务game_room需要管理会话并执行游戏逻辑如帧更新、广播。我们可以利用Asio的定时器在io_context中驱动游戏循环。// game_room.cpp 部分实现 asio::awaitablevoid game_room::game_loop() { auto executor co_await asio::this_coro::executor; asio::steady_timer timer(executor); constexpr std::chrono::milliseconds frame_duration(33); // ~30 FPS while (!stopped_) { timer.expires_after(frame_duration); // 1. 执行一帧游戏逻辑 update_game_state(); // 2. 广播状态给所有玩家 auto state_msg get_broadcast_state(); { std::lock_guardstd::mutex lock(sessions_mutex_); for (auto weak_session : sessions_) { if (auto session weak_session.lock()) { session-deliver(state_msg); } } } // 3. 清理已断开的会话 cleanup_dead_sessions(); // 4. 等待下一帧 asio::error_code ec; co_await timer.async_wait(asio::redirect_error(asio::use_awaitable, ec)); if (ec) { // 定时器被取消房间停止 break; } } }关键点游戏循环本身也是一个协程它利用定时器来周期性地执行。所有操作游戏逻辑、广播消息都在同一个io_context线程中完成天然避免了多线程并发访问游戏状态的锁竞争这是单线程异步模型的核心优势之一。对于计算密集的逻辑可以将其包装成asio::post到另一个线程池中执行再通过回调或asio::awaitable将结果传回主循环。4. 高级主题性能调优、调试与生产环境考量一个能跑通的Demo和一個能扛住生产流量的服务之间隔着无数细节。以下是基于我多年踩坑经验总结的关键点。4.1 性能调优从单线程到多线程io_context单线程io_context足以处理数千甚至上万的并发连接取决于业务逻辑的复杂度。但当连接数或CPU计算量进一步增加时我们需要引入多线程。方案一单io_context多线程运行这是最简单的方式。创建多个线程每个线程都调用io_context.run()。asio::io_context ioc; // ... 设置监听器等 std::vectorstd::thread threads; std::size_t thread_pool_size std::thread::hardware_concurrency(); for (std::size_t i 0; i thread_pool_size; i) { threads.emplace_back([ioc] { ioc.run(); }); } // ... 主线程等待 for (auto t : threads) t.join();注意事项线程安全此时io_context上的完成处理程序包括协程恢复可能会在任何线程中执行。你必须确保所有相关的操作都是线程安全的。例如之前session的deliver函数已经用了锁。性能Asio内部使用锁来保护完成队列。在高负载下多个线程争抢同一个io_context的锁可能成为瓶颈。方案二多io_contextIO线程池每个线程拥有自己独立的io_context。这通常能提供更好的扩展性因为消除了中心锁。std::vectorstd::unique_ptrasio::io_context io_contexts; std::vectorasio::executor_work_guardasio::io_context::executor_type work_guards; std::vectorstd::thread threads; for (int i 0; i num_threads; i) { io_contexts.push_back(std::make_uniqueasio::io_context()); work_guards.push_back(asio::make_work_guard(*io_contexts.back())); threads.emplace_back([ctx io_contexts.back().get()] { ctx-run(); }); } // 需要一个负载均衡器来分配新连接给不同的io_context asio::ip::tcp::acceptor acceptor(main_ioc, endpoint); acceptor.async_accept([](error_code ec, tcp::socket socket) { static std::size_t next_io 0; auto target_ioc *io_contexts[next_io % io_contexts.size()]; next_io; // 将socket移动到目标io_context的线程中 auto session std::make_sharedsession_type(std::move(socket), ...); asio::post(target_ioc, [session] { session-start(); }); // 继续接受 acceptor.async_accept(...); });选择建议对于连接间交互少的服务如HTTP API网关多io_context性能更优。对于连接间交互频繁的服务如游戏服务器单io_context多线程编程模型更简单且Asio的锁优化得很好通常不会成为瓶颈建议优先采用此方案。4.2 调试与问题排查让异步代码不再“神秘”异步代码的调试是出了名的难因为调用栈是断裂的。以下是我的工具箱日志日志还是日志在关键路径协程开始/结束、异步操作发起/完成、错误点添加详细的日志并带上连接ID、协程ID如果有、线程ID。使用异步日志库如spdlog避免阻塞I/O线程。Asio的调试处理器在编译时定义ASIO_ENABLE_HANDLER_TRACKING宏Asio会向标准错误输出详细的处理程序跟踪信息显示每个异步操作的关联和生命周期。这在分析复杂的内存或生命周期问题时非常有用。协程状态可视化手动可以为每个重要的协程分配一个唯一ID并在其挂起和恢复时打印日志。这能帮你理清协程的执行流。使用AddressSanitizer和ThreadSanitizer在开发测试阶段务必使用这些工具来检测内存错误和数据竞争。异步编程中在回调或协程间共享数据是竞争的重灾区。超时是必须的为每一个网络操作、甚至重要的内部异步操作设置超时。使用asio::steady_timer与async_wait配合asio::experimental::as_tuple(asio::use_awaitable)来避免异常实现超时逻辑。asio::awaitablebool read_with_timeout(tcp::socket socket, asio::streambuf buf, std::chrono::milliseconds timeout) { auto executor co_await asio::this_coro::executor; asio::steady_timer timer(executor); timer.expires_after(timeout); // 同时等待读操作和定时器 auto [ec_read, ec_timer] co_await ( asio::async_read_until(socket, buf, \n, asio::experimental::as_tuple(asio::use_awaitable)) || timer.async_wait(asio::experimental::as_tuple(asio::use_awaitable)) ); if (ec_timer) { // 定时器先完成说明超时 socket.cancel(); // 取消读操作 co_return false; } // 读操作完成可能成功或出错 co_return !ec_read; }4.3 生产环境加固稳定性与可观测性资源限制文件描述符限制使用setrlimit提高进程可打开的文件描述符数量以支持更多连接。内存限制监控每个连接的缓冲区内存使用。对于长连接服务警惕内存泄漏协程帧的分配和释放是关键观察点。优雅退出实现信号处理如SIGINT, SIGTERM在收到信号后有序地停止接受新连接通知所有会话进行清理等待进行中的操作完成最后再停止io_context。监控与度量连接数当前活跃连接、历史总连接。io_context队列长度可以间接反映系统负载。协程数量如果自己管理协程调度器监控活跃和挂起的协程数。业务指标消息处理延迟、广播频率等。与现有框架集成如果你的项目已在使用其他框架如游戏引擎、Web框架需要设计清晰的边界。通常将asio::io_context作为事件循环集成进去或者将框架的主循环与io_context的poll/run_one结合。5. 从Asio协程到Senders/Receivers的探索虽然当前生产主力是Asio协程但了解Senders/Receivers模型能让你站在更高的视角。Asio自身也在积极集成这一模型从Asio 1.24.0开始实验性支持。你可以尝试用它来重构部分逻辑体验其声明式的魅力。例如用Senders重写之前的读超时逻辑使用Asio的实验性Sender支持#include asio/experimental/as_single.hpp #include asio/experimental/awaitable_operators.hpp #include asio/experimental/concurrent_channel.hpp // 假设有 sender 版本的 async_read_until auto read_op asio::async_read_until(socket, buf, \n, asio::experimental::as_single(asio::deferred)); auto timeout_op asio::steady_timer(executor).async_wait(asio::experimental::as_single(asio::deferred)); // 使用 when_either 创建一个 sender它完成于两个操作中先完成的那一个 auto either_sender asio::experimental::when_either(std::move(read_op), std::move(timeout_op)); // 提交并等待结果 auto [ec, idx] co_await either_sender(asio::use_awaitable); if (idx 1) { // 第二个操作定时器先完成超时 socket.cancel(); // ... 处理超时 } else { // 第一个操作读完成 // ... 处理读取结果 }这种方式将并发和选择逻辑通过算法when_either清晰地表达出来而不是手动组合多个回调或协程。虽然目前生态和文档还不完善但这无疑是未来的方向。6. 常见问题与速查手册在实际开发和运维中你一定会遇到下面这些问题。这里是我整理的速查表。问题现象可能原因排查步骤与解决方案程序CPU占用率100%但吞吐量低1. 在协程或完成处理程序中执行了阻塞操作如文件IO、sleep。2. 存在忙等待循环。1. 检查所有co_await后的函数确保它们都是真正的异步操作。2. 使用性能分析工具如perf定位热点函数。3. 将阻塞操作移到独立的线程池中执行。内存使用量不断增长疑似泄漏1.shared_ptr循环引用导致协程帧无法释放。2. 协程在某个co_await点挂起后永远无法恢复如等待一个永远不会触发的条件。3. 缓冲区如streambuf只读不清理。1. 使用弱引用weak_ptr打破循环引用。2. 为所有异步操作设置超时确保协程最终能被清理。3. 定期检查并consume()已处理数据的缓冲区。连接随机断开或数据错乱1. 多线程访问同一对象如socket、缓冲区未加锁。2. 协程生命周期管理错误对象已销毁但协程仍在运行悬垂引用。3. 协议解析错误导致缓冲区状态混乱。1.确保每个socket的所有操作都在其关联的strand或同一个io_context线程中执行这是黄金法则。2. 使用shared_from_this()并检查stopped_标志。3. 增加协议解析的日志并编写单元测试覆盖边界情况。io_context.run()在还有工作未完成时提前返回1. 所有work对象asio::executor_work_guard都被销毁了。2. 程序调用了io_context.stop()。1. 在需要保持io_context运行的期间持有asio::make_work_guard(io_context)。2. 检查是否有异常导致stop()被意外调用。编译错误提示与协程或Awaitable相关1. 函数返回类型不是有效的Awaitable类型。2. 在非协程函数中使用了co_await。3. 编译器不支持C20协程或相关特性。1. 确认函数返回类型是asio::awaitableT或库定义的类似类型。2. 确保函数体包含co_await、co_return或co_yield之一。3. 检查编译器版本和编译标志-stdc20/std:c20。对于MSVC还需启用/await。最后我想分享一个最深刻的体会异步编程的核心挑战从来不是语法或API而是对程序状态和生命周期的精确掌控。从回调到协程再到Senders技术的演进本质上是为我们提供更强大、更安全的工具来管理这种复杂性。开始时请务必从小处着手充分理解asio::io_context的单线程模型掌握协程的生命周期然后再逐步扩展到多线程和更复杂的模式。当你对“事件循环”、“非阻塞”、“完成处理程序”这些概念有了肌肉记忆后无论是调试线上问题还是设计新的异步架构你都会感到游刃有余。记住好的异步代码应该是清晰、可预测的而不是充满“魔法”和难以追踪的bug。