系列导航：面试索引 · 代码评审与 Agentic 研发

系统编程的证明要覆盖所有权、线程间发布、最后使用点和失败清理。 性能判断随后追踪分配、调度与硬件局部性，解释优化省下的成本是否转移到了其他线程或后续请求。

本文基础语义以 C++20/23 为讨论基线；C++26 部分区分已进入工作草案的方向、提案版本和工具链实现，不能由 -std=c++2c 推断全部可用。LLVM 的 C++26 状态页明确区分库实现进度，并提示未发布草案的特性可能变化。本文链接的标准条款镜像是滚动工作草案，定位以条款名为准，出现的新接口不应倒推成 C++20 已有能力。

一、对象模型的第一道关：地址存在，不等于对象仍然有效

1. 对象生命周期：内存池复用后，旧指针还能不能读？

强答要点：先分开存储期（Storage Duration）、对象生命周期（Object Lifetime）、指针有效性和业务代次。内存池保留的是存储；某个对象的初始化完成和析构开始决定另一组边界；批次编号则属于业务身份。这三种边界不能由地址相同替代。 一般对象的生命周期开始要求获得大小与对齐合适的存储，并完成相应初始化，联合体与隐式生命周期类型等另有规则。类对象的生命周期在析构调用开始时结束，而存储可能稍后才释放。见工作草案 basic.life。

 1#include <cstddef>
 2#include <memory>
 3#include <string>
 4
 5struct Cell { std::string value; };
 6
 7void rebuild() {
 8    alignas(Cell) std::byte storage[sizeof(Cell)];
 9    auto* first = std::construct_at(
10        reinterpret_cast<Cell*>(storage), Cell{"batch-1"});
11    std::destroy_at(first);
12    auto* second = std::construct_at(
13        reinterpret_cast<Cell*>(storage), Cell{"batch-2"});
14    // 使用 second；是否可以用 first，要另查透明可替换条件。
15    std::destroy_at(second);
16}

这个例子证明“释放对象”和“释放存储”可以分开；它没有证明并发读者可以越过重建时刻。透明可替换（Transparent Replaceability）满足条件时，旧指针可自动指向新对象；条件不满足时需要按具体规则重新取得指针，std::launder 也不能让已经结束的生命周期复活。更稳妥的接口直接返回新构造结果，并禁止外部保留跨批次借用。

含 std::string 或锁的对象不能直接用字节复制代替正常复制。可平凡复制类型规则允许相应对象表示复制，也不保证自指针和批次身份仍符合业务不变量。

追问：内存池只调用 free，不调用析构，会丢什么？答成员拥有的资源；回收原始字节不会替你执行对象协议；同址重建后读者为什么不能继续读？答必须先证明读者退出或持有有效保护，否则可能与析构、重建并发冲突。

差答：“内存没有释放，所以对象还在”“强转以后就是目标类型”“加 launder 可以解决悬空”。

2. 虚函数与 ABI：为什么 sizeof 题回答完还不够？

强答要点：对象布局要同时注明架构、编译器和应用二进制接口（Application Binary Interface，ABI）。虚表（Virtual Table）与虚表指针（Virtual Table Pointer）是常用实现机制，不能当成语言强制规定的固定字段。继承布局、对齐、编译选项和 ABI 都可能影响大小。 Itanium C++ ABI 的数据布局与虚表章节规定了采用该 ABI 时的布局规则，包含次级虚表、调整量和构造期间的虚表；“每个对象只有一根虚指针”不足以解释多重继承。这里引用的是 ABI 规则，不是全部平台的共同承诺。

通过普通基类指针删除派生对象时，非虚基类析构通常导致未定义行为（Undefined Behavior，UB），不能只描述成“少调一次析构”。若接口允许这种删除，就提供公开虚析构；若禁止，则可以采用受保护的非虚析构并让实际所有者按具体类型销毁。这里不讨论特殊的 destroying delete 设计。

插件新增虚函数即使在某套 ABI 下看似只追加表项，也不能直接宣布兼容：旧插件的表长度、调用方使用的索引、内联代码和对象构造方可能不一致。需要支持长期二进制兼容时，显式版本号、能力查询或稳定的 C 接口更容易形成可验证契约。

追问：为什么不能把含虚函数对象直接写盘？布局与指针值依赖进程和工具链，应序列化稳定字段而不是对象表示；热循环虚调用慢在哪里？可能是间接分支、难以内联或数据布局；先看生成代码与采样，不能把所有成本归到一次查表。

差答：“64 位就是八字节”“所有基类都必须虚析构”“模板零成本”。

3. RAII 与失败路径：析构成功不代表提交成功

