std::stop_callback是C++20协作式取消机制中用于注册一次性清理回调的工具，应在需确保资源安全释放且避免竞态泄漏时使用，配合std::stop_token在stop请求触发且对象未析构时自动执行无异常、轻量级清理操作。
std::stop_callback 是什么，什么时候该用它
std::stop_callback 是 C++20 引入的协作式取消机制中的一环，用于在 std::stop_source 触发停止请求后，自动调用一次你注册的清理函数。它不是“随时可中断线程”的魔法开关，而是配合 std::jthread 或手动管理的 std::stop_source/std::stop_token 使用的回调注册工具。
常见错误现象：直接在线程函数里轮询 stop_token，却忘了在退出前释放资源；或用 std::thread + 手动标志位，导致竞态下资源泄漏。这时 std::stop_callback 就是更安全的选择——只要 stop 请求已发出、且对象仍在作用域内，回调就 guaranteed 被调用（前提是没被 move 构造走）。
- 它只在
stop_source.request_stop()被调用 且 当前std::stop_callback对象未被析构时触发 - 回调函数必须是可调用对象（lambda、函数指针、functor），且不能抛异常（否则 terminate）
- 一个
std::stop_callback实例只执行一次，重复构造多个才能注册多个回调
怎么正确构造和保持 std::stop_callback 生效
关键点在于生命周期管理：回调对象必须比触发停止的 std::stop_source 活得久，且不能被意外 move 或提前析构。
典型错误写法：
void bad_example(std::stop_token stoken) {
std::stop_callback cb(stoken, []{ fclose(my_file); }); // cb 离开作用域即析构 → 回调永远不会执行
}
正确做法是让 std::stop_callback 成为类成员、或局部变量但绑定到足够长的生存期：
- 在
std::jthread的线程函数里，把std::stop_callback声明为函数内局部变量（只要不提前 return，它就能活到函数结束） - 若需跨函数传递，把它作为类的
mutable成员（因为内部会修改状态），并确保类实例寿命覆盖整个任务周期 - 不要用
std::move赋值给另一个std::stop_callback—— 移动后原对象失效，新对象是否注册成功取决于实现，行为不可靠
示例（安全的局部使用）：
void worker_thread(std::stop_token stoken) {
FILE* f = fopen("log.txt", "w");
if (!f) return;
<pre class="brush:php;toolbar:false;">// 正确：cb 在函数末尾才析构，能捕获 stop 请求
std::stop_callback cb(stoken, [f]{
if (f) fclose(f);
});
while (!stoken.stop_requested()) {
// 做工作...
std::this_thread::sleep_for(100ms);
}
// 即使循环被 break 或 return，cb 析构时仍会执行清理}
为什么不能在回调里做耗时或阻塞操作
std::stop_callback 的执行时机由 stop 请求触发，而标准明确要求：回调执行期间，不得阻塞、不得等待其他线程、不得递归请求停止。否则可能卡住整个停止流程，甚至死锁。
常见错误场景：
- 在回调里调用
pthread_join或std::thread::join()—— 被 join 的线程可能正等着本线程发信号 - 调用
std::mutex::lock()且该 mutex 正被其他线程持有（尤其是同一线程已持有时） - 发起网络 I/O 或磁盘 flush（如
fflush()在慢设备上可能阻塞数百毫秒）
实际建议：
- 回调只做轻量、无锁、无等待的清理：关闭文件描述符、释放裸指针内存（用
delete）、置空智能指针（reset()）、标记状态位 - 把重操作移到主线程或专用清理线程中 —— 例如用
std::queue+std::condition_variable把待关闭句柄发给后台线程处理 - 如果必须同步关闭某资源，优先用 RAII（比如自定义
file_handle类，在析构里关文件），而非依赖std::stop_callback
std::stop_callback 和 std::jthread::jthread 的配合要点
std::jthread 自带 std::stop_source，其析构会自动调用 request_stop() 并 join。这是最简安全组合，但仍有细节要注意。
-
std::jthread析构时，先 request_stop，再 join；此时所有还活着的std::stop_callback实例都会被触发 - 如果线程函数里有 long-running 循环，记得在循环条件里检查
stoken.stop_requested()，否则std::jthread析构会卡在 join 上 - 不要在线程函数里把
std::jthread对象本身 move 出去（比如存进容器），会导致 stop_source 生命周期失控
示例：
std::jthread t([](std::stop_token stoken) {
std::vector<int> buffers;
std::stop_callback cleanup(stoken, [&buffers]{
for (auto p : buffers) delete p;
buffers.clear();
});
<pre class="brush:php;toolbar:false;">while (!stoken.stop_requested()) {
buffers.push_back(new int[1024]);
std::this_thread::sleep_for(10ms);
}
}); // t 析构 → request_stop → cleanup 执行 → join
真正容易被忽略的是：回调函数捕获的变量（比如上面的 buffers）必须确保在回调执行时仍然有效。如果用引用捕获，而外部作用域早已结束，就会 UB。所以优先用值捕获，或确保捕获对象的生命周期严格长于 std::jthread。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
