工业化C++:2.std::function、Lambda 与回调机制

写在前面本篇文章为个人 C 学习与工业实践的整合复习笔记上一期我们探讨了智能指针与生命周期管理。内容涵盖可调用对象包装器std::function()、Lambda 闭包、成员函数绑定与回调解耦设计。如有错误欢迎各位大佬指正在上一篇文章中我们认识了对象的生命周期与安全销毁。但当我们的底层网络库例如TcpConnection能够稳定且优雅地运行后一个新的架构难题浮出水面底层模块与上层业务之间究竟该如何“交谈”一、引入先来看一个常见的服务器开发场景。我们正在实现一个 TCP Server。随着客户端不断建立连接Server 需要维护这些连接并持续接收来自不同客户端的数据。TCP 提供的是字节流因此 Server 从 socket 中读取到数据之后还需要按照我们约定好的应用层协议进行解析最终还原出一条完整的消息。整个过程大致可以理解成客户端 ↓ TCP 连接 ↓ Server 读取字节流 ↓ 协议解析 ↓ 得到完整消息例如在一个多人在线游戏服务器中同一时刻可能收到这样的请求玩家 A登录 玩家 B发送聊天消息 玩家 C查询背包 玩家 D切换场景 玩家 E提交任务Server 成功解析出这些消息以后要怎么对这些消息对应的业务进行处理呢Server总不能什么都自己做可以把 Server 想象成一家饭店门口的接待员。接待员负责迎接客人、确认客人的需求并把客人安排到合适的位置。但客人真正进入饭店以后还会产生各种需求....如果门口的接待员在接待完一个客人以后还跑进去负责点菜、端菜、结账那么只要某一个客人的业务稍微耗时后面刚到饭店的客人就只能在门口等待。服务器也是类似的。网络线程需要持续处理新连接到来 数据可读 读取 socket 解析协议 连接断开 ……假设 Server 收到一条登录消息以后直接开始查询 MySQL、读取 Redis、进行身份验证。如果数据库操作耗时 100ms那么这段时间网络线程就会被业务逻辑占用其他已经到来的网络事件无法及时得到处理。因此我们希望把职责分开网络部分 ↓ 负责连接、收消息、解析消息、分发消息 业务部分 ↓ 负责登录、聊天、背包、任务、场景等具体逻辑这样一来负责网络通信的线程就可以尽快回到网络事件处理中。那么谁来像饭店里的服务员一样真正去执行这些具体业务呢——worker线程。之所以叫worker就是因为它承担的是“干活”的角色。主线程或者网络线程更像门口的接待员负责接收连接、读取消息、解析请求然后尽快把任务分发出去而真正耗时的业务逻辑例如登录认证、数据库查询、聊天广播、背包处理就交给 worker 去执行。这样做有一个直接好处网络线程不会因为某个业务执行得太久而一直被占用。它可以迅速回到自己的工作上继续处理新的连接和新的消息。而多个 worker 一起工作时就可以并发处理不同任务主线程 / 网络线程 ↓ Task Queue ↙ ↓ ↘ worker1 worker2 worker3 ↓ ↓ ↓ 登录 聊天 背包这些 worker 通常不会每来一个任务就临时创建一个新线程因为频繁创建和销毁线程本身也有开销。所以我们会提前创建一批 worker并统一放在线程池里让它们不断从任务队列中取任务执行。最终我们得到了一套更加清晰的职责划分二、callbalck为了加深对回调的理解为下文做铺垫。我们先从最普通的函数调用开始void Hello() { cout hello; } int main() { Hello(); }这里是我们自己主动调用Hello()main ↓ Hello()程序执行到Hello();主线程就进入Hello()执行代码。这种调用关系比较直接函数什么时候执行、执行哪个函数都是我们在代码里提前写好的。现在来到包含线程的工作场景。假设我们想创建一个 worker 线程。操作系统可以帮我们创建一条新的执行流但是新的问题随之出现这个 worker 创建出来以后到底要执行什么最简单的情况下我们可以在创建线程的时候直接告诉 pthreadpthread_create( tid, nullptr, Routine, // 新线程启动后执行的函数 bq );也就是说pthread 负责把 worker 创建出来而Routine负责描述这个 worker 启动以后应该执行什么。main线程 │ │ pthread_create ▼ 创建 worker │ ▼ 执行 Routine所以在最基础的 pthread 使用中routine就是线程的入口函数。它已经体现出了一个重要思想执行某段代码的人与决定“具体执行哪段代码”的人可以分离但如果继续往实际工程里走只做到这里是不够的。实际工程一般都会用到线程池其中的线程都是提前创建好的.例如我们的线程池里已经有ThreadPool ├── worker1 ├── worker2 ├── worker3 └── worker4这些 worker 创建出来以后会一直存在while (true) { // 等待任务 // 获取任务 // 执行任务 }我们没法预知这些worker线程将来要执行什么——这些任务都是程序运行起来以后动态产生的。如果每个 worker 都被硬编码成只能执行某一种业务那么线程就会和具体业务绑定线程池也难以统一调度各种动态产生的任务。真正理想的 worker 应该只负责一件事有任务就拿任务 ↓ 拿到什么任务 ↓ 就执行什么任务也就是void Worker() { while (true) { // 获取一个任务 task(); } }问题就从“worker 线程应该硬编码执行哪个函数”变成了“我们能不能把一个以后才确定的‘行为函数’像‘数据变量’一样保存下来等需要的时刻再交给 worker 去执行”回调的核心思想是把一段“将来需要执行的行为”注册或传递给另一个模块由该模块在特定事件发生时反过来调用它。这样事件的产生者只负责“什么时候触发”而不需要知道“具体该执行什么业务逻辑”。在传统逻辑里是我们主动去调用函数而在回调模式下是我们提前把“将来要干的事”注册或投递出去由 Worker 线程在合适的时机回调Call back”它。那么在 C 中我们究竟该用什么类型的“变量”来存放这些被打包好的行为如果我们想用一个统一的任务队列例如 std::queueTask把这些待执行的任务装起来这个 Task 到底应该声明为什么类型如果只用 C 语言留下的函数指针面对现代 C 极为丰富的可调用对象很快就会捉襟见肘。这就引出了我们今天的第一位重量级主角——std::function。三、std::function万能的可调用对象包装器1.std::function到底是什么在 C11 之前如果我们想把一个“函数”当成变量传给别人只能使用 C 语言留下的函数指针。但 C 拥有极度丰富的“可调用实体Callable Objects”包括普通函数与函数指针仿函数Functor即重载了operator()的类对象类的成员函数与静态成员函数Lambda 表达式匿名函数这些可调用实体虽然“调用方式”看起来差不多但它们的底层类型完全不同。例如一个捕获了变量的 Lambda 和一个普通函数指针在编译器眼里是两个截然不同的类我们根本没办法把它们塞进同一个std::vector或队列里。为了解决这个问题C11 在functional头文件中引入了std::function。它的本质是一个基于类型擦除Type Erasure技术实现的多态函数包装器Polymorphic Function Wrapper但是这个太复杂了我们别这么记。简单来说它就像一个通用函数盒子它消除了底层各种可调用实体的具体类型差异只关心这个函数的“签名”入参类型与返回值类型。如果你写过 C 语言的线程如pthread_create或网络回调你一定对void* args不陌生// C 语言的做法用 void* 预留一个万能的数据位置 void* Routine(void* args) { // 强制类型转换把 void* 还原成具体的结构体 MyContext* ctx (MyContext*)args; // ... 执行逻辑 }传统的void* args机制本质上就是在不确定未来会传什么数据时提前预留一个万能的‘类型占位符’把具体的上下文数据塞进去。如果只从“把上下文交给未来执行逻辑”这个角度看函数指针 void*与std::function Lambda有一些相似之处。预留上下文位置void* args只能预留数据的位置而std::function配合 Lambda 的闭包能把数据上下文变量和代码函数本身同时装进这个盒子里。绝对更安全相比void*std::function能利用 C 类型系统检查调用接口的兼容性避免大量手动类型转换。知识点打通void* argsvsstd::function进化对比:【C 风格】 函数指针 void* context ├── 函数指针描述执行什么代码 └── void*携带上下文数据需要自己恢复类型 ↓ 相似思想的现代 C 表达 【现代 C】 std::function Lambda ├── Lambda封装代码 上下文状态 └── std::function统一不同可调用对象的类型2. 类型别名实战using task_t std::functionvoid();在真实的工业级工程如线程池、事件循环中为了避免代码里到处充斥着冗长的std::functionvoid()模板语法我们通常会使用using声明给它定义一个极具表达力的类型别名// 定义类型别名task_t 代表任何“无参、无返回值”的可执行任务单元 using task_t std::functionvoid();这里的task_t不再只是一个抽象的模板类而是成为了我们项目中一个标准的抽象数据类型ADT——它代表了一个“可以被延迟执行的操作”。我们可以看一个直观的代码示例感受一下task_t是如何把各种各样的“异构对象”统一包装起来的#include iostream #include functional #include vector using task_t std::functionvoid(); // 1. 普通函数 void normalFunction() { std::cout [任务 1] 普通函数被执行\n; } // 2. 仿函数 (Functor) struct FunctorTask { void operator()() const { std::cout [任务 2] 仿函数被执行\n; } }; int main() { // 创建一个统一的任务队列/容器 std::vectortask_t taskQueue; // A. 放入普通函数 taskQueue.push_back(normalFunction); // B. 放入仿函数对象 taskQueue.push_back(FunctorTask()); // C. 放入 Lambda 表达式 taskQueue.push_back([]() { std::cout [任务 3] Lambda 闭包被执行\n; }); // 遍历队列统一调用Worker 线程完全不需要知道每个任务底层到底是什么类型 for (const auto task : taskQueue) { if (task) { // 重载了 operator bool可直接判断盒子内是否有可执行函数 task(); } } return 0; }第一次看到这段代码时很多人包括我自己都会很纳闷函数指针、结构体、Lambda 类型明明全都不一样凭什么能塞进同一个vector里答案就是std::function本身是一个类。当我们把函数或 Lambda 丢给它时它利用模板构造函数把这些异构的对象全部统一包装成了std::function类的对象。而它内部重载了operator()所以我们可以像调用普通函数一样写task()3.std::function的核心应用场景理解了std::function的本质后我们在工业级 C 开发中主要在以下三个场景使用它异步任务队列与线程池Task Queue Thread Pool正如前文所讨论的线程池中的任务队列std::queuetask_t只需要存放task_t。工作线程从队列头部弹出任务并直接执行task()。工作线程彻底脱离了具体业务它不需要关心这个任务到底是处理网络请求、刷盘写入日志还是计算游戏 AI。事件驱动与回调注册Event-Driven Callbacks在网络库或 GUI 框架中底层模块只负责监听事件如 Socket 读写、按钮点击。底层通过暴露setMessageCallback(task_t cb)接口让上层业务把处理逻辑“注入”进来。当事件触发时底层直接调用该std::function实现了完美的模块解耦。替代复杂的策略模式Strategy Pattern传统的 C 策略模式需要定义抽象基类并编写派生类子类继承层次复杂。而利用std::function我们可以直接将具体算法/行为包装成函数对象传递大大简化了代码的设计与维护成本。四、Lambda 与闭包既然已经有了std::functionvoid() task;这个可以保存“无参、无返回值任务”的容器接下来的问题就是我们要怎么把具体的业务逻辑装进这个容器里如果在 C 语言时代我们只能传入一个普通的函数指针。但函数指针有一个致命的缺陷它很难携带“状态State”。想象一下我们的网络服务器场景当接待员主线程收到客户端fd 42发来的字符串move forward时他需要把这个具体的任务交给工作线程。 如果任务容器的标准是void()无参我们怎么把fd和move forward传进去呢为了解决这个“既要统一接口无参又要携带上下文”的矛盾现代 C 给出了最优雅的解法Lambda 表达式与闭包机制。1. 什么是 Lambda 表达式严格来说Lambda 表达式会生成一个匿名的闭包类型执行 Lambda 表达式得到的对象称为闭包对象。我们平常所说的“Lambda 捕获变量”实际上就是这些状态被保存进了闭包对象内部简单来说Lambda 就是一个“随用随写”的匿名函数。它的基本语法长这样[捕获列表](参数列表) { 函数体 }其中最让人混淆的就是[...]和(...)我们可以用一句话区分它们的本质捕获列表[...]是“创建时打包进背包的上下文数据”定义 Lambda 时就确定了。参数列表(...)是“以后真正调用时才传进来的动态数据”触发执行时才传入。用代码直观地来理解int clientFd 1001; // 外部局部变量 // 定义 Lambda auto task [clientFd](const std::string requestData) { // ^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^ // 捕获列表 参数列表 // 创建时就定死了 调用时才由外面传进来 std::cout 处理客户端 [ clientFd ] 发来的数据: requestData std::endl; }; // 触发调用此时传参 task(LOGIN_PACKET); // LOGIN_PACKET 填入的是 (参数列表)最基础的用法它就像一个普通的函数auto sayHello []() { cout Hello Worker! endl; }; // 调用 sayHello();我们可以直接把这个 Lambda 赋值给我们的任务容器std::functionvoid() task []() { cout Hello Worker! endl; };2. 闭包Closure上面这个简单的sayHello并不能满足我们的工程需求。真正的业务逻辑总是需要依赖当时的上下文数据的。闭包的概念就是除了函数内部的代码它还能把定义这个函数时周边的“环境变量”一起打包带走。在 Lambda 中这个打包动作通过[捕获列表]来实现。回到我们刚才的场景主线程拿到了clientFd和message我们可以这样写int clientFd 42; std::string message move forward; // 将上下文数据通过 [] (按值捕获) 打包进 Lambda std::functionvoid() task [clientFd, message]() { // 这里是 Lambda 的内部它可以直接使用外面捕获进来的变量 cout 处理客户端: clientFd 的指令: message endl; // GameLogic::processMove(clientFd, message); };这里的精妙之处在于对于外面的task容器来说它的类型依然是严丝合缝的std::functionvoid()不需要传任何参数。 但实际上这个task内部自带了一个“隐形背包”即闭包里面装好了clientFd和message。3. 形成闭环解耦底层与业务有了 Lambda 和std::function我们最初设计的 Boss-Worker 线程池模型就彻底打通了在主线程接待员中// 1. 产生上下文数据 int fd 42; string data attack; // 2. 用 Lambda 打包业务逻辑和上下文塞进 function 容器 std::functionvoid() task [fd, data]() { GameLogic::handle(fd, data); }; // 3. 将通用任务投递到线程池的任务队列中 threadPool.push(task);在 Worker 线程服务员中void Worker() { while (true) { // 1. 从队列获取一个任务 (类型为 std::functionvoid()) auto task getTaskFromQueue(); // 2. 执行 task(); } }通过这种方式Worker 线程的代码变得极度纯粹。它不需要知道什么是TcpConnection不需要知道什么是玩家指令甚至不需要知道网络编程的存在。它只知道一件事“从队列里拿出一个void()类型的函数然后调用它”。std::function配合 Lambda 的闭包机制像一层完美的绝缘体成功抹平了所有业务任务的差异实现了网络底层模块与上层游戏业务的彻底解耦。五、实践std::function Lambda使用以及解耦设计1.为何std::function与Lambda的搭配被广泛使用既然可以直接写auto task [](){ ... };为什么工业界项目里经常都是std::functionvoid() task [](){ ... };① Lambda 的痛点匿名且类型独一无二C 中每一个 Lambda 表达式都会产生自己独立的闭包类型。即使两个 Lambda 的代码看起来完全一样只要来自两个不同的 Lambda 表达式它们的类型通常也是不同的。auto f1 [](){ std::cout hello; }; auto f2 [](){ std::cout hello; };f1和f2是不同的即在静态强类型语言 C 里你没办法把两个“类型不一样”的东西装进同一个接口或容器里这就导致了如果你的线程池队列想存一堆任务std::queueTask但是因为不能把两个不一样的东西存到同一个接口里——std::queuedecltype(f1)可以保存f1的闭包类型却无法直接保存f2这种不同闭包类型。可是在真实场景下我们的任务队列本来就需要容纳各种各样不同的代码行为。这些任务在类型上千差万别因为各自打包了不同的局部变量但在功能语义上却高度统一——它们都是‘一段不需要入参、执行完就拉倒的闭包逻辑’即void()签名。如果类型系统不允许把它们装进同一个容器线程池的通用设计就完全无从谈起。②std::function的救场类型擦除Type Erasure正是为了打破这种“功能语义高度统一但底层类型各自为政”的僵局C11 提出了std::function。如果把各个独特的 Lambda 比作尺寸各异的产品那么std::function就是一个标准化规格的通用包装盒。它的核心威力在于类型擦除Type Erasure它不再关心你底层到底是用__lambda_17x、__lambda_92y还是普通函数指针或仿函数它只关心一件事——这个对象的“调用签名”Signature是什么只要你的 Lambda 满足“没有入参、没有返回值”std::functionvoid()就能抹平它们底层的类型差异统统擦除并包装成同一个类型std::functionvoid()。这时线程池的任务队列难题迎刃而解// 1. 统一定义任务类型就是一个“无参无返回值”的可调用包装器 using Task std::functionvoid(); // 2. 任务队列终于可以声明了 std::queueTask taskQueue; int userId 1001; std::string sqlStr UPDATE user SET score 100; // 3. 两个完全不同的 Lambda捕获了完全不同的上下文底层类型完全不同 auto loginTask [userId]() { std::cout Log user: userId; }; auto dbTask [sqlStr]() { std::cout Exec SQL: sqlStr; }; // 4. 靠着 std::function 的类型擦除它们全都能顺利塞进同一个 queue taskQueue.push(loginTask); taskQueue.push(dbTask);③ 黄金搭档的终极分工读到这里std::function与 Lambda 为什么会被合称为“黄金搭档”就很清晰了Lambda负责“创造行为”随用随写自由打包上下文解决“带着数据去执行”的问题灵活、随性。std::function负责“类型统一”抹平类型差异给出一个通用的接口类型解决“存进容器、作为参数传递”的问题规整、统一。2. 成员函数为什么不能像普通函数一样直接调用在实际项目中业务逻辑通常不会全部写成普通函数而是属于某个对象class GameServer { public: void handleMessage(int fd, const std::string message) { // 处理游戏业务 } };对于普通函数void handle(int fd, const std::string message);我们可以直接保存它std::functionvoid(int, const std::string) callback handle;但非静态成员函数有所不同GameServer::handleMessage它本身并不能独立完成调用因为成员函数执行时还需要知道到底是哪个 GameServer 对象在调用它它还隐含依赖一个this对象。因此我们需要把“成员函数”和“对象”绑定到一起。最常见的做法就是使用 LambdaGameServer server; std::functionvoid(int, const std::string) callback [server](int fd, const std::string message) { server.handleMessage(fd, message); };这里正好可以和前面学习过的 Lambda 捕获列表联系起来。先看代码GameServer server; std::functionvoid(int, const std::string) callback [server](int fd, const std::string message) { server.handleMessage(fd, message); };我们把这个 Lambda 拆开来看[server](int fd, const std::string message)这里其实包含两类完全不同的数据来源。前面的[server]是 Lambda 的捕获列表。后面的(int fd, const std::string message)是 Lambda 的参数列表。可以继续套用前面总结过的理解[] 捕获列表 ↓ Lambda 创建时从周围环境中带走什么 () 参数列表 ↓ Lambda 将来被调用时外界再传进来什么在这个例子里server已经存在于 Lambda 外部GameServer server;而 Lambda 内部又需要调用server.handleMessage(fd, message);因此 Lambda 必须想办法获得这个server对象。于是我们写[server]意思就是按引用捕获外面的server对象。因此 Lambda 内部使用的server实际上就是外部那个原来的server。可以把它理解成Lambda 创建时 外部环境 │ ├── GameServer server │ ▼ [server] │ ▼ Lambda 保存对 server 的引用等将来执行callback(42, LOGIN);此时42 LOGIN才会分别进入int fd const std::string message最终执行server.handleMessage(fd, message);如果代码本身就在GameServer成员函数内部也经常会看到messageCallback_ [this](int fd, const std::string message) { this-handleMessage(fd, message); };此时 Lambda 闭包保存了this于是原本必须依赖对象才能执行的成员函数就被包装成了一个统一的可调用对象。除此之外C 还提供了std::bindusing namespace std::placeholders; auto callback std::bind( GameServer::handleMessage, server, _1, _2 );其中GameServer::handleMessage表示成员函数server表示未来通过哪个对象调用_1 _2表示真正触发 callback 时再传入的第一个、第二个参数。不过在现代 C 项目中std::bind的使用已经明显减少。对于大多数回调和成员函数绑定场景Lambda 通常更加直观auto callback [server](int fd, const std::string message) { server.handleMessage(fd, message); };相比std::bind中的_1、_2这类占位符Lambda 可以直接看到参数名称、捕获对象以及最终调用逻辑可读性更好也更容易维护。因此本文后续示例主要采用 Lambda。std::bind作为 C11 中重要的函数适配工具了解它的用途和基本写法即可。3. 回到 TcpConnection底层究竟如何与业务层解耦现在终于可以回到文章开头的问题TcpConnection 收到消息之后应该怎么通知上层业务如果直接在TcpConnection中写GameLogic::handleMessage(message);那么底层网络类就必须知道GameLogic的存在。这样一来TcpConnection ↓ 强依赖 GameLogic将来如果业务层发生变化网络层代码也可能跟着修改。更合理的设计是让TcpConnection只保存一个回调class TcpConnection { public: using MessageCallback std::functionvoid(const std::string); void setMessageCallback(MessageCallback cb) { messageCallback_ std::move(cb); } private: MessageCallback messageCallback_; };上层业务负责把具体行为注册进来connection.setMessageCallback( [this](const std::string message) { this-handleMessage(message); } );而TcpConnection收到完整消息以后只需要if (messageCallback_) { messageCallback_(message); }注意此时TcpConnection根本不知道handleMessage() GameServer 玩家 聊天 背包 场景这些东西是什么。它只知道我收到消息了。 有人提前给了我一个 callback。 现在调用它。于是调用关系从原来的TcpConnection ↓ 直接调用 GameServer变成GameServer │ │ 注册 callback ▼ TcpConnection │ │ 消息到达 ▼ 调用 callback │ ▼ GameServer::handleMessage()这里发生了一个非常重要的变化底层模块只负责定义“什么时候通知”上层模块负责决定“通知以后做什么”。这就是回调在网络库中的核心价值。TcpConnection不需要依赖具体业务线程池也不需要了解具体任务。双方只依赖一个统一的可调用接口std::function...最终std::function、Lambda 与回调机制共同形成了一层稳定的抽象边界。