强答要点：资源获取即初始化（Resource Acquisition Is Initialization，RAII）把资源生命周期绑定到一个明确的所有者，使构造后的对象始终满足不变量（Invariant），析构完成不抛异常的清理。获取失败可以抛异常，也可以由工厂返回 std::expected<Resource, Error>；选哪种取决于项目错误模型，不能构造一个未标记的半有效对象。

C++ Core Guidelines 的 R.1、C.35、C.36 与 CP.52分别讨论资源管理、基类析构、析构失败和跨挂起持锁问题。这些是工程指南，不能替代具体系统的持久性或线程安全证明。

consume(std::unique_ptr<Batch>) 表达所有权转移；若内部仅保存 batch.get() 就返回，异步消费者仍会悬空。应沿队列与回调追踪所有者。

需要向调用者报告的动作应有显式接口，例如 commit()、flush()、finish()；析构只做兜底清理。理由是析构通常无法可靠回传提交失败，栈展开期间再抛异常还可能终止进程。RAII 证明的是离开作用域时执行清理，不是磁盘写入、远端提交或设备任务已经成功。

查询取消也应区分“请求停止”和“全部工作已经结束”。停止提交新任务后，还必须等待已发布的工作收敛，再释放其依赖对象；进程被强制终止时不保证运行 C++ 析构。跨挂起点持有线程互斥锁还可能在另一线程恢复后解锁，违反锁的线程归属要求。

追问：构造函数中第二个资源获取失败，谁释放第一个？已完成构造的成员会析构；应先用成员包装器接管资源；析构中的关闭失败怎么办？设计显式可报告的结束操作，析构清理只记录或忽略可接受错误，不能假装提交成功。

差答：“全部改智能指针就安全”“析构里做一次提交即可”“取消后直接释放”。

二、所有权进入接口：移动、借用和泛型如何形成约束

4. 移动语义：为什么 std::move 可能触发拷贝，甚至让代码变慢？

强答要点：std::move 只改变表达式的值类别，使其可参与相应重载；具体移动、拷贝或报错由重载和类型能力决定。const T 通常不能绑定普通 T&& 移动构造，因此对常量调用 move 仍可能拷贝。命名的右值引用变量本身是左值表达式。

返回值优化（Return Value Optimization，RVO）与命名返回值优化（Named Return Value Optimization，NRVO）不是同一个保证。C++17 的特定纯右值初始化场景不需要中间移动；返回命名局部对象的 NRVO 仍不是一概强制。不能通过“返回大对象用了移动”解释所有高效返回。

移动的成本也取决于资源布局：短字符串可能复制内联字节，分配器不兼容的容器移动赋值可能逐元素迁移，自引用结构可能需要修复内部指针。应该回答调用哪个重载、是否分配、是否逐元素处理，而不是把移动等同于三次指针赋值。

追问：return std::move(local) 有何风险？可能妨碍 NRVO；先判断返回规则，不以显式 move 作为优化证据；为什么完美转发不能都写 move？转发引用（Forwarding Reference）的调用方可能传左值，应按推导结果使用 std::forward<T> 保留值类别。

差答：“有 && 就一定是转发引用”“移动后不能碰”“emplace_back 永远优于 push_back”。

5. 智能指针与视图：三个线程安全问题不能合并回答

强答要点：分开控制块、智能指针句柄和被管理对象。不同 shared_ptr 句柄共享控制块时，所有权计数有并发保证；对同一非原子句柄并发读写需要同步；对象内部字段是否可并发访问是第三个独立问题。 共享所有权与删除器等契约见 util.smartptr.shared。std::atomic<std::shared_ptr<T>> 可以用于并发发布句柄，但它不保证 T 的内部操作安全，也不承诺无锁实现。

 1#include <atomic>
 2#include <memory>
 3
 4struct Snapshot { int version; };
 5std::atomic<std::shared_ptr<const Snapshot>> current;
 6
 7void publish() {
 8    current.store(std::make_shared<const Snapshot>(Snapshot{7}),
 9                  std::memory_order_release);
10}
11
12int read_version() {
13    auto owned = current.load(std::memory_order_acquire);
14    return owned ? owned->version : -1;
15}

读者持有局部所有者，因此发布新版本不会销毁它正在访问的旧版本。这里还依赖快照发布后不再变动；const 接口不能阻止其他可写别名，应在构造和发布流程中消除这样的别名。该示例没有证明更新吞吐、回收时延或原子共享指针的锁自由性。

借用视图应携带可审计的有效期。std::span 是连续区间视图，std::string_view 是字符视图，它们都不拥有底层数据；把视图复制进队列并不会复制所有者。可以让队列元素同时拥有缓冲，或使用明确的批次租约，但必须证明租约覆盖消费和取消清理。

追问：为什么 use_count() == 1 不能用来证明无并发访问？它只是瞬时所有权观测，不约束裸指针和随后的句柄变化；shared_ptr 按值传参有什么语义？表达需要保留共享所有权；仅同步借用可用引用或指针，但不能把异步延寿需求优化掉。

差答：“计数原子所以对象线程安全”“const shared_ptr<T>& 保证 T 只读”“weak_ptr 完全没有计数成本”。

6. 模板与 concepts：编译通过能证明哪些事情？

强答要点：模板把类型和常量差异推到编译期；概念约束（Concepts）参与候选筛选和重载排序，让接口要求可表达。它们能检查表达式、返回类型和部分静态性质，却不能自动证明关联律、确定性、线程安全或业务空值语义。

requires(A a, const A b) { a.merge(b); } 只验证调用形式；空实现也能通过。若算法要求“分区后合并等价于顺序处理”，就需要写清语义契约并测试不同分区、合并顺序和边界值。浮点加法在通常机器算术下不满足数学上的精确关联律，不能由接口名称推导可任意重排。 约束的满足、规范化与偏序规则见 temp.constr。约束包含关系不是任意数学定理证明；复用命名概念与复制看似相同的布尔表达式，可能产生不同的原子约束身份，影响重载选择。

把类型、空值模式、排序模式和指令集全部作为模板维度，会按组合数放大实例化。只对证据明确的热路径做静态专门化，在外层用运行时分派约束代码体积，通常更容易控制编译时间、链接时间和指令缓存占用；这里是设计判断，不是普适性能结论。

容器引用有效性也须按具体操作核对：vector.modifiers 区分重分配、插入位置和删除；扩容倍数不属于固定语言契约。

追问：concept 比替换失败非错误（Substitution Failure Is Not An Error，SFINAE）改善什么？主要是显式表达约束与诊断，不能凭此保证生成代码更快；为什么两个重载都满足约束还会歧义？说明偏序与约束身份，再检查是否通过同一个命名概念建立包含关系。

差答：“concept 是运行时接口”“模板自动向量化”“编译器验证了 merge 的数学性质”。

三、并发证明必须覆盖发布、修改和回收

7. 内存模型：release/acquire 到底连接了哪两段代码？

强答要点：先找冲突访问，再建立先行发生（Happens-before）关系。原子变量上的修改顺序、不同操作之间的同步关系和其他普通对象的访问是三个层面；“CPU 会刷新缓存”不能替代语言层面的证明。

 1#include <atomic>
 2#include <cassert>
 3
 4int payload = 0;
 5std::atomic<bool> ready{false};
 6
 7void producer() {                 // 整个实验仅调用一次。
 8    payload = 42;
 9    ready.store(true, std::memory_order_release);
10}
11
12void consumer() {
13    if (ready.load(std::memory_order_acquire)) {
14        assert(payload == 42);
15    }
16}

如果获取操作读到了对应释放操作发布的值，就形成同步关系，连接发布前写入与获取后读取。若把标志的两端都改为宽松内存序（Relaxed Ordering），对标志本身仍是原子访问，但不再建立这里所需的跨对象同步；普通 payload 的冲突访问可能形成数据竞争（Data Race），导致未定义行为。依据见 intro.races 和 atomics.order。

这个证明依赖“一次发布后不再写 payload”。生产者第二轮直接覆盖数据，消费者可能仍在第一轮读取；布尔标志无法表达槽位是否已归还。正确循环队列还要证明消费者读取完成后，生产者才可以复用槽位，通常需要反向的发布关系或代次协议。

追问：把 payload 也改成原子就行吗？可以消除其数据竞争，但不自动建立“看见 ready 必须看见指定版本 payload”的跨对象契约；硬件缓存一致性是否足够？一致性约束缓存行或位置的可见行为，不能替代 C++ 抽象机对跨位置同步的要求。

差答：“volatile 防重排，所以可同步”“release 立即刷回主存”“任何 acquire 都会读到最新值”。

8. CAS 与锁：原子操作组合起来，也可能丢更新

强答要点：原子加载和原子存储各自不可分割，不代表两者组成的读改写（Read-Modify-Write，RMW）不可分割。计数应使用 fetch_add，有条件的状态迁移才考虑比较交换（Compare-and-Swap，CAS），多字段不变量仍可能更适合互斥锁。

 1#include <atomic>
 2
 3class TeachingSpinLock {
 4    std::atomic<bool> held_{false};
 5public:
 6    void lock() noexcept {
 7        bool expected = false;
 8        while (!held_.compare_exchange_weak(
 9            expected, true,
10            std::memory_order_acquire,
11            std::memory_order_relaxed)) {
12            expected = false;
13        }
14    }
15    void unlock() noexcept {
16        held_.store(false, std::memory_order_release);
17    }
18};

成功必须执行 false → true；失败会改写 expected，重试前恢复为 false，弱 CAS 还允许伪失败。获取 acquire、释放 release 连接临界区。atomic::wait/notify 等待值变化，A→B→A 可能被错过；必须观察每次事件时需序号，见 atomics.wait。

这个教学锁不适合作为默认生产锁：所有等待者反复执行 RMW，竞争同一缓存行；线程被抢占或 CPU 配额不足时，其他线程仍会忙等。可以讨论先读后尝试、处理器暂停指令、退避、排队锁或 atomic::wait，但每一步都要重新分析唤醒、饥饿和停机行为。

追问：弱 CAS 失败是不是说明别人推进了？不一定，可能伪失败，不能把这个结论直接用于进度证明；原子是否必定无锁？不是，需核查目标类型与平台的 is_lock_free() 或 is_always_lock_free。

差答：“原子一定比锁快”“CAS 循环就是无等待”“加超时就不会死锁”。

9. 无锁与 ABA：比较的是地址，回收的是对象

强答要点：分开线性化（Linearizability）、进度保证和安全内存回收（Safe Memory Reclamation）。节点摘除后立即 delete 仍可能与读者解引用并发；版本号不能延长对象存活期。CAS 成功可以是逻辑操作的线性化点，但读者可能在 CAS 前已经读取旧节点；把节点从结构里摘除，并不代表所有潜在访问者都退出了。

1初始：head -> A -> B -> C
2T1：读取 head=A，并已保存 A.next=B，然后暂停
3T2：弹出 A，再弹出 B，把 A 重新压回，令 A.next=C
4T1：仅比较 head 是否为 A，CAS(A, B) 成功
5结果：把已经不属于当前栈的 B 错误放回 head

危险指针（Hazard Pointer）用于延迟回收仍可能被读者访问的节点，C++26 相关接口与动机见 P2530R3。这不是让原子指针自动拥有对象；保护、校验与退役仍需遵循具体库协议。

常见的回收选择有不同成本归属：危险指针让读者显式保护节点并重新校验源指针；基于纪元的回收（Epoch-based Reclamation，EBR）让读者进入受保护区间，推迟到旧读者退出才回收；读复制更新（Read-Copy-Update，RCU）则围绕读侧临界区和宽限期建立回收协议。这里比较的是机制，不声明它们是标准库中完全等价的接口。

选型首先看最慢读者是否有上界。纪元读者长期停顿可能积压大量退役节点；危险指针需要保护记录、扫描和重试；版本标签存在回绕、表示宽度与双宽 CAS 支持问题。回收方案决定了延迟和内存上限，不能只比较读侧指令数。

追问：线性化点在哪里？逐一指出 push、pop 成功和空栈返回的判定点，不只给成功 CAS 一个答案；保护指针为什么要再读一次 head？保护发布前节点可能已经被移除；必须确认保护对象仍与源一致后再解引用。

差答：“CAS 成功所以一定安全”“双宽 CAS 解决全部问题”“指针读到后马上加引用就好”。

10. 无锁队列的选型：进度保证不能由名字推出

强答要点：先固定参与者、容量、满队列行为、元素生命周期与关闭语义，再讨论算法。无锁（Lock-free）要求系统总体持续推进；无等待（Wait-free）要求每个参与操作在有界自身步骤内完成；无阻塞命名或“使用 atomic”本身都不是这些保证。

在固定容量单生产者单消费者（Single Producer Single Consumer，SPSC）环上，生产者写槽位后发布写游标，消费者获取写游标后读槽位；消费者完成读取后发布读游标，生产者获取它再复用槽位。两个方向都需要证明，不能只画生产者到消费者的一条边。

1生产者：构造 slot[i] → 发布 write
2                              ↓ 消费者观察该发布
3消费者：读取并结束使用 slot[i] → 发布 read
4                              ↓ 生产者观察该发布
5生产者：下一轮才可重建 slot[i]

有界容量使内存上限更清楚，但队列满时必须背压（Backpressure）、拒绝或由上层处理。生产者预留槽位后暂停，可能阻挡按顺序消费；某些声称“无锁”的有界多生产者多消费者（Multiple Producer Multiple Consumer，MPMC）算法因此不能满足严格锁自由定义。候选人应说明自己选用算法的实际进度属性。

追问：无锁为何不保证低尾延迟？某个线程仍可能长期输掉竞争；总体推进与个体公平不同；malloc 在入队路径上，会影响什么？它可能阻塞，也可能使算法宣称的端到端进度保证失效。

差答：“MPMC 通用，直接用它”“无锁不会阻塞，所以没有停顿”“吞吐高就该替换”。

四、内存预算与硬件局部性：性能成本由谁承担

11. jemalloc 与 mimalloc：分配器优化先解释 RSS 为什么没降

强答要点：建立分层账本：业务存活字节、分配器实际分配字节、活跃页、映射和驻留页；再检查线程缓存、尺寸分级、跨线程释放、空闲页保留与操作系统记账。free 结束对象分配的可用性，不承诺立即减少进程常驻集大小（Resident Set Size，RSS）；RSS 也不是堆存活对象的同义词。

jemalloc 官方手册描述了 arena、线程缓存、尺寸类别、衰减与统计接口，例如 stats.allocated、stats.active、stats.resident 和 stats.retained。这些指标口径不同；其中 resident 是分配器统计，也不能直接当成操作系统对整个进程的 RSS。读取统计还需按手册刷新 epoch，并确认构建启用了相关能力。

mimalloc v3.0.1描述空闲链表分片、跨线程释放与页面管理；早期 v3 的实验状态不代表所有 v3 发布，作者基准也不能直接推广到数据库负载。

更大的缓存可能降低锁与系统调用频率，也可能在大量工作线程上放大保留内存。更积极归还页面可能压低驻留量，却增加下轮缺页和清零成本。应把空闲后内存曲线与恢复负载时的延迟一起看，否则只是把成本从当前时刻移到下一轮查询。

mallopt 的 mmap 阈值可动态变化；mallinfo2 没有 mmap_threshold 成员。不能用固定 128 KiB 二分法或不存在的字段解释实际分配路径。

追问：为什么归还空闲页不能消除所有碎片？同一页还有存活对象时，通用原生指针分配器不能随意搬迁这些对象；设置更多 arena 能解决什么？可能减竞争，也可能增加分散与保留；需结合线程数、尺寸分布和实际绑定验证。

差答：“jemalloc 没碎片”“mimalloc 在所有场景更快”“malloc_trim 可以整理全部存活对象”。

12. arena 与批次内存：批量释放如何跨过异步边界？

强答要点：区域分配（Arena Allocation）与多态内存资源（Polymorphic Memory Resource，PMR）适合共享生命周期的一组对象；将逐对象释放成本移到区域重置，但要求所有借用者已经退出。资源对象、容器和容器元素的析构顺序必须明确，单调内存资源（Monotonic Buffer Resource）释放存储并不代替执行其中业务对象的析构。

例如 pmr::vector<int> values{&arena} 必须先于 arena 析构；异步回调若保留 values.data()，还需批次所有者覆盖消费期。提前 arena.release() 会使随后访问失效。

区域方案能减少释放动作和元数据成本，也可能让一小段慢输出拖住整个大批次；拆分区域可以缩短保留时间，却增加区域数量和管理成本。对于有非平凡析构的对象，必须安排析构调用或证明可以不构造这种对象。

追问：pmr::vector<std::string> 的字符串缓冲也用 arena 吗？不自动如此；元素类型与分配器传播规则决定嵌套分配路径；跨资源移动一定转移缓冲吗？不能这样保证，资源不兼容时可能逐元素处理，要核对构造和赋值的具体操作。

差答：“有 arena 就不需要析构”“PMR 自动覆盖所有子分配”“查询返回就可以 reset”。

13. cache、false sharing 与 NUMA：线程越多为什么越慢？

强答要点：缓存行（Cache Line）是常见一致性粒度。伪共享（False Sharing）指线程修改不同逻辑变量，却竞争同一缓存行；真实共享是多个线程争同一逻辑状态。填充只能针对前者，不能解决所有线程反复更新一个全局计数器的问题。

Linux v6.12 的 perf c2c 文档提供缓存行共享分析入口。相关事件受硬件支持和采样方式限制；缓存到缓存传输或修改态命中等证据，只能定位候选共享位置，仍要映射到字段与访问者才能区分真共享和伪共享。

非一致内存访问（Non-Uniform Memory Access，NUMA）要同时考虑线程在哪运行、物理页在哪分配以及数据被谁访问。首次触页（First Touch）解释的是一定策略下实际页分配的常见行为，不是 malloc 返回地址时一定绑定到调用线程的承诺；共享页、预触页、迁移和内存策略都会改变结果。 Linux NUMA 内存策略文档说明默认、本地、绑定和交错策略，以及策略与 cpuset 限制的关系。仅绑定 CPU 不会自动修复已经位于另一节点的数据；策略也不能越过允许节点集合。

追问：用了 relaxed 为何仍有竞争？它削弱排序约束，不取消原子 RMW 对同一缓存行的所有权竞争；线程绑核后变慢说明什么？可能失去负载均衡、受拓扑或配额限制；需同时查页分布与线程运行状态。

差答：“每个字段后加 64 字节”“MESI 保证程序没有竞态”“NUMA 一律 interleave”。

五、协程把控制流写直，却把生命周期问题留给运行时

14. C++20 协程：挂起以后，谁拥有协程帧，谁有权恢复？

强答要点：C++20 协程（Coroutine）提供无栈协程转换机制，编译器把跨挂起点存活的状态组织进协程帧（Coroutine Frame），由承诺对象（Promise Object）和等待器（Awaiter）协议控制行为。它没有内置通用调度器、网络轮询器和完整取消协议。 语言转换中的参数副本、promise、初始挂起、最终挂起与异常处理规则见 dcl.fct.def.coroutine。帧可能动态分配，也可能满足条件后被优化消除；不能保证每次调用都分配，也不能保证一定零分配。

1调用 → 建立帧和 promise → initial_suspend
2     → 执行函数体 → await_ready
3                     ├─ 就绪：继续
4                     └─ 未就绪：await_suspend 注册恢复路径
5     → await_resume 获取结果 → return_value / return_void
6     → final_suspend → 由协议指定的所有者销毁帧

图中的销毁策略不是统一固定：若最终挂起保留帧，任务对象需要承担销毁；若设计为完成时自行销毁，就不能再让外部持有者无条件 destroy()。coroutine_handle 是操作句柄，不天然拥有帧；对已销毁帧使用句柄或同时恢复同一协程，都需要被协议排除。

审查一个异步等待器，应该按“注册完成 → 完成可能立即发生 → 取消同时发生 → 运行时关闭”逐项推演。await_suspend 把句柄交给其他线程后，对方可能立即恢复并使等待器失效；发布后再访问等待器成员，不能假设它仍存活。把完成与取消串行化、或设定一个唯一完成者，是运行时必须证明的状态迁移。

追问：co_await 会自动切线程吗？不一定，是否挂起、由谁恢复和在哪恢复由等待器及调度器决定；取消后能直接 destroy 吗？只有证明底层操作和回调都不会再访问帧，且没有并发恢复，才可以销毁。

差答：“协程自动多核并行”“handle.destroy() 就是取消”“RAII 保证回调不悬空”。

15. 从数据库调度到 AI runtime：完成事件必须覆盖真实使用期

强答要点：对每一类资源定义“最后一次可能访问”的完成条件。数据库输入缓冲可能被解码或输出任务继续持有；设备提交接口返回也可能只说明工作已经入队。主机所有权结束与设备完成事件不是同一个时刻。

这里是跨岗位设计练习，不声称某个 vLLM 版本采用此实现。缓冲释放前，必须确认所有使用者都已完成访问，或接口已完成复制、转移所有权；不能仅凭提交函数返回判断。以 CUDA 12.6 的同步行为文档为例，内核启动相对主机异步，而内存复制的同步行为取决于方向、内存类型和具体接口，不能仅凭 Async 名称判断。

1请求接纳 → 取得预算 → 构建输入 → 提交底层任务
2                               ↓
3取消请求 → 停止新增派生任务   等待真实完成或安全撤销
4                               ↓
5                    汇合回调 → 归还预算与输入缓冲

追问：请求超时后还能不能回传结果？由接口契约决定，但结果不能被交给已经销毁的接收对象；底层无法取消怎么办？逻辑取消后保留必要资源直到完成，限制在途规模，并把这部分占用计入预算。

差答：“协程析构就会停止设备任务”“客户端断开就不用记内存”“换语言可以消除异步资源问题”。

六、性能剖析：先解释时间去了哪里，再决定改什么

16. perf 与火焰图：宽度、等待和尾延迟分别说明什么？

强答要点：把墙钟时间（Wall-clock Time）、运行中时间（On-CPU Time）、离开 CPU 的时间（Off-CPU Time）和可运行却未被调度的等待分开。线程 CPU 总时间可以因并行而大于一次请求耗时，不能把所有线程样本直接相加当成请求关键路径。

Linux v6.12 的 perf record 文档描述采样事件和调用链采集方式。栈回溯要匹配实际二进制，保留符号，并按构建情况选择帧指针或 DWARF 调试信息；高采样频率与更复杂回溯都会改变观测开销。

1# 以下为实验命令模板，不是本文已经执行的生产采样。
2# PID 替换为目标进程号；事件、权限和线程覆盖范围先查本机版本。
3perf stat -p PID \
4  -e task-clock,cycles,instructions,cache-misses,context-switches -- sleep 30
5perf record -F 99 -g --call-graph dwarf -p PID -- sleep 30
6perf report

火焰图（Flame Graph）作者的说明将横向宽度解释为所聚合样本的权重，普通火焰图横轴不是时间顺序。CPU 图中宽函数可能是被频繁调用，也可能是单次昂贵；离 CPU 图则按相应等待数据解释，不应混用。

Off-CPU Analysis用阻塞与等待分析补足 CPU 采样。线程的离 CPU 区间还需结合调度状态区分阻塞与可运行等待；阻塞栈说明在哪里睡下，不自动指出是谁持锁或哪个远端请求导致等待。

CPU 不高时，先检查是否锁等待、输入等待、背压、CPU 配额节流或单线程串行阶段；CPU 高但热点分散时，检查重复工作、全局共享计数、内存带宽与吞吐退化。低每周期指令数（Instructions Per Cycle，IPC）只是现象，可能来自等待、分支或执行资源限制，不能直接断言“内存瓶颈”。

追问：CPU 火焰图能否看网络等待？通常看不到阻塞期间消耗的时间，需要等待和请求时间线证据；锁函数很宽就应该换无锁吗？先识别持锁者、锁保护的不变量与竞争来源，可能应缩小临界区或分片。

差答：“火焰图越平越好”“最宽函数就是最慢请求”“cache-misses 多就加预取”。

17. 性能与正确性验证：怎样推翻自己的第一个解释？

强答要点：先保留可比较的构建、参数、输入与时间线，拆成可证伪的假设。例如“跨线程释放竞争增加 CPU 时间”应预测相关栈和事件下降；“归还更积极导致恢复期缺页”则应预测空闲后恢复阶段的缺页与延迟一起上升。不同预测对应不同采集方法。

只看平均吞吐无法排除队列积压和资源转移。固定到达负载、逐级加压，同时记录成功率、拒绝率、队列长度和尾延迟；若新方案靠拒绝更多请求换吞吐，必须把这种语义变化显式纳入比较。这个实验设计不包含任何已测量的提升数值。

地址消毒器（AddressSanitizer，ASan）可以发现多类越界与释放后使用，线程消毒器（ThreadSanitizer，TSan）用于检测数据竞争，能力与限制分别见 ASan 文档和 TSan 文档。两类检测通常使用不同构建，不能把插桩构建的性能直接与生产构建对比。

追问：微基准还有什么价值？隔离机制与发现上限，但要把线程、尺寸、缓存和生命周期条件带回真实负载验证；复现不了线上长尾怎么办？收集慢窗口上下文和对照条件，逐步复现负载阶段，不把“没复现”写成“已经排除”。

差答：“跑一遍压测更快就合”“TSan 通过所以无锁算法正确”“线上环境复杂，结论只能靠经验”。

七、2024–2026 的增量：按工程问题选择标准特性

18. C++23：新接口能减少哪些错误，不能替你决定什么？

强答要点：从具体错误和接口成本出发，而不是罗列语法。先区分编译器前端支持、标准库支持、部署机器兼容与 ABI；升级编译开关只是其中一项。选一两个局部模块验证，保留与旧代码可互操作的边界。

libc++ 的 C++23 状态页列出 expected、mdspan、move_only_function、generator 等库能力及实现进度；语言特性另查 Clang 状态页。下表描述能力的用途，不宣称所有部署工具链已完整支持。

追问：用了 expected 就完全不会抛异常吗？不是，值类型的构造、分配或其他操作仍可能抛，取决于具体操作契约；怎样防止库支持不完整？使用特性测试宏（Feature-test Macro）、实际编译链接探针和目标平台测试，避免只比较编译器版本号。

差答：“C++23 都是语法糖”“打开标准开关就都能用”“generator 就是异步流”。

19. C++26：execution、回收、SIMD 和反射怎样进入答题？

强答要点：按四个工程问题准备：异步组合如何表达完成与停止；节点回收由谁承担；数据并行如何表达；元数据生成如何减少重复。用固定提案解释机制，用实现状态确认可用性，不把历史提案代码当成最终 API。

2024 年 P2300R10：std::execution以发送者／接收者（Sender/Receiver）模型组合异步操作，涉及值、错误、停止完成及操作状态。协程负责可挂起控制流，execution 讨论异步组合协议；两者并非互相替代，也不意味着标准库附送所有设备后端。

对运行时岗位，值得追问的是连接后操作状态由谁持有、启动后如何完成、停止请求如何到达底层、调度器切换是否改变线程归属。停止完成信号不是强制终止正在执行的任意操作；接入真实网络或设备仍要处理无法取消的工作和迟到事件。

C++26 的危险指针方向与前文节点回收相连，见 P2530R3。2024 年 P1928R15讨论标准数据并行类型，即单指令多数据（Single Instruction Multiple Data，SIMD）抽象。提案提供表达能力，不保证任意算子自动更快，也不保证浮点归约与原顺序逐位一致。

静态反射（Static Reflection）可以围绕类型与成员元数据生成代码，机制参考 2025 年 P2996R13：Reflection for C++26。这是编译期反射方向，不能直接理解为运行时扫描任意对象，也不能由成员枚举结果推导稳定的持久化格式。

追问：知道 execution 名称后应该讲什么？选一个有取消的异步操作，画状态所有权和三种完成结果，而不是背算法名称；某标准特性已进入草案，为什么还要探针？前端、库和适配后端可以分别缺失；历史版本与当前修订也可能有差异。

差答：“C++26 已经让 C++ 内存安全”“有 reflection 就不用格式版本”“标准 SIMD 等于最佳汇编”。

20. Rust 对比：把哪些证明交给类型系统，哪些仍留给工程师？

强答要点：Rust 的所有权、借用与析构规则能在安全代码中拒绝多类悬空和别名冲突；C++ 更多依赖类型约定、代码审查和动态检查。比较应落到需要维护的证明数量、已有生态和边界成本，而不是预设某语言必然更快。

Rust 的 Send 表达值可安全跨线程转移，Sync 表达共享引用可安全跨线程使用，定义与不安全实现责任见 Rustonomicon：Send and Sync。Arc<T> 提供共享所有权，并不自动把任意 T 的内部操作变成线程安全；这与 C++ 的控制块／对象区分可以相互对照。

Rust 中的移动主要是所有权语义，不存在 C++ 那样可自由自定义的移动构造函数。地址敏感状态则需单独约束；标准库 Pin 文档解释固定（Pinning）与 Unpin 的条件，不能把 Pin 误读成“指针变量不能移动”或“对象永远不析构”。

C++ 协程的句柄、promise 和帧所有者，与 Rust 的未来对象（Future）及执行器，都需要运行时安排轮询或恢复、唤醒和关闭。安全类型可以约束接口，却不会替你决定公平调度、队列上限或远端操作何时停止；丢弃 future 也不必然取消已经提交的外部工作。

Rust 1.85 发布说明宣布 Rust 2024 Edition 在 2025 年稳定。新版要求更显式地标记不安全边界：unsafe extern 块强调外部声明正确性由作者负责；unsafe_op_in_unsafe_fn默认警告促使函数体中的不安全操作使用显式块。Edition 名称不是稳定发布年份，也不是 C++ ABI 兼容保证。

追问：安全 Rust 是否排除死锁和业务竞态？不排除；锁顺序、原子状态机和协议仍可能错误；FFI 必须写清什么？分配与释放方、长度和对齐、别名与可变性、回调有效期、线程归属及异常或 panic 边界。

差答：“Rust 没有内存泄漏”“加 Arc 就能随便共享”“包装一层就能验证 C++”“借用检查器解决所有并发问题”。

八、把强答变成可核验材料

21. 综合题：给一次查询取消后的崩溃与长尾，怎样组织答案？

强答要点：区域内存经队列交给协程输出，取消后崩溃、修复后峰值上升，先把对象和事件画完整：查询对象、区域资源、批次、队列元素、协程帧、底层在途操作；标出谁引用谁和谁拥有谁。崩溃先验证是否存在资源重置早于最后使用，再检查完成与取消是否重复终结。修复正确性以后，再比较保留内存和调度成本。

一种待验证方案是让输出任务持有批次所有者，取消后禁止新增派生任务，等在途操作完成才回收资源；同时用有界队列和字节预算限制保留量。它解决的是释放时序与上限，不保证吞吐不降：每批共享所有权、汇合和背压都可能新增成本，必须测量。

追问：用什么反例证明旧实现不安全？构造“输出已拿到视图但未消费 → 查询取消并重置区域 → 输出恢复”的确定性交错；为什么峰值上升可能是修复后的真实成本？旧实现可能过早归还账面预算，新方案才把在途资源完整计入；仍要排除无界队列与引用环。

差答：“给所有对象加 shared_ptr”“直接扩大队列”“换成无锁和新分配器”。

【模板】个人案例证据卡：仅填写允许披露且本人能核实的材料。没有真实案例时，将这张卡标为复核练习，不把设计推演改写为生产经历。

• 环境与版本：【填写编译器、标准库、引擎版本、CPU 拓扑与内存配置】。
• 具体触发：【填写输入、并发度、取消／超时条件和可观察后果】。
• 本人责任：【填写本人提出的判断、实现或验证；团队成员的工作单列】。
• 初始假设与反证：【只有实际存在时填写，不能为了叙事编造一次误判】。
• 关键证明：【填写所有权图、同步边或回收边界，以及对应提交／记录】。
• 验证与结果：【填写测量口径、实际结果、未覆盖条件与回退方式】。

验证边界

代码是教学反例或局部证明，未复现分配器排名、硬件性能或个人项目指标。练习应从一个不变量出发，给出同步边、最后使用点和能推翻答案的交错；个人案例仍用【模板】填入真实版本与结果。