Dorkytiger 的知识分享 on Dorkytiger 的小屋

`perf stat` —— 统计模式

Mon, 01 Jan 0001 00:00:00 +0000

一、基本用法

# 统计程序运行期间的硬件计数器
perf stat ./my_program

# 输出示例：
# Performance counter stats for './my_program':
#
#       1324.56  msec task-clock                # 1.00 CPUs utilized
#            12  context-switches               # 9.06 /sec
#             0  cpu-migrations                 # 0.00 /sec
#           125  page-faults                    # 94.35 /sec
#    4,285,294,201  cycles                      # 3.235 GHz
#    2,142,647,100  instructions                # 0.50  insn per cycle
#      428,529,420  branches                    # 323.5 M/sec
#        8,570,588  branch-misses               # 2.00% of all branches
#      214,264,710  L1-dcache-loads
#       21,426,471  L1-dcache-load-misses       # 10.00% of all L1-dcache accesses
#      107,132,355  cache-references
#       10,713,235  cache-misses                # 10.001 % of all cache refs

二、关键指标解读

instructions per cycle (IPC)
  含义：每个 CPU 周期执行了多少条指令
  理想值：现代 CPU 可以做到 3-4（超标量 + 乱序执行）
  
  IPC > 2：程序运行良好，CPU 利用率高
  IPC 1~2：有轻度流水线停顿
  IPC < 1：严重停顿，可能是缓存未命中、分支预测失败、指令依赖

  ❌ 低 IPC 的程序：
    [周期][周期][周期][周期][周期][周期][周期][周期]
    [指令]      [指令]      [指令]      [指令]
    CPU 大部分时间在等待内存或解决依赖

  ✅ 高 IPC 的程序：
    [周期][周期][周期][周期][周期][周期][周期][周期]
    [指令][指令][指令][指令][指令][指令][指令][指令]
    CPU 利用率接近理论峰值

cache-misses
  含义：L3 缓存未命中的次数
  理想值：< 5%（如果 < 1% 说明数据访问模式非常好）

  > 20%：内存访问模式有问题，需要重构数据结构
  常见原因：链表遍历、红黑树中序遍历、跳跃指针

branch-misses
  含义：分支预测失败的次数占比
  理想值：< 5%

  > 10%：分支模式难以预测
  常见原因：二分搜索中的随机数据、switch-case 中的均匀分布
  优化：用分支友好的算法（如用 cmov 替代分支）、使用 [[likely]]/[[unlikely]]

三、C++ 代码与 perf 计数器的对应

// IPC 低的代码（Cache Miss 严重）
void list_traversal(const std::list<int>& lst) {
    // list 的节点散落在堆中，遍历时大量 Cache Miss
    // perf 会显示 IPC < 1, cache-misses > 20%
    for (auto it = lst.begin(); it != lst.end(); ++it) {
        total += *it;
    }
}

// IPC 高的代码（缓存友好）
void vector_traversal(const std::vector<int>& vec) {
    // vector 连续内存，预取器提前加载
    // perf 会显示 IPC > 2, cache-misses < 1%
    for (auto x : vec) {
        total += x;
    }
}

// 分支预测失败的代码
void unpredictable_branch(const std::vector<int>& data) {
    long long sum = 0;
    for (int x : data) {
        // 如果 data 中的正负数随机分布，分支预测失败率 ~50%
        if (x > 0) sum += x;
    }
}

// 分支预测友好的优化版
void predictable_branch(const std::vector<int>& data) {
    long long sum = 0;
    std::sort(data.begin(), data.end());  // 排序后正数都在前面
    for (int x : data) {
        if (x > 0) sum += x;  // 前一批全命中，后一批全不命中 → 预测率接近 100%
    }
}

如何用 perf 验证优化效果：

`std::unique_ptr` —— 零开销的独占所有权

Mon, 01 Jan 0001 00:00:00 +0000

一、物理大小：和裸指针一样大

unique_ptr<int> up(new int(42));

栈上 (up 对象本身，8 字节):
+────────────────────+
| ptr (8字节，64位)   │  ← 就是指向堆上 int 的指针
+────────────────────+

堆上:
+────────────────────+
| 42                  │
+────────────────────+

关键：默认情况下（deleter 是无状态的函数对象/函数指针），unique_ptr 就是一个指针的大小，没有任何额外成员。它的析构函数在编译期被展开为 delete ptr，和裸指针手动 delete 完全一样。

// 汇编层面完全等价：
delete raw_ptr;          // mov rdi, [raw_ptr]; call operator delete
up.reset();              // 同上，mov rdi, [up.ptr]; call operator delete

这就是"零运行时开销"的含义：unique_ptr 在 Release 编译下和裸指针一样快。

二、为什么只能 `std::move` 不能拷贝？

unique_ptr<int> a(new int(42));
unique_ptr<int> b = a;          // ❌ 编译错误：拷贝构造被 delete
unique_ptr<int> c = std::move(a); // ✅ 移动：a 的指针置空，c 接管所有权

物理上的原因：

`std::variant` —— 类型安全联合体

Mon, 01 Jan 0001 00:00:00 +0000

解决什么问题？

// ❌ 传统 union 的问题
union Value {
    int i;
    double d;
    const char* s;
};

Value v;
v.i = 42;        // 现在 v 存的是 int
v.d = 3.14;      // 现在 v 存的是 double，覆盖了 int
// 编译器不管！v.i 现在是垃圾数据，但代码能访问 v.i → 未定义行为！
// 你必须自己用 tag 记录当前类型，但很容易忘记

variant 的承诺：编译期记住当前是哪种类型，访问错了会报错/抛异常。

什么时候用？

场景	为什么选 variant
函数返回"要么是正常结果，要么是错误信息"	替代 `pair<bool, T>` 或 -1 这样的哨兵值
解析器（JSON、INI、YAML）的节点类型	JSON 值可以是 string/number/array/object
状态机	状态是多种不同的结构体，但同一时刻只有一种
返回异构类型	函数可能返回 int、double 或 string

三种访问方式（选哪种？）

std::variant<int, double, std::string> v = 42;

// 方式 1：get<T>——你知道当前是什么类型时用
int val = std::get<int>(v);     // ✅ 正确
double val2 = std::get<double>(v); // ❌ 抛 bad_variant_access

// 方式 2：get_if<T>——不确定时用，安全
if (auto* p = std::get_if<double>(&v)) {
    // p 是 double*，当前 v 存的是 double 时才进入
} else if (auto* p = std::get_if<int>(&v)) {
    // 当前 v 存的是 int
}

// 方式 3：visit——最推荐，"我不管是什么类型，你帮我处理每个类型"
std::visit([](const auto& val) {
    // 编译器会为 int/double/string 各生成一个 lambda 实例
    // val 在三个实例中分别是 int、double、string
    std::cout << val;
}, v);

我推荐 visit：因为你不写大量 if-else，不容易漏掉某个类型。而且 visit 是编译期展开的，没有运行时成本。

`std::vector` 动态数组的内存黑幕

Mon, 01 Jan 0001 00:00:00 +0000

一、物理内存：绝对连续

vector 是 C++ 唯一保证元素在堆内存中绝对连续排列的容器（与 std::array 一样，但 array 在栈上）。

vector<int> v = {10, 20, 30, 40};

堆内存 (Heap):
+──────+──────+──────+──────+──────────────────+
|  10  |  20  |  30  |  40  |  预留空间         |
+──────+──────+──────+──────+──────────────────+
  ^      ^      ^      ^                       ^
  |      |      |      |                       |
v[0]   v[1]   v[2]   v[3]                   v.capacity() - 1

栈上 (Stack) — vector 对象本身 (24 字节，64位):
+────────────────────────────────────────────────────+
| _M_start (ptr)  | _M_finish (ptr) | _M_end_of_storage (ptr) |
| 指向堆首         | 指向堆尾(size)   | 指向容量尾(capacity)    |
+────────────────────────────────────────────────────+

关键结论：

AddressSanitizer（ASan）

Mon, 01 Jan 0001 00:00:00 +0000

一、它能抓到什么

// 1. 堆越界访问（Heap buffer overflow）
void heap_oob() {
    auto* arr = new int[10];
    arr[10] = 42;  // ASan 在这里崩溃，告诉你越界了
    delete[] arr;
}

// 2. 栈越界访问（Stack buffer overflow）
void stack_oob() {
    int arr[10];
    arr[10] = 42;  // ASan 捕获
}

// 3. Use-After-Free（释放后使用）
void use_after_free() {
    auto* p = new int(42);
    delete p;
    *p = 0;  // ASan 捕获：Address 0x... is a wild pointer
}

// 4. Double-Free
void double_free() {
    auto* p = new int(42);
    delete p;
    delete p;  // ASan 捕获：double free
}

二、用法

# 编译：加入 sanitize 标志
g++ -fsanitize=address -fno-omit-frame-pointer -g -O1 -o test test.cpp

# 运行（不用任何额外命令，直接运行即可）
./test

# 出错了会类似这样输出：
# ==============================================================
# ==12345==ERROR: AddressSanitizer: heap-buffer-overflow
#     WRITE of size 4 at 0x602000000014 thread T0
#     #0 0x400b12 in heap_oob() test.cpp:4
#     #1 0x400bf1 in main test.cpp:10
#     #2 0x7f1234567890 in __libc_start_main
#
# 0x602000000014 is located 0 bytes after 40-byte region
#   allocated by thread T0 here:
#     #0 0x7f123456abcd in operator new[](unsigned long)
#     #1 0x400adf in heap_oob() test.cpp:3
#
# SUMMARY: AddressSanitizer: heap-buffer-overflow test.cpp:4
# ==============================================================

# 关键信息：
# heap-buffer-overflow → 堆越界
# test.cpp:4            → 第 4 行出了问题
# 0 bytes after 40-byte region → 在 40 字节分配区域之后越界了 0 字节（正好最后一个 int）

三、和你的两个项目相关的例子

// SimpleAsyncLogger 中可能出现的 Use-After-Free
// ring_buffer.cpp 中的无锁队列
void producer_race_example() {
    uint8_t* buffer = new uint8_t[1024];
    std::thread producer([&] {
        // 假设这里操作 buffer
        buffer[0] = 1;
    });
    std::thread consumer([&] {
        // 假设这里也操作 buffer
        buffer[0] = 2;
    });

    producer.join();
    consumer.join();

    // ⚠️ 如果 consumer 删除了 buffer 而 producer 还在用 → ASan 帮你抓到
    // 编译时带上 -fsanitize=address 就能自动检测这种问题
}

// ScoreMaster 中的 DMA-BUF fd 泄漏
void dma_buf_leak() {
    // 如果忘记 close DMA buffer 的 fd
    // ASan 不会直接捕获（因为 fd 是内核资源）
    // 但堆上的 fd 包装对象泄漏了 ASan 是能看到的
}

四、性能影响

ASan 开启后：
  运行速度：慢约 2 倍
  内存占用：多约 2-3 倍

所以只在测试/CI 构建中开启，生产环境关闭。

推荐：CMake 中按构建类型启用
  # CMakeLists.txt
  if(CMAKE_BUILD_TYPE STREQUAL "Debug")
      set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address -fno-omit-frame-pointer")
  endif()

Callgrind —— 指令级精确分析

Mon, 01 Jan 0001 00:00:00 +0000

一、和 perf 的区别

perf（采样）：
    每隔 N 微秒采样一次 CPU 的 PC 寄存器
    快（几乎不影响程序运行速度）
    统计结果有误差（采样丢失）

Callgrind（模拟）：
    用 Valgrind 的虚拟 CPU 模拟执行每条指令
    慢（慢 20-30 倍）
    结果精确（统计了每一条指令、每次缓存访问）

二、基本用法

# 运行 Callgrind
valgrind --tool=callgrind ./my_program

# 输出文件：callgrind.out.12345 (pid=12345)

# 查看函数排行
callgrind_annotate callgrind.out.12345

# 输出示例：
# --------------------------------------------------------------------------
# Ir (指令数)   Dr (读)    Dw (写)    L1m (L1 Miss)  L2m (L2 Miss)  function
# --------------------------------------------------------------------------
# 12,345,678    4,321,000  2,100,000  123,456        12,345         motion_search
#  8,234,567    3,100,000  1,500,000   89,012         8,901         dct_transform
#  2,345,678      900,000    400,000  234,567        23,456         memcpy
#    567,890      200,000    100,000    1,234           123         frame_copy

# 重要指标：
# Ir（Instructions）—— 总指令数，越多的函数越值得优化
# L1m / L2m —— 缓存不命中率，越高说明内存访问模式越差

# 可以清晰看到：
# motion_search 指令数最多（12M），且 L1 Miss 也高（123K）
# → 优先优化这个函数，且优化方向是改善内存访问模式

三、可视化分析

# 用 KCachegrind（GUI 工具）打开
kcachegrind callgrind.out.12345

# 可以在图形界面中看到：
# - 函数调用关系的图（谁调了谁，花费了多少指令）
# - 每个函数的指令数/缓存 Miss 数/分支预测失败数
# - 源码级别的指令开销
# - 热路径（哪个调用链最耗时）

Clang-Tidy

Mon, 01 Jan 0001 00:00:00 +0000

一、Clang-Tidy 能做什么

Clang-Tidy 是 LLVM 的静态分析工具，在编译时分析代码中潜在的 Bug 和代码异味。和 GDB/Run-time sanitizer 不同，它不需要运行程序就能检测问题。

# 基本用法
clang-tidy --checks=* source.cpp -- -std=c++17

# 常用 check 组合
clang-tidy --checks=modernize-*,performance-*,bugprone-* source.cpp

二、它能抓到的问题

// 1. modernize —— 用现代 C++ 写法替代旧写法
int* ptr = new int(42);    // warning: use auto rather than explicit type
auto* ptr = new int(42);   // ✅ 推荐写法

// 2. performance —— 性能问题
std::vector<int> v;
for (int i = 0; i < v.size(); i++) {  // warning: range-for loop is faster
    foo(v[i]);
}
for (auto x : v) {                     // ✅ 推荐
    foo(x);
}

// 3. bugprone —— 潜在的 Bug
int x = 1;
if (x = 42) {   // warning: assignment in if condition, did you mean == ?
    // ...
}

void foo(const std::string& s) {
    std::cout << s.c_str() << std::endl;  // warning: unnecessary .c_str() call
    std::cout << s << std::endl;           // ✅ 推荐
}

// 4. clang-analyzer —— 深层逻辑错误
int* get_ptr() {
    int x = 42;
    return &x;  // warning: returning reference to local temporary
}

void test() {
    int* p = get_ptr();
    *p = 0;     // Use-After-Free（栈变量已失效）
}

三、在 CMake 中集成

# CMakeLists.txt 中添加 clang-tidy 支持
# ccmake 时设置 -DCMAKE_CXX_CLANG_TIDY=clang-tidy

# 或者编辑 CMakeCache.txt：
# CMAKE_CXX_CLANG_TIDY:STRING=clang-tidy;-checks=modernize-*,performance-*,bugprone-*

# 效果：每次编译时自动运行 clang-tidy，警告出现在编译输出中

四、用 `.clang-tidy` 配置项目规则

# .clang-tidy
Checks: >
    modernize-*,
    performance-*,
    bugprone-*,
    readability-*,
    -modernize-use-trailing-return-type,  # 排除某个不想要的检查

WarningsAsErrors: >
    bugprone-*     # 把 Bug 相关的警告视为错误

CheckOptions:
    { key: readability-identifier-naming.ClassCase, value: CamelCase }
    { key: readability-identifier-naming.FunctionCase, value: camelBack }

CPU 缓存行（Cache Line）与 MESI 协议

Mon, 01 Jan 0001 00:00:00 +0000

完美！进入第二阶段，我们要从"原子操作"升级到"缓存一致性"，这是理解内存屏障和伪共享的基石。这个问题直击高性能并发编程的灵魂。

1. 缓存行（Cache Line）：CPU缓存的最小传输单位

什么是缓存行？

CPU和内存之间传输数据时，不是按字节，而是按块（Block） 传输。这个块的大小就是缓存行（Cache Line），现代CPU通常为 64字节。

内存地址空间 (假设从 0x0000 开始):
+--------+--------+--------+--------+--------+--------+
| 字节0   | 字节1   | 字节2   | ...    | 字节63  |        ← 缓存行 1 (0x0000 - 0x003F)
+--------+--------+--------+--------+--------+--------+
| 字节64  | 字节65  | ...    |         | 字节127 |        ← 缓存行 2 (0x0040 - 0x007F)
+--------+--------+--------+--------+--------+--------+

关键特性：

当CPU读取 int a（4字节），实际会加载整个64字节的缓存行到L1。
当CPU修改 int a，先把整个缓存行加载，修改后整行写回（或标记脏）。
缓存行是对齐的：地址必须是64的倍数（address & ~63 得到行首）。

为什么用缓存行？（空间局部性）

// 数组遍历：极快
int arr[1000000];
for (int i = 0; i < 1000000; i++) {
    arr[i]++; // 每次访问 arr[i]，相邻的 arr[i+1] 已经被预加载到缓存行
}
// 缓存命中率 > 95%

2. MESI协议：缓存一致性的"交通规则"

多个核心都有自己独立的L1/L2缓存，如何保证它们看到的数据一致？MESI协议定义了缓存行的四种状态，每个核心的缓存控制器维护这个状态机。

CRTP 基础模式

Mon, 01 Jan 0001 00:00:00 +0000

一、为什么需要 CRTP？

场景：你有一个算法框架，不同的派生类有不同的"处理步骤"，但算法骨架是一样的。你有两个选择：

虚函数方案：

class Processor {
public:
    virtual void process() = 0;
    virtual ~Processor() = default;
};

问题：虚函数调用不能内联。如果你的 process() 只有几行代码且每秒调用百万次，虚函数间接寻址的开销占比就很大。

CRTP 方案：把派生类作为模板参数传给基类，基类用 static_cast 调用派生类的方法——这个转换在编译期完成，可以内联。

二、CRTP 长什么样？

template <typename Derived>
class Base {
public:
    void interface() {
        // 编译期将 this 转为 Derived*，直接调用
        static_cast<Derived*>(this)->implementation();
    }
};

class DerivedA : public Base<DerivedA> {
public:
    void implementation() { /* A 的处理 */ }
};

class DerivedB : public Base<DerivedB> {
public:
    void implementation() { /* B 的处理 */ }
};

编译器眼中：

Base<DerivedA>::interface() 被调用时：
  static_cast<DerivedA*>(this) 在编译期确定
  → 直接调用 DerivedA::implementation()
  → 可以内联 → 编译后可能只剩几条指令

Base<DerivedB>::interface() 被调用时：
  → 直接调用 DerivedB::implementation()
  两个 Base<DerivedA> 和 Base<DerivedB> 是完全不同的类型
  各有自己的 interface() 实现，没有虚表

三、CRTP 和虚函数的性能差距

// 虚函数版
struct ShapeVirt { virtual double area() const = 0; };
struct CircleVirt : ShapeVirt {
    double r;
    double area() const override { return 3.1415926 * r * r; }
};

// CRTP 版
template <typename Derived>
struct ShapeCRTP {
    double area() const {
        return static_cast<const Derived*>(this)->area_impl();
    }
};
struct CircleCRTP : ShapeCRTP<CircleCRTP> {
    double r;
    double area_impl() const { return 3.1415926 * r * r; }
};

10 亿次调用实测：

CRTP（奇异递归模板模式）

Mon, 01 Jan 0001 00:00:00 +0000

一、解决什么问题？

问题：你有一个通用的算法骨架（比如"遍历 + 处理 + 汇总"），但其中的"处理"步骤在不同类型中不同。有两种选择：

虚函数：方便，但每次调用都要查 vtable，而且虚函数不能内联。
CRTP：消除虚函数开销，但要求类型在编译期已知。

CRTP 的典型场景：

你的类继承一个基类，但基类需要调用派生类的成员函数。
你对性能有要求，不能接受虚函数调用的 vtable 寻址 + 无法内联。
你知道派生类的具体类型（编译期已知）。

二、底层原理：编译期 `this` 转换

template <typename Derived>
class Base {
public:
    void interface() {
        // static_cast 在编译期完成，不产生运行时开销
        // 等价于直接调用 Derived::impl()
        static_cast<Derived*>(this)->impl();
    }
};

class MyClass : public Base<MyClass> {
public:
    void impl() { /* ... */ }
};

编译器眼中的展开：

MyClass 继承自 Base<MyClass>。

当调用 my_obj.interface() 时：
  编译器看到 Base<MyClass>::interface()
  → static_cast<MyClass*>(this) → 编译器知道 this 的实际类型是 MyClass*
  → 直接调用 MyClass::impl()
  → 可以内联（inline）！

三、虚函数 vs CRTP——性能差距有多大？

// 写法 A：虚函数
struct ShapeVirt { virtual double area() const = 0; };
struct CircleVirt : ShapeVirt {
    double r_;
    double area() const override { return 3.14 * r_ * r_; }
};

// 写法 B：CRTP
template <typename Derived>
struct ShapeCRTP {
    double area() const { return static_cast<const Derived*>(this)->area_impl(); }
};
struct CircleCRTP : ShapeCRTP<CircleCRTP> {
    double r_;
    double area_impl() const { return 3.14 * r_ * r_; }
};

面试官会问：“CRTP 比虚函数快多少？为什么？”

FFmpeg 命令行

Mon, 01 Jan 0001 00:00:00 +0000

一、日常必会命令

# 查看文件信息
ffprobe input.mp4
ffprobe -v quiet -print_format json -show_streams input.mp4  # JSON 格式

# 格式转换
ffmpeg -i input.avi -c:v libx264 -c:a aac output.mp4

# 截取片段（从 10 秒开始，持续 5 秒）
ffmpeg -i input.mp4 -ss 10 -t 5 -c copy output.mp4

# 缩放到 720p
ffmpeg -i input.mp4 -vf scale=-1:720 output.mp4

# 推流到 RTMP
ffmpeg -i input.mp4 -c:v libx264 -preset ultrafast -f flv rtmp://server/live/stream

# 桌面推流（Windows）
ffmpeg -f gdigrab -i desktop -c:v libx264 -preset ultrafast -tune zerolatency -f flv rtmp://localhost/live/test

# 拉流并保存
ffmpeg -i rtmp://server/live/stream -c copy record.mp4

二、直播延迟优化

# ❌ 默认配置（高延迟，高质量）
ffmpeg -i input -c:v libx264 -f flv rtmp://server/live

# ✅ 低延迟配置
ffmpeg -i input -c:v libx264 \
  -preset ultrafast \              # 最快的编码速度
  -tune zerolatency \              # 零延迟优化
  -g 15 \                          # 每 15 帧一个关键帧
  -bf 0 \                          # 不要 B 帧
  -f flv rtmp://server/live/stream

# 各参数的延迟影响：
# -preset ultrafast ↓延迟 ↑文件体积（编码快，但压缩率低）
# -preset medium    平衡点
# -preset veryslow  ↑延迟 ↓文件体积（编码慢，但压缩率高）
# 直播必须用 ultrafast 或 veryfast

PCM 裸音频

Mon, 01 Jan 0001 00:00:00 +0000

一、音频怎么变成数据

声卡以固定的频率采样声波的电压值，每次采样得到一个数值。这些数值按时间顺序排列就是 PCM 数据。

声波（模拟信号）：  ╱╲    ╱╲    ╱╲    ╱╲
                 ╱  ╲  ╱  ╲  ╱  ╲  ╱  ╲
采样（数字信号）：  █   █   █   █   █   █
                  ↑   ↑   ↑   ↑   ↑   ↑
                 t0  t1  t2  t3  t4  t5
                 每隔 1/44100 秒采一次

二、三个关键参数

// 采样率（Sample Rate）：每秒采多少次
// 44100 Hz = CD 音质
// 48000 Hz = 视频/DVD 标准
// 96000 Hz = 高解析度音频

// 位深（Bit Depth）：每次采样用多少 bit 表示
// 16 bit = CD 音质，每个样本范围 -32768 ~ 32767
// 24 bit = 录音室级别
// float 32 = 音频处理内部格式

// 声道数（Channels）：
// 1 = Mono
// 2 = Stereo（左右声道交织）
// 6 = 5.1 环绕声

// PCM 数据量计算
void calc_pcm_size(int sample_rate, int bit_depth, int channels, int duration_sec) {
    int bytes_per_sample = bit_depth / 8;
    int bytes_per_sec = sample_rate * bytes_per_sample * channels;
    int total_bytes = bytes_per_sec * duration_sec;

    printf("PCM 参数: %dHz/%dbit/%dch\n", sample_rate, bit_depth, channels);
    printf("每秒: %d bytes (%.1f KB)\n", bytes_per_sec, bytes_per_sec / 1024.0);
    printf("1 分钟: %d bytes (%.1f MB)\n", total_bytes, total_bytes / 1024.0 / 1024);
}

// calc_pcm_size(48000, 16, 2, 60);
// 输出：
// 每秒: 192000 bytes (187.5 KB)
// 1 分钟: 11520000 bytes (11.0 MB)
// 对比：同样的 1 分钟 AAC 128kbps → 约 1MB，压缩率约 11x

三、音频在内存中的布局

// Stereo 16-bit PCM 的内存布局（交织模式 Interleaved）：
// [L][R][L][R][L][R]...
//  采样0  采样1  采样2
// 每个样本是 int16_t（小端序）

#include <cstdint>

struct Stereo16Sample {
    int16_t left;
    int16_t right;
};

// 生成一个 440Hz 的正弦波测试音（A4 音）
void generate_sine_wave(int16_t* buffer, int num_samples, int sample_rate) {
    double freq = 440.0;  // A4
    for (int i = 0; i < num_samples; i++) {
        double t = (double)i / sample_rate;
        double value = sin(2.0 * M_PI * freq * t) * 32767.0;  // 归一化到 16bit 范围
        buffer[i] = (int16_t)value;
    }
}

// 混音：把两个音频叠加（注意防止溢出）
void mix_audio(const int16_t* a, const int16_t* b, int16_t* out, int count) {
    for (int i = 0; i < count; i++) {
        int mixed = (int)a[i] + (int)b[i];
        // 防止溢出：钳制到 int16_t 范围
        if (mixed > 32767) mixed = 32767;
        if (mixed < -32768) mixed = -32768;
        out[i] = (int16_t) mixed;
    }
}

PGO 的原理

Mon, 01 Jan 0001 00:00:00 +0000

一、PGO 解决什么问题

编译器默认的优化是基于通用假设——它不知道你的程序实际运行时哪些分支是热的、哪些是冷的。

// 编译器不知道这两条分支的实际运行频率：
void process(bool is_error) {
    if (is_error) {
        // 编译器假设这两条分支概率是 50/50
        // 但实际上这条分支只占 0.01%
        log_error();
        return;
    }
    // 99.99% 的执行走这里
    do_normal_work();
}

PGO 的做法：

先编译一个带桩（profile-generate）的版本。
用真实负载跑一遍，收集实际的执行行为。
用收集的数据重新编译（profile-use），编译器知道"那条错误分支 99.99% 不执行"→ 把它放到 .text.unlikely 段 + 不再内联 + 不再预取。

二、三步流程

# 第一步：插桩编译
g++ -O2 -fprofile-generate -o my_program main.cpp
# 生成一个插桩后的可执行文件

# 第二步：跑真实负载
./my_program < test_input.txt
# 运行结束后生成 *.gcda 文件（profile 数据）
# 位置：当前目录的 ./ 或环境变量 GCOV_PREFIX 指定

# 第三步：利用 profile 优化编译
g++ -O2 -fprofile-use -o my_program_opt main.cpp
# 编译器读取 *.gcda 中的信息做针对性优化

三、PGO 的实际效果

没有 PGO：
  main → process (50%) → normal (生成两份差不多的代码)
              (50%) → error

有 PGO（profile 显示只走了 0.01% error 路径）：
  编译器做的优化：
    1. normal 路径内联到 process 中（减少一次函数调用）
    2. error 路径移到 .text.unlikely（热代码更紧凑，I-Cache 命中率更高）
    3. normal 路径的基本块排在一起（减少分支跳转）
    4. 寄存器分配策略偏向 normal 路径

实测结果：
    性能提升通常在 10-30%，取决于分支的可预测性。
    浏览器（Chrome）用 PGO 编译后，启动速度提升约 15%。

PIMPL 惯用法（Pointer to Implementation）

Mon, 01 Jan 0001 00:00:00 +0000

一、解决什么问题？

问题：你有一个类的头文件，暴露了私有成员。每次修改私有成员，所有包含这个头文件的 .cpp 都要重新编译——大项目里一次改动触发 10 分钟的全量编译。

// widget.h — ❌ 私有成员在头文件里
class Widget {
    std::string title_;       // private
    std::vector<int> data_;   // private
    // 每次改这些私有成员，所有 include widget.h 的 .cpp 都要重编
public:
    void show();
};

PIMPL 的做法：私有成员放到一个 Impl 结构体，只在前向声明：

// widget.h
class Widget {
    struct Impl;               // 只声明，不定义
    std::unique_ptr<Impl> pimpl_;

public:
    Widget();
    ~Widget();                 // 析构必须在 .cpp 中定义（因为 Impl 是不完整类型）
    void show();
};

// widget.cpp
struct Widget::Impl {
    std::string title_;
    std::vector<int> data_;
};

Widget::Widget() : pimpl_(std::make_unique<Impl>()) {}
Widget::~Widget() = default;  // 必须在这里定义

void Widget::show() {
    // 通过 pimpl_ 访问私有成员
    std::cout << pimpl_->title_;
}

效果：改 Impl 的成员只需要编译 widget.cpp，不需要重新编译所有 #include "widget.h" 的文件。

PTS / DTS

Mon, 01 Jan 0001 00:00:00 +0000

一、为什么需要两个时间戳

I 帧：不需要参考其他帧，解码顺序 = 显示顺序
P 帧：参考前一帧，解码顺序 = 显示顺序

B 帧：需要参考前后帧 → 解码顺序 ≠ 显示顺序！

视频帧顺序（显示顺序）：
  I B B P B B P B B ...
  1 2 3 4 5 6 7 8 9 ...

解码器需要的顺序（解码顺序）：
  I P B B P B B ...  ← 因为解码 B 帧需要前后的 P 和 I
  1 4 2 3 7 5 6 ...

所以每个帧有两个时间戳：
  DTS（Decode TimeStamp）：解码器按这个顺序解码
  PTS（Present TimeStamp）：播放器按这个顺序显示

举个实际例子：
  帧序列：I1(pts=0) B2(pts=1) B3(pts=2) P4(pts=3) B5(pts=4) B6(pts=5) P7(pts=6)
  解码顺序：I1(dts=0) P4(dts=1) B2(dts=2) B3(dts=3) P7(dts=4) B5(dts=5) B6(dts=6)
          ↓解码          ↓需要 P4 解码后才能解 B2
  显示顺序：I1 B2 B3 P4 B5 B6 P7

二、在 FFmpeg 中拿正确的 PTS

// 解码后的 frame 中的 pts 要用 stream 的 time_base 转换成秒
void print_frame_timestamp(AVFormatContext* fmt_ctx, int stream_idx, AVFrame* frame) {
    AVStream* stream = fmt_ctx->streams[stream_idx];
    AVRational tb = stream->time_base;

    // frame->pts 的单位是 time_base
    // 例如 time_base = {1, 1000} 表示 pts 单位是毫秒
    // 例如 time_base = {1, 90000} 表示 pts 单位是 1/90000 秒（H.264 常用）

    double pts_seconds = frame->pts * av_q2d(tb);
    printf("PTS = %ld (raw), %.3f (seconds)\n", frame->pts, pts_seconds);
}

// 把 packet 的时间戳从编码器时基转换到流时基
void convert_packet_ts(AVFormatContext* fmt_ctx, AVCodecContext* enc_ctx,
                        AVStream* stream, AVPacket* packet) {
    av_packet_rescale_ts(packet,
                         enc_ctx->time_base,       // 编码器时基
                         stream->time_base);       // 容器时基
}

Reactor 模式

Mon, 01 Jan 0001 00:00:00 +0000

单线程 Reactor（Redis 就是这种）：

一个 Event Loop（epoll_wait）：
  while (true) {
    epoll_wait();    // 等待事件
    for (每个事件) {
      if (可读) 读取数据 → 处理请求 → 发送响应
      if (可写) 继续发送
      if (新连接) accept
    }
  }

优点：没有多线程竞争问题，简单。缺点：一个请求处理慢了，阻塞所有后续请求。

多线程 Reactor（最常见模型）：

Main Reactor（一个线程）：
  accept 新连接 → 分发给 SubReactor

SubReactor（多个线程，每个一个 epoll）：
  epoll_wait(该连接) → 读取数据
    → 把解析好的请求提交给 ThreadPool 处理
    → 在工作线程中执行业务逻辑
    → 工作线程完成后，通知 SubReactor 发送响应

RGB 色彩空间

Mon, 01 Jan 0001 00:00:00 +0000

一、RGB 的物理含义

RGB 是加色模型：三种颜色的光叠加在一起，越叠越亮。

       红 (R)
      /   \
    /      \
黄         洋红
|            |
绿 ──── 白 ──── 蓝
|            |
  青         蓝 (B)
      \      /
        \  /
       绿 (G)

显示器的工作原理：每个像素由三个子像素（红/绿/蓝 LED）组成，通过控制亮度百分比混合出各种颜色。

在内存中的排列（C++ 处理时直接面对）：

// RGB24：每个像素 3 字节，R/G/B 各 8 bit
struct RGBPixel {
    uint8_t r, g, b;  // 内存顺序取决于平台
};

// OpenCV 是 BGR 顺序
struct BGRPixel {
    uint8_t b, g, r;  // 注意：蓝在前，红在后
};

// RGBA：每个像素 4 字节，多一个 Alpha（透明度）
struct RGBAPixel {
    uint8_t r, g, b, a;
};

// 一行 1920×1080 RGB 图片的内存布局
// [R][G][B][R][G][B][R][G][B]......[R][G][B]
//  \___________ 1920 × 3 = 5760 字节 ___________/
// 然后下一行

二、RGB 为什么不适合视频编码？

你提到的这个问题确实是很多初学者容易困惑的地方。简单说：RGB 把宝贵的带宽浪费在了人眼不敏感的信息上，而且三个通道之间有大量重复信息。

RTMP 协议

Mon, 01 Jan 0001 00:00:00 +0000

一、RTMP 握手

客户端                            服务器
  │                                │
  │──── C0 (版本=3) ──────────────→│
  │──── C1 (1536 字节随机数据) ────→│
  │←─── S0 (版本=3) ──────────────│
  │←─── S1 (1536 字节随机数据) ────│
  │←─── S2 (C1 的回应) ───────────│
  │──── C2 (S1 的回应) ───────────→│
  │                                │
  │       握手完成，建立连接         │
  │                                │
  │──── connect("live") ──────────→│
  │←─── _result (成功) ───────────│
  │──── createStream ─────────────→│
  │←─── _result (stream_id=1) ────│
  │──── publish("live") ──────────→│
  │←─── onStatus("正在发布") ──────│
  │                                │
  │       开始推送音视频数据         │
  │──── Audio/Video Tag ──────────→│
  │──── Audio/Video Tag ──────────→│
  │ ...                            │

二、RTMP Chunk 分片

RTMP 的核心设计：把大的消息切成小的 chunk，交错发送，避免大消息阻塞后面的小消息。

SPSC (单写单读) 的极致优化

Mon, 01 Jan 0001 00:00:00 +0000

SPSC（Single Producer Single Consumer）是并发队列的性能天花板。因为只有一个线程写、一个线程读，我们完全不需要CAS，只需要内存屏障保证可见性，就能实现每秒数亿次的数据交换。

1. SPSC 为什么可以零 CAS？

多生产者/多消费者 (MPMC): 需要CAS保证原子性
    ↓
单生产者/多消费者 (SPMC): 需要CAS保护生产者竞争
    ↓
多生产者/单消费者 (MPSC): 需要CAS保护消费者竞争
    ↓
单生产者/单消费者 (SPSC): 
    - 写指针 (head)：只有生产者修改 → 不需要原子操作
    - 读指针 (tail)：只有消费者修改 → 不需要原子操作
    - 唯一需求：生产者写完数据后，消费者能看到 → 需要内存屏障

核心认知：SPSC不需要任何原子RMW（Read-Modify-Write）指令，只需要：

普通内存拷贝（memcpy）
Release屏障（生产者写完数据后刷新Store Buffer）
Acquire屏障（消费者读取数据前清空Invalidation Queue）

2. 环形缓冲区（Ring Buffer）—— SPSC的经典实现

数据结构

template<typename T, size_t Capacity>
class SPSCRingBuffer {
    static_assert((Capacity & (Capacity - 1)) == 0, 
                  "Capacity must be power of 2 for efficient modulo");
    
    // 缓存行对齐：避免伪共享
    alignas(64) std::atomic<size_t> head{0};  // 生产者写位置 (消费者读)
    alignas(64) std::atomic<size_t> tail{0};  // 消费者读位置 (生产者写)
    
    // 数据存储：缓存行对齐，避免伪共享
    alignas(64) T buffer[Capacity];
    
public:
    // 生产者：写入数据
    bool enqueue(const T& item) {
        const size_t current_head = head.load(std::memory_order_relaxed);
        const size_t next_head = (current_head + 1) & (Capacity - 1);
        
        // 检查队列是否已满
        if (next_head == tail.load(std::memory_order_acquire)) {
            return false; // 队列满
        }
        
        // 写入数据 (普通内存拷贝)
        buffer[current_head] = item;
        
        // Release屏障：确保数据写入完成，再更新head
        // 等价于: std::atomic_thread_fence(std::memory_order_release)
        head.store(next_head, std::memory_order_release);
        return true;
    }
    
    // 消费者：读取数据
    bool dequeue(T& item) {
        const size_t current_tail = tail.load(std::memory_order_relaxed);
        
        // 检查队列是否为空
        if (current_tail == head.load(std::memory_order_acquire)) {
            return false; // 队列空
        }
        
        // 读取数据 (普通内存拷贝)
        item = buffer[current_tail];
        
        // Acquire屏障：确保数据读取前，tail更新已完成
        const size_t next_tail = (current_tail + 1) & (Capacity - 1);
        tail.store(next_tail, std::memory_order_release);
        return true;
    }
};

内存布局图示

环形缓冲区 (Capacity=8, 掩码=7):
+------------------------------------------------------------------+
| 索引: 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |  (使用位运算 & 7 取模)    |
+------------------------------------------------------------------+
      ↑                    ↑
      |                    |
    tail (消费者)       head (生产者)
    
生产者在 head 处写入，然后 head = (head+1) & 7
消费者在 tail 处读取，然后 tail = (tail+1) & 7

当 head == tail → 队列空
当 (head+1) & 7 == tail → 队列满 (留一个空位区分空和满)

3. 性能核武器：批量处理（Batch Processing）

单元素入队/出队虽然快，但批量操作能把吞吐量推向极致。

Type Erasure 要解决什么问题

Mon, 01 Jan 0001 00:00:00 +0000

一、问题场景

场景：你有一个容器，想存"满足某个接口的任何类型"，但又不希望用户继承你的基类。

传统做法是定义一个抽象基类，用户必须继承它：

class Drawable {
public:
    virtual void draw() const = 0;
    virtual ~Drawable() = default;
};

// 用户必须继承 Drawable
class MyCircle : public Drawable { ... };

问题：用户需要用 public 继承你的类，这是侵入式的。用户可能已经有了自己的类层次，不想再改继承。

Type Erasure 的做法：非侵入式——用户不需要继承任何东西。你提供包装器。

二、Type Erasure 的核心模式

Type Erasure 的经典实现是 外部多态（External Polymorphism）：

// 1. 用 concept 定义接口
template <typename T>
concept Drawable = requires(const T& t) {
    { t.draw() } -> std::same_as<void>;
};

// 2. 类型擦除包装器（用户可以传入任何满足 Drawable 的类型）
class DrawableWrapper {
    struct Concept {
        virtual void draw() const = 0;
        virtual ~Concept() = default;
    };

    template <Drawable T>
    struct Model : Concept {
        T obj_;
        Model(T obj) : obj_(std::move(obj)) {}
        void draw() const override { obj_.draw(); }
    };

    std::unique_ptr<Concept> pimpl_;

public:
    template <Drawable T>
    DrawableWrapper(T obj) : pimpl_(std::make_unique<Model<T>>(std::move(obj))) {}

    void draw() const { pimpl_->draw(); }
};

用法：

一、核心原理解释：物理视角的分类法

Mon, 01 Jan 0001 00:00:00 +0000

在现代 C++ 中，一个表达式有两个独立维度的属性：

拥有身份（Has Identity）：在内存中有固定的、可寻址的物理地址。
可被移动（Can be Moved）：生命周期即将结束，它的资源（比如堆内存）允许被别人无损接管。

根据这两个维度的组合，C++ 官方将所有的“值（Value）”严格划分为了三大主类：

                     ┌──────────────────┐
                     │   表达式（Value） │
                     └────────┬─────────┘
                              ▼
            ┌─────────────────┴─────────────────┐
            ▼                                   ▼
   【有身份 / 内存可寻址】                    【临时数据 / 可被移动】
      (Has Identity)                       (Can be Moved)
            │                                   │
      ┌─────┴───────────┐                 ┌─────┴───────────┐
      ▼                 ▼                 ▼                 ▼
   左值 (lvalue)    将亡值 (xvalue)   将亡值 (xvalue)   纯右值 (prvalue)

1. 左值 (lvalue) —— 有身份，不可移动

本质：指代一个持久存在的内存对象。只要你能用 &（取地址符）拿到它在内存中的物理地址，它就是左值。
特点：有名字，生命周期由作用域决定，编译器不能随意销毁它。
常见示例：变量名 a、函数名、左值引用 int& r = a;、解引用表达式 *ptr。

2. 纯右值 (prvalue) —— 无身份，可移动

本质：纯粹的临时字面量或运算产生的临时过渡数据。它们在物理内存中没有独立的持久身份（你没办法对它们取地址）。
特点：没有名字，生命周期极短，通常只存在于 CPU 寄存器或编译器的临时栈帧中。
常见示例：字面量 42、'a'；算术表达式 a + b；函数返回的临时非引用对象（如 std::string("hello")）。

3. 将亡值 (xvalue) —— 有身份，可移动（现代 C++ 零拷贝的精髓 ✨）

本质：这是一个虽然在内存中有地址，但它马上就要被销毁（即将死亡）的对象。
特点：因为它有身份，所以你可以找到它；因为它可移动，这意味着你被允许去“合法压榨”它，把它的堆内存指针据为己有。
常见示例：最典型的将亡值就是通过 std::move(a) 强转出来的结果，或者返回右值引用的函数调用。

一、Concepts 到底解决了什么问题？

Mon, 01 Jan 0001 00:00:00 +0000

没有 Concepts 的 C++：

template <typename T>
T twice(T x) {
    return x + x;
}

twice(42);           // ✅ 正常
twice("hello"s);     // ✅ 正常（string 可以 +）
twice(std::mutex{}); // ❌ 编译报错，5 万行报错信息！！

错误信息长啥样？

error: no match for 'operator+' (operand types are 'std::mutex' and 'std::mutex')
  note: candidate: 'std::mutex::mutex(const std::mutex&)' <near match>
  note: conversion of argument 1 would be ill-formed
  ... (50 行后续错误)
  ... (深入各种模板实例化失败上下文)
  ... (100 行库内部代码)

有了 Concepts 的 C++ 20：

一、Ranges 解决了一个什么痛？

Mon, 01 Jan 0001 00:00:00 +0000

痛点：你有一段数据处理逻辑——筛选、转换、取前 N 个。传统写法会产生多个中间容器：

std::vector<int> data = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

// 传统风格：产生两个临时 vector
std::vector<int> evens;
std::copy_if(data.begin(), data.end(), std::back_inserter(evens),
             [](int x) { return x % 2 == 0; });        // ① 分配 evens

std::vector<int> doubled;
std::transform(evens.begin(), evens.end(), std::back_inserter(doubled),
               [](int x) { return x * 10; });           // ② 分配 doubled

std::vector<int> top3;
std::copy_n(doubled.begin(), 3, std::back_inserter(top3)); // ③ 分配 top3

// 3 次分配、3 次遍历、3N 次拷贝

Ranges 的做法：

auto result = data
    | std::views::filter([](int x) { return x % 2 == 0; })
    | std::views::transform([](int x) { return x * 10; })
    | std::views::take(3);

// 0 次分配、1 次遍历、0 次多余拷贝

Ranges 的核心承诺：写出表达力强的代码，但不付出性能代价。

一、容器为什么不直接 new/delete？

Mon, 01 Jan 0001 00:00:00 +0000

直接 new/delete 的问题：

// 假如 vector 内部用 new[]/delete[] 管理内存
// 那么每次 push_back 导致扩容时：
// ① new[] 分配新内存 + 默认构造 N 个元素（浪费！其实我只想申请内存，不构造）
// ② 拷贝/移动旧元素
// ③ delete[] 旧内存 + 析构所有元素（又浪费！其实我只想释放内存，不析构）

分配器把"分配内存"和"构造对象"分开了：

// vector 底层实际做的
Alloc alloc;
T* p = alloc.allocate(10);    // 只分配 10 个 T 大小的空间，不构造
// 这 10 个位置是原始内存，里面可能放着旧数据

alloc.construct(p + 3, args); // 在第 4 个位置构造一个新对象（placement new）
// 现在 p+3 才真正有了一个 T 对象

alloc.destroy(p + 3);         // 手动调用析构
alloc.deallocate(p, 10);      // 只释放内存，不析构

分离的意义：

reserve：只 allocate，不 construct——所以 reserve 快。
pop_back：只 destroy，不 deallocate——所以 pop_back 快。
自定义分配器只需重写 allocate/deallocate，construct/destroy 有默认行为。

为什么不直接存 YUV 图片序列？

Mon, 01 Jan 0001 00:00:00 +0000

一、数据量对比

void print_bitrate(int width, int height, int fps) {
    auto yuv420_size = [](int w, int h) {
        return w * h * 3 / 2;  // Y + UV/4 + UV/4
    };

    int frame_bytes = yuv420_size(width, height);
    int second_bytes = frame_bytes * fps;
    int minute_bytes = second_bytes * 60;
    int hour_bytes   = minute_bytes * 60;

    auto to_mb = [](int b) { return b / 1024 / 1024; };

    std::cout << width << "x" << height << " @" << fps << "fps YUV420:\n"
              << "  一帧:    " << to_mb(frame_bytes)   << " MB\n"
              << "  一秒:    " << to_mb(second_bytes)  << " MB\n"
              << "  一分:    " << to_mb(minute_bytes)  << " MB\n"
              << "  一小时:  " << to_mb(hour_bytes)    << " MB ≈ "
              << to_mb(hour_bytes) / 1024 << " GB\n";
}

// print_bitrate(1920, 1080, 60);
// 输出：
//   一帧:     3 MB
//   一秒:     180 MB
//   一分:     10800 MB
//   一小时:   648000 MB ≈ 633 GB
// 一小时就要 633GB，不可接受。
// 编码后（H.264 10Mbps）：一小时 ≈ 4.5 GB → 压缩比约 140:1

二、编码器怎么做到的？

编码器利用了两个层面的冗余：

传统 IO 的四次拷贝与上下文切换痛点

Mon, 01 Jan 0001 00:00:00 +0000

1. 传统 IO 读取一个文件的完整硬件旅程

以 Linux 上执行 read(fd, buf, count) 为例，从应用程序发出指令到数据到达用户缓冲区，硬件层面经历了以下阶段：

[用户态应用] 
    │
    ├─① 执行 syscall (int 0x80 / syscall 指令)
    │   └─ CPU 从 Ring 3 切换到 Ring 0，陷入内核
    │
    ▼
[内核 VFS 层]
    │
    ├─② 检查文件是否已在页缓存 (Page Cache) 中
    │   ├─ 命中 → 直接跳到 ④
    │   └─ 未命中 → 触发缺页中断，进入 ③
    │
    ▼
[块设备层 / 驱动]
    │
    ├─③ 构造 I/O 请求，提交给磁盘驱动程序
    │   └─ 驱动配置 DMA 控制器，告诉它：把磁盘扇区数据搬运到主存 [物理地址]
    │
    ▼
[硬件层]
    │
    ├─④ 磁盘控制器通过 DMA 将数据直接写入主存（内核缓冲区）
    │   └─ DMA 传输期间，CPU 完全空闲，可以执行其他任务
    │   └─ 传输完成后，磁盘控制器发出硬中断 (IRQ)
    │
    ▼
[内核中断处理]
    │
    ├─⑤ 中断处理程序唤醒等待该 I/O 的进程
    │   └─ 将数据从页缓存 (内核空间) CPU 拷贝到用户缓冲区 (用户空间)
    │
    ▼
[用户态]
    │
    ├─⑥ syscall 返回，CPU 从 Ring 0 切回 Ring 3
    └─ 用户程序拿到数据

2. 四次拷贝的真正定义（按硬件参与者区分）

编号	拷贝路径	执行者	是否消耗 CPU 周期	数据形态
①	磁盘扇区 → 主存（内核缓冲区）	DMA 控制器	❌ 不消耗	物理内存写入
②	内核缓冲区 → 用户缓冲区	CPU（`memcpy`）	✅ 消耗	物理内存→物理内存
③	用户缓冲区 → Socket 缓冲区（内核）	CPU（`memcpy`）	✅ 消耗	物理内存→物理内存
④	Socket 缓冲区 → 网卡 DMA 缓冲区	DMA 控制器	❌ 不消耗	主存→网卡缓存

结论：

全局队列的瓶颈

Mon, 01 Jan 0001 00:00:00 +0000

第一阶段实现的线程池有一个全局任务队列，所有线程共享一个 mutex。

当任务数量很大、每个任务执行时间极短时：

线程 1:          线程 2:          线程 3:
🔒 lock()        🔒 lock()        🔒 lock() ← 等着
| 取任务          | 等着             | 等着
🔓 unlock()       ...               ...
执行任务          🔒 lock()         🔒 lock()
                  | 取任务           | 等着
                  🔓 unlock()        ...
                  执行任务           🔒 lock()
                                     ...

perf 表现（100M 个微任务，每个 1μs）：

context-switches: 几乎为 0（没有阻塞）
但：mutex 的 cache line bouncing 很严重
cache-misses: 非常高（mutex 在核心间飞来飞去）

当任务极短时，取任务的锁竞争比任务本身还耗时。

内存分配器

Mon, 01 Jan 0001 00:00:00 +0000

好的，我们从第一个盲区开始补齐：内存分配器（Memory Allocator）。

这是无锁编程中最容易被忽视的"隐藏杀手"。你精心设计了一个无锁队列，所有 CAS 操作都完美，结果发现性能还是上不去——很可能是 new 和 delete 在背后拖了后腿。

1. 问题：`malloc` 是个"全局锁"

当我们调用 new / delete（底层是 malloc / free）时，背后是一个全局堆管理器在干活。

[线程A] new 对象 → 进入 malloc()
                    │
                    ▼
              [全局堆锁] ← 线程A 拿到锁，开始分配内存
                    │
[线程B] new 对象 → 进入 malloc() → 等待全局堆锁 → 阻塞！
[线程C] new 对象 → 进入 malloc() → 等待全局堆锁 → 阻塞！

硬件视角：

全局堆锁本质上是一个 Mutex（或自旋锁），多个线程争抢时会产生缓存行乒乓（MESI RFO）。
每次 malloc/free 都可能触发系统调用（brk / mmap），陷入内核态。
频繁分配/释放时，锁开销可能超过业务逻辑本身。

结论：无锁数据结构本身很快，但 malloc 的全局锁会让你的多线程程序退化成串行执行。

2. 解决方案：Per-CPU / Per-Thread 内存池

核心思想：让每个线程/核心拥有自己独立的内存池，分配时无需加锁。

基于优先队列的定时器

Mon, 01 Jan 0001 00:00:00 +0000

一、核心设计

定时器需要一个线程不断检查：“有哪些定时任务到期了？”

用 std::priority_queue（最小堆），堆顶是最快到期的任务。

struct TimerTask {
    std::chrono::steady_clock::time_point expiry;
    std::function<void()> callback;
    std::shared_ptr<bool> cancelled;  // 用于取消

    bool operator>(const TimerTask& other) const {
        return expiry > other.expiry;  // 小顶堆：最早到期的在堆顶
    }
};

class Timer {
    std::priority_queue<TimerTask, std::vector<TimerTask>, std::greater<>> tasks_;
    std::mutex mtx_;
    std::condition_variable cv_;
    bool stop_ = false;
    std::thread worker_;

public:
    Timer() {
        worker_ = std::thread([this] { worker_loop(); });
    }

    ~Timer() {
        {
            std::lock_guard<std::mutex> lock(mtx_);
            stop_ = true;
        }
        cv_.notify_one();
        worker_.join();
    }

    // 延迟 delay 后执行 callback
    // 返回的 TimerId 可用于取消
    std::shared_ptr<bool> addTimer(std::chrono::milliseconds delay,
                                    std::function<void()> callback) {
        auto cancelled = std::make_shared<bool>(false);
        TimerTask task{
            std::chrono::steady_clock::now() + delay,
            std::move(callback),
            cancelled
        };

        {
            std::lock_guard<std::mutex> lock(mtx_);
            tasks_.push(std::move(task));
        }
        cv_.notify_one();  // 唤醒定时线程，重新检查堆顶

        return cancelled;
    }

private:
    void worker_loop() {
        while (!stop_) {
            std::unique_lock<std::mutex> lock(mtx_);

            if (tasks_.empty()) {
                cv_.wait(lock, [this] { return stop_ || !tasks_.empty(); });
                continue;
            }

            auto now = std::chrono::steady_clock::now();
            auto& top = tasks_.top();

            if (now >= top.expiry) {
                // 到期
                auto task = std::move(tasks_.top());
                tasks_.pop();
                lock.unlock();  // 执行回调前解锁

                if (!*task.cancelled) {
                    task.callback();
                }
            } else {
                // 没到期，等待到最早到期的时刻
                cv_.wait_until(lock, top.expiry);
            }
        }
    }
};

二、关键点

主要数据结构：最小堆（priority_queue）
堆顶：最快到期的定时任务

线程循环：
   1. 检查堆顶是否到期 → 到期就执行并弹出
   2. 没到期就 wait_until 到到期时刻（精确定时）
   3. 有新任务加入时 notify 唤醒，重新检查

时间复杂度：

基本用法

Mon, 01 Jan 0001 00:00:00 +0000

一、安装

git clone https://github.com/google/benchmark.git
cd benchmark
cmake -DCMAKE_BUILD_TYPE=Release -DBENCHMARK_DOWNLOAD_DEPENDENCIES=ON
make -j4
sudo make install

二、编写第一个基准测试

#include <benchmark/benchmark.h>
#include <vector>
#include <numeric>

// 测试 vector 求和的不同方式
static void BM_Sum_Loop(benchmark::State& state) {
    std::vector<int> v(state.range(0));
    std::iota(v.begin(), v.end(), 0);

    for (auto _ : state) {
        long long sum = 0;
        for (int x : v) sum += x;
        benchmark::DoNotOptimize(sum);
    }
}
BENCHMARK(BM_Sum_Loop)->Arg(1000)->Arg(10000)->Arg(100000);

static void BM_Sum_STL(benchmark::State& state) {
    std::vector<int> v(state.range(0));
    std::iota(v.begin(), v.end(), 0);

    for (auto _ : state) {
        auto sum = std::accumulate(v.begin(), v.end(), 0LL);
        benchmark::DoNotOptimize(sum);
    }
}
BENCHMARK(BM_Sum_STL)->Arg(1000)->Arg(10000)->Arg(100000);

BENCHMARK_MAIN();

# 编译并运行
g++ -O2 -o bench bench.cpp -lbenchmark
./bench

# 输出示例：
# --------------------------------------------------------------
# Benchmark              Time     CPU  Iterations
# --------------------------------------------------------------
# BM_Sum_Loop/1000     432 ns  431 ns    1623905
# BM_Sum_Loop/10000   4123 ns 4120 ns     169853
# BM_Sum_Loop/100000 41234 ns 41230 ns     16985
# BM_STL_Sum/1000      428 ns  427 ns    1638281
# BM_STL_Sum/10000    4128 ns 4125 ns     169720
# BM_STL_Sum/100000  41280 ns 41270 ns     16972

# 分析：for 循环和 std::accumulate 几乎没区别（编译器优化到一样了）

三、`for (auto _ : state)` 的作用

// 这个循环框架帮做了 3 件事：
static void BM_Example(benchmark::State& state) {
    // ① 初始化（只在测试开始前执行一次）
    std::vector<int> data(1000000);

    // ② 被测代码在循环中重复执行
    for (auto _ : state) {
        // benchmark 框架会：
        //   - 自动计算执行了多少次以达到统计显著性
        //   - 排除循环本身的时间开销
        //   - 多次运行取平均值
        do_something(data);
    }

    // ③ 这里的代码只有在所有循环结束后执行一次
    // 可以在测试结束时做结果校验
}

多线程交替打印与协调

Mon, 01 Jan 0001 00:00:00 +0000

一、交替打印 FooBar（LeetCode 1115）

问题：两个线程交替打印 “foo” 和 “bar”，共 N 次。保证 foo 总是在 bar 之前。

解法 1：条件变量（std::condition_variable）

思路：

线程 A (打印 foo)    线程 B (打印 bar)
    │                     │
    │ wait(turn==foo)     │ wait(turn==bar)
    │ print foo           │ print bar
    │ turn=bar            │ turn=foo
    │ notify B            │ notify A
    │ ...                 │ ...

整体操作流程（条件变量版）：

初始化：创建互斥锁 mtx、条件变量 cv、布尔标志 foo_turn = true（表示当前该打印 foo）。
foo 线程：循环 N 次：获取锁 → cv.wait 等待 foo_turn == true（如果为 false 则阻塞释放锁）→ 打印 foo → 设置 foo_turn = false → cv.notify_one 唤醒 bar 线程 → 释放锁。
bar 线程：循环 N 次：获取锁 → cv.wait 等待 foo_turn == false（如果为 true 则阻塞）→ 打印 bar → 设置 foo_turn = true → cv.notify_one 唤醒 foo 线程 → 释放锁。
核心机制：cv.wait 在阻塞前会自动释放锁，被唤醒后重新获取锁并检查条件，保证"foo 总是在 bar 之前"的交替顺序。

class FooBar {
private:
    int n;
    mutex mtx;
    condition_variable cv;
    bool foo_turn = true;  // true: 该打印 foo, false: 该打印 bar

public:
    FooBar(int n) : n(n) {}

    void foo(function<void()> printFoo) {
        for (int i = 0; i < n; i++) {
            unique_lock<mutex> lock(mtx);          // ① 获取互斥锁
            cv.wait(lock, [this] { return foo_turn; });// ② 等待轮到 foo
                                                   //    如果 foo_turn==false，
                                                   //    释放锁并阻塞，被唤醒后重查条件
            printFoo();                            // ③ 打印 foo
            foo_turn = false;                      // ④ 标记轮到 bar
            cv.notify_one();                       // ⑤ 唤醒 bar 线程
        }                                          // ⑥ 解锁（unique_lock 析构）
    }

    void bar(function<void()> printBar) {
        for (int i = 0; i < n; i++) {
            unique_lock<mutex> lock(mtx);          // ① 获取互斥锁
            cv.wait(lock, [this] { return !foo_turn; });// ② 等待轮到 bar
            printBar();                            // ③ 打印 bar
            foo_turn = true;                       // ④ 标记轮到 foo
            cv.notify_one();                       // ⑤ 唤醒 foo 线程
        }
    }
};

关键理解：

多线程调试

Mon, 01 Jan 0001 00:00:00 +0000

一、查看和控制线程

# 假设有一个死锁的多线程程序

(gdb) info threads
  Id   Target Id         Frame
  1    Thread 0x7f1 main() at main.cpp:10
  2    Thread 0x7f2 worker() at worker.cpp:23
  3    Thread 0x7f3 worker() at worker.cpp:45   ← 当前线程
* 4    Thread 0x7f4 worker() at worker.cpp:23

# * 号表示当前线程（正在调试的线程）
# 切换到线程 2：
(gdb) thread 2
[Switching to thread 2]
#0  worker() at worker.cpp:23
23        lock_b.lock();  // 线程 2 正在等 lock_b

# 看所有线程的调用栈：
(gdb) thread apply all bt

Thread 1 (main):
  #0 main() at main.cpp:10

Thread 2 (worker):
  #0  worker() at worker.cpp:23   ← 等 lock_b
  #1  std::thread::_Invoke() ...

Thread 3 (worker):
  #0  worker() at worker.cpp:30   ← 持有 lock_a
  #1  std::thread::_Invoke() ...

Thread 4 (worker):
  #0  worker() at worker.cpp:23   ← 等 lock_a
  #1  std::thread::_Invoke() ...

# 看到这个调用栈就知道死锁了：
# Thread 3 持有 lock_a，等 lock_b
# Thread 2 持有 lock_b，等 lock_a
# → 典型的 ABBA 死锁

二、调试无锁编程中的 Bug

无锁 Bug 的特点：不是每次都能复现，调试器里跑可能就不出现了。

完整调度器

Mon, 01 Jan 0001 00:00:00 +0000

class Scheduler {
    ThreadPool pool_{4};       // 工作线程池
    Timer timer_;              // 定时器

public:
    // 立即执行（线程池的任务）
    template <typename F>
    auto execute(F&& f) {
        return pool_.enqueue(std::forward<F>(f));
    }

    // 延迟执行（先经过定时器，到时间后丢给线程池）
    template <typename F>
    auto executeAfter(std::chrono::milliseconds delay, F&& f) {
        using ReturnType = std::invoke_result_t<F>;
        auto promise = std::make_shared<std::promise<ReturnType>>();
        auto future = promise->get_future();

        timer_.addTimer(delay, [this, f = std::forward<F>(f), promise]() mutable {
            pool_.enqueue([f = std::move(f), promise]() mutable {
                if constexpr (std::is_void_v<ReturnType>) {
                    f();
                    promise->set_value();
                } else {
                    promise->set_value(f());
                }
            });
        });

        return future;
    }

    // 周期执行
    template <typename F>
    void executeEvery(std::chrono::milliseconds interval, F&& f) {
        timer_.addTimer(interval, interval, [this, f = std::forward<F>(f)]() mutable {
            pool_.enqueue(f);
        });
    }
};

容器格式的作用

Mon, 01 Jan 0001 00:00:00 +0000

视频编码器输出的是 H.264 裸流（纯视频数据），音频编码器输出的是 AAC 裸流（纯音频数据）。容器格式把视频轨 + 音频轨 + 字幕 + 元数据 + 时间戳打包成一个文件：

H.264 视频流 ─┐
               ├──→ MP4 / FLV / TS / MKV 容器
AAC 音频流   ──┘      │
                      ├── 时间戳（PTS/DTS）
                      ├── 每帧的时长
                      ├── 分辨率、帧率
                      └── 字幕、章节等元数据

工厂模式

Mon, 01 Jan 0001 00:00:00 +0000

一、为什么需要工厂？（什么时候用）

场景：你有一个基类 Product，多个派生类 ConcreteProductA / ConcreteProductB。客户端要创建产品，但不知道具体类型。

不用工厂：

std::unique_ptr<Product> createProduct(const std::string& type) {
    if (type == "A") return std::make_unique<ConcreteProductA>();
    if (type == "B") return std::make_unique<ConcreteProductB>();
    return nullptr;
}
// ↑ 每次加新产品都要改这个函数，违反了"开闭原则"

二、注册表工厂（最实用的工厂写法）

class ProductFactory {
    // 用 unique_ptr 返回，所有权清晰
    using Creator = std::function<std::unique_ptr<Product>()>;
    std::unordered_map<std::string, Creator> registry_;

public:
    void register_type(const std::string& type, Creator creator) {
        registry_[type] = std::move(creator);
    }

    std::unique_ptr<Product> create(const std::string& type) {
        auto it = registry_.find(type);
        if (it == registry_.end()) return nullptr;
        return it->second();  // 调用注册的创建函数
    }
};

// 使用
ProductFactory factory;
factory.register_type("Circle", [] { return std::make_unique<Circle>(); });
factory.register_type("Square", [] { return std::make_unique<Square>(); });

auto p = factory.create("Circle");  // unique_ptr<Product>

好处：

快慢指针与对撞指针

Mon, 01 Jan 0001 00:00:00 +0000

一、快慢指针——解决"环"与"中间位置"

核心思想：两个指针从同一位置出发，一个走得快（每次两步），一个走得慢（每次一步）。

场景 1：检测环形链表（LeetCode 141）

问题：给你一个链表，判断是否有环。

为什么快慢指针能检测环？

想象两个人在环形操场上跑步。快的人跑两步，慢的人跑一步。如果有环，快的人最终会"套圈"慢的人（再次相遇）。如果没环，快的人先到终点（nullptr）。

不带环的链表：
1 → 2 → 3 → 4 → 5 → nullptr
快指针先到 nullptr → 无环

带环的链表：
1 → 2 → 3 → 4 → 5 → 3（回到 3）
快指针走两步，慢指针走一步：
1: 快=3, 慢=2
2: 快=5, 慢=3
3: 快=3, 慢=4  ← 回到 3 了！
4: 快=5, 慢=5  ← 相遇！有环

整体操作流程：

边界检查：如果 head 为空或只有一个节点，不可能有环，直接返回 false。
初始化：快慢两个指针都指向链表头节点 head。
遍历移动：每次循环中，慢指针向前走一步，快指针向前走两步。
相遇检测：每走一步后，检查两个指针是否指向同一节点。如果是，说明快指针"套圈"了慢指针，链表有环，返回 true。
终止条件：如果快指针到达了链表末尾（fast == nullptr 或 fast->next == nullptr），说明链表无环，返回 false。

struct ListNode {
    int val;
    ListNode* next;
    ListNode(int x) : val(x), next(nullptr) {}
};

bool hasCycle(ListNode* head) {
    if (!head || !head->next) return false;      // ① 空链表或单节点 → 无环

    ListNode* slow = head;                        // ② 慢指针从 head 出发
    ListNode* fast = head;                        // ③ 快指针也从 head 出发

    while (fast && fast->next) {                  // ④ 快指针没到终点就继续
        slow = slow->next;                        // ⑤ 慢指针走一步
        fast = fast->next->next;                  // ⑥ 快指针走两步

        if (slow == fast) {                       // ⑦ 快慢相遇 → 有环
            return true;
        }
    }

    return false;                                 // ⑧ 快指针到尽头 → 无环
}

时间复杂度：$O(N)$。有环时最多走一圈半就相遇；无环时 fast 先到终点。 空间复杂度：$O(1)$。只用两个指针。

快速排序（QuickSort）

Mon, 01 Jan 0001 00:00:00 +0000

一、核心思想：分治 + 分区

快速排序的流程：选一个 pivot（基准值），把小于 pivot 的放左边，大于的放右边。然后递归对左右两部分排序。

原始数组：[3, 7, 8, 5, 2, 1, 9, 5, 4]
选 pivot = 4（最后一个元素）

分区后：
小于 4 的部分 | pivot=4 | 大于等于 4 的部分
[3, 2, 1]    |   4    | [7, 8, 5, 9, 5]

递归排序左边 [3, 2, 1] 和右边 [7, 8, 5, 9, 5]

二、Lomuto 分区（最简单，面试首选）

整体操作流程（Lomuto 分区）：

选基准：取最右侧元素 nums[right] 作为 pivot。
双指针扫描：i 指向"小于区域的边界"，j 从左到右扫描。
交换：如果 nums[j] < pivot，将它与 nums[i] 交换，i++（扩大小于区域）。
归位 pivot：扫描结束后，将 pivot（nums[right]）交换到 nums[i] 位置。
返回 pivot 索引：此时 i 就是 pivot 的正确位置。

整体操作流程（quickSort 递归）：

总线锁（Lock Asserted）与缓存锁（Cache Locking）

Mon, 01 Jan 0001 00:00:00 +0000

这个问题问到了并发编程的根基，也是理解无锁编程（Lock-Free）和内存模型（Memory Model）的前提。为了让你直观理解，我们先从“为什么冲突”说起，再深入到硬件是如何“劝架”的。

1. 为什么多核 CPU 同时改一个内存会冲突？

先看一个C++经典场景：两个线程分别在不同核心上执行 global_var++（读-改-写操作）。

冲突的本质不是“同时写入”，而是“基于过期数据的写入”。

为了提速，每个CPU核心都有自己的L1/L2缓存。核心操作数据时，先在缓存里改，之后再同步回主存。

时刻1：核心A和核心B都读取 global_var = 10 到各自的缓存。
时刻2：核心A计算 10+1=11，将 11 写回主存。
时刻3：核心B依然拿着过期的10，计算 10+1=11，将 11 写回主存。

结果：明明加了两次，结果却是11（应该是12）。这就是经典的缓存一致性问题。如果不加锁，最终结果取决于谁最后写（丢失了A的写入）。

2. 硬件如何“锁住”？—— 总线锁（Lock Asserted）

在最早期的多核CPU（或者访问未缓存的内存地址）中，硬件使用粗暴但有效的办法。

原理：CPU在执行特定指令时，会在其前端总线（FSB）上拉高一个名为 LOCK# 的引脚信号（即断言Lock Asserted）。

演示图（概念）：

[ 核心A ] ----( 请求锁总线 )---> [ 总线仲裁器 ]
[ 核心B ] ----( 等待... )------> [ 总线仲裁器 ]
              |
              v
        +--------------+
        |  LOCK# 信号  |  <--- 只有持有者能访问主存
        +--------------+
              |
[ 核心A ] ----> 执行 read-modify-write (原子性) ----> 释放 LOCK#
[ 核心B ] <---- 获得总线使用权 <---- 继续执行

特点：

悲观锁（Mutex）与乐观锁（CAS 自旋）的底层成本对比

Mon, 01 Jan 0001 00:00:00 +0000

欢迎进入第三阶段：用户态并发！这是区分"普通程序员"和"底层系统工程师"的分水岭。你现在的目标很明确：彻底摆脱内核态的重量级锁，在用户态用自旋逻辑实现极速并发。

我们先解剖悲观锁 vs 乐观锁的硬件成本和软件代价，让你亲眼看到一次Mutex::lock()背后有多痛。

1. 悲观锁（Mutex）：内核态的"断崖式"切换

执行流程（完整链路）

[ 线程A尝试获取锁 ]

1. 用户态执行 mutex.lock()
   ↓
2. 尝试原子CAS抢锁 (快速路径)
   ├─ 成功 → 进入临界区 (约 20-50 ns)
   └─ 失败 → 进入慢速路径
       ↓
3. 系统调用 (syscall) → 陷入内核态 (约 50-100 ns)
   ↓
4. 内核将线程A放入等待队列，状态改为 TASK_UNINTERRUPTIBLE
   ↓
5. 触发调度器 (Schedule) → 保存当前线程上下文 (寄存器、PC、栈指针)
   ↓ (约 100-200 ns)
6. 内核选择下一个线程B执行
   ↓
7. 恢复线程B的上下文 → 切换CR3寄存器 (刷新TLB)
   ↓ (约 200-500 ns)
8. 返回用户态执行线程B
   ↓
总耗时: 约 1-5 微秒 (μs) 
如果锁持有者执行时间短 (如 1μs)，内核切换开销占比 > 80%！

上下文切换到底在"切"什么？

; 内核保存现场 (简化版)
push rax, rbx, rcx, rdx, rsi, rdi, rbp, r8-r15  ; 保存通用寄存器 (16个×8字节)
push rip, rsp, rflags                             ; 保存指令指针、栈指针、状态寄存器
mov cr3, [new_thread_page_table]                 ; 切换页表 → 清空TLB (性能杀手！)
; 恢复新线程现场
pop ...

关键代价：

树的层序遍历与 BFS

Mon, 01 Jan 0001 00:00:00 +0000

一、BFS 层序遍历模板（LeetCode 102）

问题：按层打印二叉树，每层一个 vector。

思路：

     3
   /   \
  9    20
      /  \
     15   7

层序遍历结果：
[
  [3],       // 第 0 层
  [9, 20],   // 第 1 层
  [15, 7]    // 第 2 层
]

整体操作流程：

初始化：如果根节点为空，返回空结果。创建队列并将根节点入队。
层循环：当队列不为空时，记录当前层的节点数 level_size = q.size()。
节点循环：从队列中弹出 level_size 个节点：
- 将节点值加入当前层结果。
- 将节点的左右子节点入队（这些属于下一层）。
保存结果：将当前层结果加入最终结果集。
重复：直到队列为空，所有层遍历完毕。

vector<vector<int>> levelOrder(TreeNode* root) {
    if (!root) return {};                          // ① 空树 → 空结果

    vector<vector<int>> result;
    queue<TreeNode*> q;
    q.push(root);                                  // ② 根节点入队

    while (!q.empty()) {
        int level_size = q.size();                 // ③ 记录当前层节点数
        vector<int> level;

        for (int i = 0; i < level_size; i++) {     // ④ 遍历当前层的所有节点
            TreeNode* node = q.front();
            q.pop();                                // ⑤ 弹出队首节点

            level.push_back(node->val);             // ⑥ 记录节点值

            if (node->left)  q.push(node->left);    // ⑦ 左子节点入队（下一层）
            if (node->right) q.push(node->right);   // ⑧ 右子节点入队（下一层）
        }

        result.push_back(std::move(level));         // ⑨ 保存当前层结果
    }

    return result;
}

关键点：int level_size = q.size() 在循环之前记录当前层大小，保证 for 循环只处理当前层的节点，不混入下一层。

泛型编程与模板特化

Mon, 01 Jan 0001 00:00:00 +0000

一、类模板全特化与偏特化

// 主模板
template <typename T>
struct TypeInfo {
    static constexpr const char* name = "unknown";
};

// 全特化：T = int
template <>
struct TypeInfo<int> {
    static constexpr const char* name = "int";
};

// 偏特化：T*（对所有指针类型）
template <typename T>
struct TypeInfo<T*> {
    static constexpr const char* name = "pointer";
};

// 偏特化：const T（对所有 const 类型）
template <typename T>
struct TypeInfo<const T> {
    static constexpr const char* name = "const";
};

// 使用
TypeInfo<double>::name;     // "unknown"（主模板）
TypeInfo<int>::name;        // "int"（全特化）
TypeInfo<float*>::name;     // "pointer"（偏特化）
TypeInfo<const int>::name;  // "const"（偏特化）

面试题：“为什么高性能库经常针对特定类型做全特化？”

因为通用实现（如逐元素循环）对 CPU 不友好，全特化可以换用 SIMD 指令（如 _mm256_loadu_si256）一次处理 8 个 int，速度提升 8 倍。

二、函数模板只能全特化，不能偏特化

template <typename T>
void func(T x) {}

template <>               // ✅ 函数全特化
void func<int>(int x) {}

template <typename T>
void func<T*>(T* x) {}    // ❌ 函数不能偏特化！编译错误

替代方案：用函数重载 + std::enable_if 或 if constexpr 实现类似效果。

火焰图生成流程

Mon, 01 Jan 0001 00:00:00 +0000

一、三步生成火焰图

# 第一步：采样
perf record -F 99 -g ./my_program

# 第二步：转换为火焰图工具需要的格式
perf script > out.perf

# 第三步：生成 SVG 火焰图
git clone https://github.com/brendangregg/FlameGraph
FlameGraph/stackcollapse-perf.pl out.perf > out.folded
FlameGraph/flamegraph.pl out.folded > flame.svg

# 用浏览器打开 flame.svg

二、火焰图解读方法

火焰图的阅读方向是"自底向上"：
  底部：调用链的起点（main、线程入口函数）
  顶部：CPU 正在执行的函数

x 轴：采样数量（不是时间）
  → 一个函数条越宽，它占的 CPU 时间越多

y 轴：调用栈深度
  → 顶层函数是被调用的，底层是调用者

颜色：没有特殊含义，随机分配（但也有风格按函数名 hash 上色）

平顶（顶部宽，底部窄）：
  这个函数本身的计算量大
  ┌───────────────────┐
  │  compute_dct       │ ← 宽 → 大部分时间花在 compute_dct 里面
  └───────────────────┘
       ↑ process_frame
       ↑ main

尖顶（顶部窄，底部宽）：
  大部分时间花在子函数中，当前函数只是调用了别人
  ┌──┐
  │f1│ ← 窄 → f1 本身不花时间，它调用的子函数花时间
  └──┘
   ↑ f2
   ↑ f3

三、结合自己的项目的解读示例

假设你的 SimpleAsyncLogger 生成火焰图如下：

底部（main）:
  main  →  AsyncWriter::run  →  io_uring_enter  ← 宽
                              →  memcpy           ← 窄
                              →  TcpClient::send  ← 中等

分析：
  io_uring_enter 很宽 → 大部分时间花在等待 I/O 完成（正常，异步日志就是等 I/O）
  memcpy 很窄 → 你的 SPSC 零拷贝设计是有效的
  TcpClient::send 中等 → 网络可能成为瓶颈，考虑更大的发送缓冲区

如果 memcpy 很宽 → 说明 SPSC 的零拷贝没有生效，检查是不是走了拷贝路径。
如果 TcpClient::send 很宽 → 网络带宽或 buffer 需要调优。

策略模式——用 std::function 替代虚类

Mon, 01 Jan 0001 00:00:00 +0000

一、问题场景

传统策略模式（GoF 风格）：

// 抽象策略类
struct CompressionStrategy {
    virtual std::vector<char> compress(const std::vector<char>&) = 0;
    virtual ~CompressionStrategy() = default;
};

struct GzipStrategy : CompressionStrategy { ... };
struct ZstdStrategy : CompressionStrategy { ... };

// 使用策略
class Compressor {
    std::unique_ptr<CompressionStrategy> strategy_;
public:
    void setStrategy(std::unique_ptr<CompressionStrategy> s) {
        strategy_ = std::move(s);
    }
};

问题：用户必须继承 CompressionStrategy、必须传 unique_ptr、必须处理所有权转移。

二、现代写法

class Compressor {
    // 用 std::function 替代虚基类
    std::function<std::vector<char>(const std::vector<char>&)> strategy_;

public:
    // 接受任何可调用对象：lambda、函数指针、函数对象
    void setStrategy(std::function<std::vector<char>(const std::vector<char>&)> s) {
        strategy_ = std::move(s);
    }

    std::vector<char> compress(const std::vector<char>& data) {
        if (!strategy_) throw std::runtime_error("no strategy set");
        return strategy_(data);
    }
};

// 使用——用户不需要继承任何东西
Compressor comp;
comp.setStrategy([](const auto& data) -> std::vector<char> {
    // 在这里写 gzip 压缩逻辑
    return data;
});

现代写法 vs 传统写法：

线程池核心设计

Mon, 01 Jan 0001 00:00:00 +0000

一、为什么需要线程池？

不用线程池：来一个任务就 new thread()，做完就 join()。问题是线程创建/销毁开销很大（~10μs），且大量线程同时运行导致上下文切换爆炸。

线程池的方案：预先创建一组线程，它们空闲时等待任务，任务来了就执行。复用线程，避免创建销毁开销。

二、最小实现

class ThreadPool {
    std::vector<std::thread> workers_;
    std::queue<std::function<void()>> tasks_;
    std::mutex mtx_;
    std::condition_variable cv_;
    bool stop_ = false;

public:
    ThreadPool(size_t threads) {
        for (size_t i = 0; i < threads; i++) {
            workers_.emplace_back([this] {
                while (true) {
                    std::function<void()> task;
                    {
                        std::unique_lock<std::mutex> lock(mtx_);
                        cv_.wait(lock, [this] {
                            return stop_ || !tasks_.empty();
                        });
                        if (stop_ && tasks_.empty()) return;
                        task = std::move(tasks_.front());
                        tasks_.pop();
                    }
                    task();  // 在锁外执行任务！
                }
            });
        }
    }

    template <typename F>
    void enqueue(F&& f) {
        {
            std::lock_guard<std::mutex> lock(mtx_);
            tasks_.push(std::forward<F>(f));
        }
        cv_.notify_one();
    }

    ~ThreadPool() {
        {
            std::lock_guard<std::mutex> lock(mtx_);
            stop_ = true;
        }
        cv_.notify_all();
        for (auto& w : workers_) {
            w.join();
        }
    }
};

三、关键设计决策

1. 为什么 task() 要在锁外执行？

经典二分搜索

Mon, 01 Jan 0001 00:00:00 +0000

一、核心思想——每次排除一半

前提：数组必须有序。

在有序数组 [1, 3, 5, 7, 9, 11, 13, 15] 中找 7：

[1, 3, 5, 7, 9, 11, 13, 15]  left=0, right=7, mid=3 → nums[3]=7 ✅ 找到
                         ↑mid

如果找 6：
[1, 3, 5, 7, 9, 11, 13, 15]  left=0, right=7, mid=3 → nums[3]=7 >6
 left=0, right=2, mid=1 → nums[1]=3 <6
 left=2, right=2, mid=2 → nums[2]=5 <6
 left=3, right=2 → 退出，找不到

二、两种区间写法

面试高频考点：左闭右闭 [left, right] 和 左闭右开 [left, right) 的区别。

解封装流程（Demuxing）

Mon, 01 Jan 0001 00:00:00 +0000

一、从文件读取 packet 到解码出 frame 的完整流程

extern "C" {
#include <libavformat/avformat.h>
#include <libavcodec/avcodec.h>
#include <libswscale/swscale.h>
#include <libavutil/imgutils.h>
}

// 完整的一个 demux + decode 流程
// 从视频文件中读取每一帧解码为 YUV420P 原始数据

struct VideoDecoder {
    AVFormatContext* fmt_ctx = nullptr;
    AVCodecContext*  dec_ctx = nullptr;
    int video_stream_idx = -1;
};

bool open_file(VideoDecoder& dec, const char* filename) {
    // ① 打开文件并读取头部信息
    if (avformat_open_input(&dec.fmt_ctx, filename, nullptr, nullptr) < 0)
        return false;

    // ② 读取流信息（找到视频流的索引和编码器参数）
    if (avformat_find_stream_info(dec.fmt_ctx, nullptr) < 0)
        return false;

    // ③ 找到第一个视频流
    for (unsigned i = 0; i < dec.fmt_ctx->nb_streams; i++) {
        if (dec.fmt_ctx->streams[i]->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
            dec.video_stream_idx = i;
            break;
        }
    }
    if (dec.video_stream_idx < 0) return false;

    // ④ 找到对应的解码器并打开
    const AVCodec* codec = avcodec_find_decoder(
        dec.fmt_ctx->streams[dec.video_stream_idx]->codecpar->codec_id);
    if (!codec) return false;

    dec.dec_ctx = avcodec_alloc_context3(codec);
    avcodec_parameters_to_context(dec.dec_ctx,
        dec.fmt_ctx->streams[dec.video_stream_idx]->codecpar);
    avcodec_open2(dec.dec_ctx, codec, nullptr);

    return true;
}

bool decode_frame(VideoDecoder& dec, AVFrame* frame) {
    AVPacket* packet = av_packet_alloc();

    while (av_read_frame(dec.fmt_ctx, packet) >= 0) {
        if (packet->stream_index == dec.video_stream_idx) {
            // ⑤ 把 packet 送入解码器
            if (avcodec_send_packet(dec.dec_ctx, packet) == 0) {
                // ⑥ 从解码器取出解码后的 frame
                if (avcodec_receive_frame(dec.dec_ctx, frame) == 0) {
                    av_packet_free(&packet);
                    return true;  // 成功解码一帧
                }
            }
        }
        av_packet_unref(packet);
    }

    av_packet_free(&packet);
    return false;  // 文件读完
}

二、关于 AVFrame 的重要理解

// 解码后得到的 AVFrame 包含：
// frame->data[0]  → Y 平面数据指针
// frame->data[1]  → U 平面数据指针
// frame->data[2]  → V 平面数据指针（NV12 时 data[1] 是 UV 交错）
//
// frame->linesize[0] → Y 平面的 stride
// frame->linesize[1] → U 平面的 stride
// frame->linesize[2] → V 平面的 stride
//
// frame->pts → 显示时间戳（毫秒单位 × time_base）
// frame->pict_type → AV_PICTURE_TYPE_I / P / B
//
// frame->width, frame->height → 分辨率
// frame->format → 像素格式 AV_PIX_FMT_YUV420P / AV_PIX_FMT_NV12

// ❌ 常见错误：假设 data 是连续的内存块
for (int y = 0; y < height; y++) {
    for (int x = 0; x < width; x++) {
        uint8_t y_val = frame->data[0][y * frame->linesize[0] + x];
    }
}
// ✅ linesize 可能不等于 width（有 padding），必须用 linesize

问题

Mon, 01 Jan 0001 00:00:00 +0000

目前 enqueue(f) 无法获取返回值。如果任务返回一个 int，调用者想知道结果：

int compute(int x) { return x * x; }

pool.enqueue([&] {
    int result = compute(42);
    // 怎么把 result 传给调用者？
});

解决方案：std::packaged_task + std::future。

std::packaged_task<R()> 包装一个可调用对象，它关联一个 std::future<R>。当你执行 packaged_task 时，结果被存入关联的 future，调用者通过 future.get() 获取。

`DoNotOptimize` 和 `ClobberMemory`

Mon, 01 Jan 0001 00:00:00 +0000

一、为什么需要它们

编译器非常聪明，会优化掉"看起来没用的代码"：

void test_sine() {
    double x = 0.0;
    for (int i = 0; i < 100000; i++) {
        x = sin(x);  // 编译器发现 x 没有后续使用 → 整个循环被删掉！
    }
}

// 如果你用 benchmark 测试这个函数，测出来时间 ≈ 0ns
// 因为编译器把整个循环优化掉了

二、正确用法

static void BM_Sine(benchmark::State& state) {
    double x = 0.0;

    for (auto _ : state) {
        x = sin(x);
        // 告诉编译器：这个值后续会被使用，不能删
        benchmark::DoNotOptimize(x);
    }

    // 最终把 x 输出，也是告诉编译器"x 确实被用了"
    std::cout << x << std::endl;
}

static void BM_Memcpy(benchmark::State& state) {
    char src[1024] = {}, dst[1024] = {};

    for (auto _ : state) {
        memcpy(dst, src, 1024);
        // 告诉编译器：dst 的内容被"外部"使用了
        benchmark::ClobberMemory();
    }
}

// 对比没有 ClobberMemory 的版本——编译器可能会把 memcpy 优化掉
static void BM_Memcpy_Wrong(benchmark::State& state) {
    char src[1024] = {}, dst[1024] = {};

    for (auto _ : state) {
        memcpy(dst, src, 1024);
        // dst 后续没被使用 → 编译器可能优化掉 memcpy
        // 测出来的时间 ≈ 0ns
    }
}

`perf record` + `perf report` —— 采样模式

Mon, 01 Jan 0001 00:00:00 +0000

一、基本使用

# 以 99Hz 频率采样，记录 CPU 正在执行的位置
perf record -F 99 -g ./my_program
# -F 99：每秒采样 99 次（避免采样开销过大）
# -g：记录调用栈（才能看到谁调了谁）

# 查看热点函数排名
perf report --stdio

# 输出示例：
# Samples: 1K of event 'cycles', 4000 Hz
# Event count (approx.): 845117845
# Overhead  Command   Shared Object     Symbol
#   25.32%  program   program           [.] compute_dct
#   18.15%  program   program           [.] motion_search
#   12.07%  program   program           [.] avcodec_send_frame
#    8.50%  program   libc-2.31.so      [.] memcpy
#    5.23%  program   program           [.] frame_copy
#    ...

# 看到热点函数后，用 perf annotate 查看汇编级别的热点
perf annotate compute_dct

二、perf annotate 的汇编级分析

输出示例：

compute_dct:
         │ 循环展开的热点：
         │ dct_4x4.c:25 (循环主体)
         │ vld1.32  {q0}, [r1]!       ← 加载数据
   23.5% │ vmla.f32  q1, q0, q2       ← 乘加运算（占 23.5% 的 CPU 时间）
   12.1% │ vld1.32  {q3}, [r2]!       ← 再加载数据
   18.3% │ vmla.f32  q4, q3, q5       ← 乘加运算
         │ subs     r3, #1
    5.2% │ bne      loop              ← 分支

如果一条指令占的时间异常高（比如 50%+），说明这条指令可能是流水线停滞点。
常见原因：
  - cache miss（加载指令）
  - 除法（div 指令，几十个周期）
  - 浮点转换（fcvt）

三、C++ 实战：用 perf 找到热点函数

// bench.cpp —— 一个需要性能分析的程序
#include <vector>
#include <algorithm>
#include <cmath>

// 模拟视频编码中的运动估计
void motion_search(const std::vector<int>& frame, int& best_mv) {
    best_mv = 0;
    int best_cost = INT_MAX;

    for (int dy = -16; dy <= 16; dy++) {
        for (int dx = -16; dx <= 16; dx++) {
            int cost = 0;
            // 简化的 SAD（绝对差和）计算
            for (int i = 0; i < 64; i++) {
                int diff = frame[i] - frame[i + dy * 64 + dx];
                cost += std::abs(diff);
            }
            if (cost < best_cost) {
                best_cost = cost;
                best_mv = dy * 64 + dx;
            }
        }
    }
}

// 模拟 DCT 变换
void dct_transform(std::vector<float>& block) {
    for (int i = 0; i < 64; i++) {
        block[i] = std::sin(block[i]) * std::cos(block[i]);  // 假运算模拟负载
    }
}

int main() {
    std::vector<int> frame(4096, 128);
    std::vector<float> dct_block(64, 1.0f);

    for (int i = 0; i < 100000; i++) {
        if (i % 10 == 0) {
            dct_transform(dct_block);  // 每 10 次做一次 DCT
        } else {
            int mv;
            motion_search(frame, mv);  // 大多数时间做运动估计
        }
    }
}

# 编译并运行 perf
g++ -O2 -g -o bench bench.cpp
perf record -F 99 -g ./bench
perf report --stdio

# 预期输出：
# Overhead  Symbol
#   72.5%   motion_search    ← 主要热点，占总 CPU 的 72%
#   18.3%   dct_transform    ← 次要热点
#    5.2%   std::abs         ← 被 motion_search 调用的

# 优化方向：把 motion_search 的 -16..16 搜索区域减少、提前终止等

`std::function` 的底层——Type Erasure 的典型实现

Mon, 01 Jan 0001 00:00:00 +0000

一、`std::function` 是怎么存任意可调用对象的？

std::function<int(int, int)> f = [](int a, int b) { return a + b; };
int result = f(3, 4);  // 7

你传进去的是一个 lambda（每 lambda 类型不同），但 f 能统一调用。这靠的就是 Type Erasure。

二、小对象优化（SBO）

std::function 内部有一个小缓冲区（通常是 16-32 字节）：

如果可调用对象 ≤ SBO 阈值：
  ┌─────────────────────────────────┐
  │ vptr  │ 小缓冲区（存 lambda）    │  ← 栈上，无堆分配
  └─────────────────────────────────┘

如果可调用对象 > SBO 阈值：
  ┌─────────────────────────────────┐
  │ vptr  │  ptr → 堆上的 lambda    │  ← 一次堆分配
  └─────────────────────────────────┘

实测：

// 小 lambda（捕获 2 个 int，16 字节）→ SBO，无堆分配
int a = 1, b = 2;
auto small = [a, b](int x) { return a + b + x; };

// 大 lambda（捕获一个大 vector）→ 堆分配
vector<int> v(1000);
auto big = [v](int x) { return v.size() + x; };

面试题：“为什么高频构造 std::function 性能差？”

`std::list` 双向链表与 `std::deque` 双端队列

Mon, 01 Jan 0001 00:00:00 +0000

一、`std::list` 的内存灾难

list 的每个节点单独 new 分配，分布在堆的各个角落：

list<int> l = {1, 2, 3, 4};

内存布局 (每个节点独立分配):
堆地址 0x1000: [1 | next→0x2000 | prev←null]
堆地址 0x2000: [2 | next→0x3000 | prev←0x1000]
堆地址 0x3000: [3 | next→0x4000 | prev←0x2000]
堆地址 0x4000: [4 | next←null  | prev←0x3000]

栈上:
list 对象: [_M_node 指向 0x1000 或哨兵节点]

遍历时的缓存行为：

CPU 遍历 list:
  读 0x1000 → Cache Miss (第一次加载缓存行，顺带加载了附近 64 字节的垃圾数据)
  读 0x2000 → Cache Miss (因为 0x2000 和 0x1000 不在同一缓存行)
  读 0x3000 → Cache Miss
  读 0x4000 → Cache Miss
  缓存命中率: ~0% ❌

CPU 遍历 vector:
  读 v[0] → Cache Miss (第一次，加载了 v[0]~v[15] 到缓存行)
  读 v[1] → Cache Hit ✅ (已经在缓存里了)
  读 v[2] → Cache Hit ✅
  ...
  缓存命中率: ~99% ✅

性能差距实测（1 亿次遍历，Release 编译）：

`std::optional` —— 可能有值，也可能没有

Mon, 01 Jan 0001 00:00:00 +0000

解决什么问题？

// ❌ 传统方式：约定特殊值代表"没有找到"
size_t find(const std::vector<int>& v, int x) {
    for (size_t i = 0; i < v.size(); i++)
        if (v[i] == x) return i;
    return -1;  // ❌ -1 对 size_t 来说是 18446744073709551615！而且如果索引 0 是有效值呢？
}

// ❌ 另一种传统方式：输出参数
bool find(const std::vector<int>& v, int x, size_t& out_index);
// API 调用者必须声明一个变量传进去，很啰嗦

optional 的承诺：用类型系统表达"返回值可能不存在"。

什么时候用？

场景	不用 optional	用 optional
容器查找	返回 -1 或 `end()`	返回 `optional<iterator>`
解析	返回 `bool` + 输出参数	返回 `optional<T>`
从可能为空的配置取值	抛异常	返回 `optional<T>`
数据库查询	返回 nullptr	返回 `optional<Record>`

std::optional<size_t> find(const std::vector<int>& v, int x) {
    for (size_t i = 0; i < v.size(); i++)
        if (v[i] == x) return i;     // ✅ 没有歧义
    return std::nullopt;              // ✅ 明确表达"没有"
}

auto result = find(vec, 42);
if (result.has_value()) {
    // 进入这里说明 result 一定有效
    size_t index = result.value();  // 或者 *result
} else {
    std::cout << "not found";
}

性能：optional<T> 不分配堆内存，和 T 占同样大的空间（+一个 bool 标记位，通常利用 padding 字节，不增加 sizeof）。

`std::shared_ptr` —— 引用计数的代价

Mon, 01 Jan 0001 00:00:00 +0000

一、16 字节的物理组成

shared_ptr<int> sp(new int(42));

栈上 (sp 对象本身，16 字节):
+──────────────────────+──────────────────────+
| ptr (8字节)          | control_block_ptr     |
| 指向堆上的 int       | 指向控制块            |
+──────────────────────+──────────────────────+

堆上:
+──────────────────────+  ← ptr 指向这里
| int: 42              |
+──────────────────────+

+──────────────────────+  ← control_block_ptr 指向这里（控制块）
| ref_count (原子 int)  |  引用计数
| weak_count (原子 int) |  弱引用计数
| deleter (函数指针)     |  删除器
| allocator (函数指针)   |  分配器
+──────────────────────+

两个堆分配：new int(42) 一次 + 控制块分配一次。这是两 new，两 delete。

二、`std::make_shared` 的合并优化

auto sp = std::make_shared<int>(42);

堆上 (一次 malloc):
+──────────────────────────────────────────────+
| int: 42    | ref_count | weak_count | ...    |
+──────────────────────────────────────────────+
              ↑
栈上 sp: [ptr→这里 | control_block_ptr→这里]
        ptr 指向的地址 = control_block_ptr 指向的地址（在同一个内存块内）

缓存优势：对象和控制块在同一个缓存行内。当 sp 被拷贝时，引用计数 ++ 的操作大概率在 L1 缓存中完成，不需要去主存加载控制块。

AAC 音频编码

Mon, 01 Jan 0001 00:00:00 +0000

一、PCM → AAC 的转换

extern "C" {
#include <libavcodec/avcodec.h>
#include <libavutil/audio_fifo.h>
}

// 把 PCM 帧编码为 AAC packet
struct AudioEncoder {
    AVCodecContext* ctx = nullptr;

    bool init(int sample_rate, int channels) {
        const AVCodec* codec = avcodec_find_encoder(AV_CODEC_ID_AAC);
        if (!codec) return false;

        ctx = avcodec_alloc_context3(codec);
        ctx->sample_fmt = AV_SAMPLE_FLT_FLTP;  // AAC 编码器要求 float planar
        ctx->sample_rate = sample_rate;
        ctx->channel_layout = channels == 1 ? AV_CH_LAYOUT_MONO : AV_CH_LAYOUT_STEREO;
        ctx->channels = channels;
        ctx->bit_rate = 128000;  // 128 kbps

        return avcodec_open2(ctx, codec, nullptr) >= 0;
    }

    // 编码一帧 PCM 数据
    // 注意：AAC 一帧固定 1024 个样本
    AVPacket* encode(const float* pcm_data, int num_samples) {
        AVFrame* frame = av_frame_alloc();
        frame->nb_samples = num_samples;
        frame->format = ctx->sample_fmt;
        frame->channel_layout = ctx->channel_layout;
        av_frame_get_buffer(frame, 0);

        // 把输入 PCM 拷贝到 frame（planar 格式：ch0 全在 data[0], ch1 全在 data[1]）
        memcpy(frame->data[0], pcm_data, num_samples * sizeof(float));

        AVPacket* packet = av_packet_alloc();
        if (avcodec_send_frame(ctx, frame) == 0) {
            avcodec_receive_packet(ctx, packet);
        }

        av_frame_free(&frame);
        return packet;
    }

    ~AudioEncoder() { avcodec_free_context(&ctx); }
};

二、AAC 的 ADTS 头部

当你从编码器拿到 AAC 裸流时，每帧数据开头有一个 ADTS 头部（7 或 9 字节），包含了采样率、声道数、帧长度等信息。没有 ADTS 头部，解码器不知道数据怎么解析。

Clang Static Analyzer

Mon, 01 Jan 0001 00:00:00 +0000

一、比 Clang-Tidy 更深层的分析

Clang-Tidy 是"模式匹配"（找常见的代码模式问题），Clang Static Analyzer 是符号执行（模拟代码的执行路径）。

# 方法 1：用 scan-build 替代编译命令
scan-build make -j4

# 方法 2：直接分析单个文件
clang --analyze source.cpp -std=c++17

二、它能找到 Clang-Tidy 找不到的问题

// 1. 资源泄漏
void leak_example() {
    FILE* f = fopen("data.txt", "r");
    // 忘了 fclose(f)
    // clang-tidy 不会报告，但 scan-build 会标记"资源泄漏"
}

// 2. 野指针路径
void branch_bug(bool condition) {
    int* p = nullptr;
    if (condition) {
        p = new int(42);
    }
    // 如果 condition = false，p 还是 nullptr
    *p = 0;  // scan-build 警告：possible null pointer dereference
}

// 3. 死代码（Dead code）
bool always_true(int x) {
    if (x > 0) {
        return true;
    }
    return true;  // 永远不会执行的代码
}

CRTP 典型应用

Mon, 01 Jan 0001 00:00:00 +0000

一、`std::enable_shared_from_this<T>`

这是 CRTP 在标准库中最经典的应用。场景：你有一个 shared_ptr 管理的对象，对象内部需要生成指向自己的 shared_ptr。

class Widget : public std::enable_shared_from_this<Widget> {
public:
    void register_callback() {
        // 把一个回调注册到别处，回调要持有 Widget 的 shared_ptr
        // 防止 Widget 被释放时回调还在执行
        callback_mgr_.add([self = shared_from_this()] {
            self->do_something();
        });
    }
};

没有 CRTP 会怎样？

如果 enable_shared_from_this 不是模板，它不知道派生类的类型，shared_from_this() 只能返回 shared_ptr<enable_shared_from_this>，不是 shared_ptr<Widget>。CRTP 让基类在编译期拿到派生类的类型，自然就能正确返回。

二、CRTP 实现实例计数

template <typename Derived>
class InstanceCounter {
    static inline int count_ = 0;
protected:
    InstanceCounter() { count_++; }
    ~InstanceCounter() { count_--; }
public:
    static int instance_count() { return count_; }
};

class MyClass : public InstanceCounter<MyClass> {
    // ...
};

class OtherClass : public InstanceCounter<OtherClass> {
    // ...
};

// MyClass 和 OtherClass 有各自独立的 count_
MyClass a, b;
OtherClass c;
MyClass::instance_count();   // 2
OtherClass::instance_count(); // 1

因为 InstanceCounter<MyClass> 和 InstanceCounter<OtherClass> 是两个不同的类，它们的 static count_ 是独立的。

HLS 协议

Mon, 01 Jan 0001 00:00:00 +0000

一、HLS 的工作方式

HLS 不是"实时推流协议"，而是"把直播切成小文件，让客户端通过 HTTP 下载播放"。

推流端：
    编码器 → 切片器 → TS 文件 1 (2秒)
                    → TS 文件 2 (2秒)
                    → TS 文件 3 (2秒)
                    → m3u8 播放列表（不断更新）

播放器：
    先请求 m3u8 → 看到 TS 文件列表 → 依次下载并播放

二、m3u8 文件格式

#EXTM3U                          ← 标识这是 HLS 播放列表
#EXT-X-VERSION:3                 ← 版本
#EXT-X-TARGETDURATION:10         ← 每个切片最长 10 秒
#EXT-X-MEDIA-SEQUENCE:100        ← 起始序列号

#EXTINF:8.320,                   ← 第一个切片时长 8.32 秒
segment-100.ts

#EXTINF:9.120,
segment-101.ts

#EXTINF:8.960,
segment-102.ts

#EXT-X-ENDLIST                   ← 如果文件在持续更新，没有这一行
                                 ← 直播场景不写 ENDLIST

三、HLS 的延迟问题

HLS 延迟 = 切片时长 + 播放器缓冲

假设每 2 秒切一个 TS 文件：
  推流器切完一个文件 → 放到服务器 → 更新 m3u8 → 播放器下载 → 播放
  最小延迟 ≈ 2 个切片 = 4 秒（播放器至少缓冲 2 个文件才能平滑播放）

提高延迟：
  切片 10 秒 → 延迟 20-30 秒（稳定，兼容性好）
  切片 2 秒 → 延迟 4-6 秒（延迟低，但服务器压力大）

对比：
  RTMP 延迟：1-3 秒
  HTTP-FLV 延迟：2-5 秒
  HLS 延迟：6-30 秒
  WebRTC 延迟：< 500ms

但 HLS 兼容性最好：
  iOS/macOS 原生支持，不需要任何插件
  浏览器通过 <video> 标签直接播放
  穿越防火墙容易（走 80/443 端口）

MP4 格式

Mon, 01 Jan 0001 00:00:00 +0000

一、MP4 的基本结构

MP4 由一个个 Box（也叫 Atom）组成，每个 Box 有类型和大小。

┌──────────────────────────────────────────┐
│ ftyp box（文件类型）                      │
│ 标识这是 MP4 文件，版本号                 │
├──────────────────────────────────────────┤
│ moov box（元数据头，非常重要）            │
│ ├── mvhd（电影头：时长、时间基）           │
│ ├── trak（视频轨道）                      │
│ │   ├── tkhd（轨道头：分辨率）            │
│ │   └── mdia（媒体信息）                  │
│ │       ├── mdhd（媒体头：语言）          │
│ │       ├── hdlr（处理类型：vide）        │
│ │       ├── minf（媒体信息）              │
│ │       └── stbl（样本表——关键！）         │
│ │           ├── stsd（编码器配置：H.264)   │
│ │           ├── stts（帧时间戳）           │
│ │           ├── stsc（帧分组）             │
│ │           ├── stsz（每帧大小）           │
│ │           └── stco（每帧在文件中的偏移)  │
│ └── trak（音频轨道，类似结构）             │
├──────────────────────────────────────────┤
│ mdat box（媒体数据）                      │
│ 实际的 H.264 码流 + AAC 码流             │
│ 按帧顺序排列，stco 告诉你每帧在 mdat 中的位置 │
└──────────────────────────────────────────┘

二、moov box 的位置——影响"秒开"的关键

moov 在文件头：
  [ftyp][moov][mdat...]
  播放器先读到 moov，知道所有帧的位置 → 可以直接跳到任意位置播放
  适合"点播"场景（用户从头看）

moov 在文件尾（编码器默认行为）：
  [ftyp][mdat...][moov]
  编码器写入时还不知道总帧数和每帧大小 → 先写 mdat，最后写 moov
  播放器必须下载完整个文件才能读到 moov → 不能边下边播
  对直播/流式播放不友好

解决方案（faststart）：
  ffmpeg -i input.mp4 -movflags faststart output.mp4
  编码完后把 moov 从文件尾搬到文件头

三、手写解析 MP4 文件头（简化版）

#include <cstdio>
#include <cstdint>
#include <cstring>

#pragma pack(push, 1)
struct MP4BoxHeader {
    uint32_t size;      // Box 总大小（含 header）
    uint32_t type;      // 4 字符类型，如 'ftyp', 'moov', 'mdat'
};
#pragma pack(pop)

void print_box_type(uint32_t type) {
    char t[5] = {
        (char)((type >> 24) & 0xFF),
        (char)((type >> 16) & 0xFF),
        (char)((type >> 8) & 0xFF),
        (char)(type & 0xFF),
        '\0'
    };
    printf("%s", t);
}

void parse_mp4_boxes(const char* filename) {
    FILE* f = fopen(filename, "rb");
    if (!f) { perror("open"); return; }

    printf("=== MP4 Box 结构 ===\n");
    int depth = 0;

    while (true) {
        MP4BoxHeader hdr;
        if (fread(&hdr, sizeof(hdr), 1, f) != 1) break;

        if (hdr.size == 0) break;  // 最后一个 box

        for (int i = 0; i < depth; i++) printf("  ");
        printf("+ ");
        print_box_type(hdr.type);
        printf("  size=%u", hdr.size);

        if (hdr.type == 0x66747970) {  // 'ftyp'
            char brand[5] = {};
            fread(brand, 4, 1, f);
            printf("  brand=%s", brand);
        }

        printf("\n");

        // 递归进入容器 box（moov、trak、mdia 等）
        uint32_t container_types[] = {
            0x6D6F6F76,  // 'moov'
            0x7472616B,  // 'trak'
            0x6D646961,  // 'mdia'
            0x6D696E66,  // 'minf'
            0x7374626C,  // 'stbl'
            0x65647473,  // 'edts'
            0x75647461,  // 'udta'
        };
        bool is_container = false;
        for (auto ct : container_types) {
            if (hdr.type == ct) { is_container = true; break; }
        }

        if (is_container) {
            depth++;
            // 容器 box 的 header 后面就是子 box
            // continue reading
        } else {
            // 跳过这个 box 的数据（header 已读，skip 剩余部分）
            int remaining = hdr.size - sizeof(MP4BoxHeader);
            if (remaining > 0) fseek(f, remaining, SEEK_CUR);
        }

        // 如果 is_container，子 box 的读取在下一轮 while 循环中继续
        if (!is_container && depth > 0) {
            // 检查是否回到父 box 的末尾
            // 简化处理：没有很好地处理 box 嵌套边界
            // 真实场景需要跟踪每个 box 的结束位置
        }
    }

    fclose(f);
}

MPSC (多写单读) 在异步系统中的落地

Mon, 01 Jan 0001 00:00:00 +0000

这个问题直接触及异步系统设计的灵魂！MPSC（Multi-Producer Single-Consumer）是日志系统、网络收包、数据库WAL的黄金模型。我们的目标很明确：让成千上万个生产者疯狂提交任务，而单个消费者线程以内存带宽极限速度刷盘/处理。

1. MPSC 的天然困境：多写竞争

MPSC 的难点在于：

多个生产者争抢同一个队列 → 需要 CAS 保护。
一个消费者需要看到所有生产者的提交 → 需要全局可见性。

如果直接用 push + CAS 逐个入队，在高并发下会产生缓存行乒乓（所有生产者都在抢 head 指针的缓存行），吞吐量断崖式下跌。

解决方案：批量提交（Batch Submission） + 本地缓冲（Thread-Local Buffer）。

2. MPSC 批量提交流程（三阶段）

核心思想：每个生产者先攒一批，然后一次 CAS 把整批交给消费者。

[阶段1: 生产者本地缓冲]
    每个线程有自己的本地队列 (线程局部存储)
    任务先写入本地队列 (无竞争，极快)

[阶段2: CAS 批量提交]
    本地队列满了 (或超时) → 获取共享队列的全局锁（一次CAS）
    把整批任务挂到共享队列尾部

[阶段3: 消费者批量消费]
    消费者一次性取走所有任务 (使用内存屏障保证可见性)
    批量处理/刷盘 → 极高吞吐

3. 工业级 MPSC 队列实现（批处理 + 环形缓冲区）

数据结构设计

template<typename T, size_t LocalBatchSize = 256, size_t GlobalSize = 1024 * 1024>
class MPSCBatchQueue {
    // ============ 全局共享队列 (环形缓冲区) ============
    struct GlobalQueue {
        alignas(64) std::atomic<size_t> write_index{0};  // 生产者CAS抢位置
        alignas(64) std::atomic<size_t> read_index{0};   // 消费者读位置
        alignas(64) T buffer[GlobalSize];
        
        // 保证容量是2的幂，使用位运算取模
        static constexpr size_t MASK = GlobalSize - 1;
        static_assert((GlobalSize & (GlobalSize - 1)) == 0, 
                      "GlobalSize must be power of 2");
    };
    GlobalQueue global_queue;
    
    // ============ 生产者本地缓冲 (线程局部) ============
    struct LocalBuffer {
        size_t count{0};
        T items[LocalBatchSize];
    };
    
    // 线程局部存储：每个生产者有自己的缓冲
    thread_local static LocalBuffer local_buffer;

public:
    // 生产者接口：提交单个任务
    bool enqueue(const T& item) {
        // 1. 写入本地缓冲 (无竞争，极快)
        local_buffer.items[local_buffer.count++] = item;
        
        // 2. 如果本地缓冲满了，批量提交到全局队列
        if (local_buffer.count >= LocalBatchSize) {
            flush_local_buffer();
        }
        return true;
    }
    
    // 生产者接口：强制刷新（如程序退出前）
    void flush() {
        flush_local_buffer();
    }
    
    // 消费者接口：批量获取任务
    struct Batch {
        const T* data;
        size_t count;
    };
    
    Batch dequeue_batch() {
        const size_t current_read = global_queue.read_index.load(std::memory_order_acquire);
        const size_t current_write = global_queue.write_index.load(std::memory_order_acquire);
        
        size_t available = current_write - current_read;
        if (available == 0) {
            return {nullptr, 0}; // 队列空
        }
        
        // 尽量一次性取出所有可用数据 (但不要超过环形缓冲区边界)
        size_t count = std::min(available, GlobalSize - (current_read & GlobalQueue::MASK));
        const T* data = &global_queue.buffer[current_read & GlobalQueue::MASK];
        
        // 注意：这里不立即更新read_index，让消费者处理完再更新
        // (或者使用双指针技术，下面会讲)
        return {data, count};
    }
    
    // 消费者接口：提交消费进度 (批量标记已处理)
    void commit_read(size_t count) {
        size_t new_read = global_queue.read_index.load(std::memory_order_relaxed) + count;
        global_queue.read_index.store(new_read, std::memory_order_release);
    }

private:
    // 批量提交本地缓冲到全局队列
    void flush_local_buffer() {
        if (local_buffer.count == 0) return;
        
        // 1. 用 CAS 抢占全局队列的写入位置 (唯一原子操作!)
        size_t start_index = global_queue.write_index.fetch_add(
            local_buffer.count, std::memory_order_acquire);
        
        // 2. 计算在环形缓冲区中的起始位置
        size_t start_pos = start_index & GlobalQueue::MASK;
        size_t end_pos = (start_index + local_buffer.count) & GlobalQueue::MASK;
        
        // 3. 复制数据到全局队列 (可能跨越环形边界)
        if (start_pos < end_pos) {
            // 不跨越边界：直接拷贝
            memcpy(&global_queue.buffer[start_pos], 
                   local_buffer.items, 
                   local_buffer.count * sizeof(T));
        } else {
            // 跨越边界：分两段拷贝
            size_t first_part = GlobalSize - start_pos;
            memcpy(&global_queue.buffer[start_pos], 
                   local_buffer.items, 
                   first_part * sizeof(T));
            memcpy(&global_queue.buffer[0], 
                   &local_buffer.items[first_part], 
                   (local_buffer.count - first_part) * sizeof(T));
        }
        
        // 4. 清空本地缓冲
        local_buffer.count = 0;
    }
};

4. 性能关键：消费者"双指针"技术

消费者如果每处理完一条就更新 read_index，会产生大量缓存行写操作。优化的做法是：消费者批量处理，只更新一次 read_index。

NUMA（非统一内存访问）

Mon, 01 Jan 0001 00:00:00 +0000

这是多插槽服务器（如双路 Xeon、AMD EPYC、ARM 服务器）上最容易被忽视的性能杀手。你在单颗桌面 CPU 上跑得飞快的程序，搬到多插槽服务器上可能性能直接腰斩——十有八九是 NUMA 在作祟。

1. 什么是 NUMA？（物理拓扑视角）

在传统的 UMA（Uniform Memory Access，统一内存访问） 架构中，所有 CPU 核心通过同一条总线（或同一个内存控制器）访问所有物理内存，延迟一致。

在 NUMA 架构中，每个 CPU 插槽（Socket）拥有自己独立的内存控制器和本地内存。CPU 插槽之间通过高速互联（如 Intel UPI、AMD Infinity Fabric）连接。

+-----------------------------------------------------------+
|                    NUMA 双插槽服务器                        |
+-----------------------------------------------------------+
|  Socket 0 (CPU 0)          |  Socket 1 (CPU 1)            |
|  +-------------------+     |  +-------------------+        |
|  | 核心 0-7          |     |  | 核心 8-15         |        |
|  | L1/L2/L3 缓存     |     |  | L1/L2/L3 缓存     |        |
|  +-------------------+     |  +-------------------+        |
|  | 内存控制器 (MC0)  |     |  | 内存控制器 (MC1)  |        |
|  +--------+----------+     |  +--------+----------+        |
|           |                |           |                   |
|  +--------v----------+     |  +--------v----------+        |
|  | 本地内存 (Node 0) |     |  | 本地内存 (Node 1) |        |
|  | 延迟: ~80ns       |     |  | 延迟: ~80ns       |        |
|  +-------------------+     |  +-------------------+        |
|           |                |           |                   |
|           +----[UPI 互联]---+-----------+                   |
|               跨插槽访问延迟: ~160ns (2倍!)                  |
+-----------------------------------------------------------+

核心事实：

NVI（非虚接口模式）

Mon, 01 Jan 0001 00:00:00 +0000

一、NVI 的核心思想

非虚接口（Non-Virtual Interface）：基类的公有接口不是虚函数，而是调用私有的虚函数。

class DataProcessor {
public:
    // 公有接口——非虚
    void process() {
        // 统一的前置处理
        std::lock_guard<std::mutex> lock(mtx_);
        log_start();

        // 调用派生类实现的虚函数
        do_process();

        // 统一的后置处理
        log_end();
    }

    virtual ~DataProcessor() = default;

private:
    std::mutex mtx_;

    // 私有虚函数——派生类改写这个
    virtual void do_process() = 0;

    void log_start() { /* ... */ }
    void log_end()   { /* ... */ }
};

好处：基类在 process() 中统一添加了日志、锁、性能统计，派生类只需要关心 do_process() 的业务逻辑，不需要重复写这些横切关注点。

Proactor 模式与 io_uring

Mon, 01 Jan 0001 00:00:00 +0000

Reactor 的问题：读取数据的操作是同步的——调用 read() 后线程阻塞等待数据从内核拷贝到用户缓冲区。

Proactor / io_uring：你告诉内核"数据读到我指定的缓冲区"，内核完成后通知你。读数据不阻塞。

Reactor（epoll）：
  程序：epoll_wait 告诉我可读了
  程序：read(fd, buf, len)  ← 这里阻塞等数据拷贝
  程序：处理数据

Proactor（io_uring）：
  程序：提交 SQE → "把数据读到 buf，完成后通知我"
  程序：干别的事情
  内核：数据准备好 → DMA 直接拷贝到 buf
  内核：产生 CQE → 通知程序
  程序：从 CQE 拿到完成的 buf
  程序：处理数据

你的 SimpleAsyncLogger 的 Linux 后端 (io_engine_linux.cpp) 用的就是 Proactor 模式——提交 WRITE_FIXED 后不等待，CQE 完成后处理。

UndefinedBehaviorSanitizer（UBSan）

Mon, 01 Jan 0001 00:00:00 +0000

一、它能抓到什么

// 1. 整数溢出
void int_overflow() {
    int x = INT_MAX;
    x++;  // UBSan：signed integer overflow
}

// 2. 移位越界
void shift_overflow() {
    int x = 1;
    x <<= 33;  // UBSan：shift exponent 33 is too large for 32-bit type
}

// 3. 空指针解引用
void null_deref() {
    int* p = nullptr;
    *p = 42;  // UBSan：null pointer dereference
}

// 4. dynamic_cast 到错误类型
class Base { virtual ~Base() = default; };
class Derived1 : public Base {};
class Derived2 : public Base {};

void bad_cast() {
    Base* b = new Derived1;
    auto* d = dynamic_cast<Derived2*>(b);
    // 不会崩溃（返回 nullptr），但如果你忘了检查 → 后续解引用会 UB
}

二、用法

# 编译：可以在 ASan 的基础上叠加 UBSan
g++ -fsanitize=address,undefined -fno-omit-frame-pointer -g -O1 -o test test.cpp

./test

# 可能会在标准输出中看到：
# test.cpp:4:5: runtime error: signed integer overflow
# test.cpp:9:5: runtime error: shift exponent 33 is too large

建议：你的所有 C++ 项目都应该在 Debug 构建中开启 UBSan，因为它捕到的错误都是真正的 Bug，不应该是正常行为。

Work-Stealing 的设计

Mon, 01 Jan 0001 00:00:00 +0000

Work-Stealing 的核心思想：每个线程有自己的任务队列，线程优先处理自己的任务。自己的队列空了，才去"偷"别人的。

线程 1                   线程 2                   线程 3
┌──────────────┐        ┌──────────────┐        ┌──────────────┐
│ deque<任务>   │        │ deque<任务>   │        │ deque<任务>   │
│ [t1][t2][t3] │        │ [t4][t5]     │        │ 空            │
│  ↑pop_front  │        │  ↑pop_front  │        │              │
└──────────────┘        └──────────────┘        └──────────────┘
      │                                               │
      │ 自己取自己的任务                                 │ 自己的空了，
      │ top_front 是热点                               │ 去偷别人的
      ▼                                               ▼
  执行 t1                                        从线程 2 的
                                                 尾部偷 t5

每个队列是双端队列（deque）：

自己：从 front 取任务（pop_front）——热点
别人偷：从 back 取任务（pop_back）——减少冲突

为什么自己从 front 取、别人从 back 偷？

x86 架构下的核心兵器：`LOCK` 前缀指令

Mon, 01 Jan 0001 00:00:00 +0000

LOCK前缀就像给指令挂上了“原子手雷”，而cmpxchg和xadd则是两种不同战术的手雷。

我们先拆解硬件行为，再看汇编形态，最后看C++如何映射。

1. 灵魂拷问：`LOCK` 前缀到底对CPU做了什么？

当你在汇编指令前加上 LOCK，CPU会执行以下硬件契约：

断言总线锁或缓存锁（我们上节课讲的，优先缓存锁）。
内存屏障（Memory Barrier）：LOCK 隐式包含全屏障（Full Barrier），它会强制：
- 将CPU核心的写缓冲区（Store Buffer） 全部冲刷到缓存。
- 确保这条指令之前的所有读写操作都全局可见，之后的操作不会提前。
原子性保证：在读-改-写期间，不允许其他核心/硬件设备（如DMA）访问该内存地址。

关键点：LOCK 不是“锁住变量”，而是锁住对那个内存地址的访问路径，保证读-改-写是一个不可分割的硬件事务。

2. 核心兵器一：`xadd` —— 原子自增/自减的“特快专列”

汇编原型

lock xadd [mem], reg   ; 等价于：先交换，再相加
; 功能：将 [mem] 的值 与 reg 的值交换，然后将两者之和存回 [mem]
; 返回值（旧值） 存放在 reg 中

执行过程（3步原子完成）

初始: [mem] = 10, reg (eax) = 1
1. 硬件原子性读取 [mem] 的值（10）到内部临时寄存器
2. 将 reg（1）写入 [mem]（此时 [mem]=1，但这是内部中间态）
3. 计算 10 + 1 = 11，写回 [mem]
最终: [mem]=11, reg=10  (reg 拿到了旧值)

典型应用场景

高性能统计计数器（网络包计数、QPS统计）。
无锁栈的 pop 操作（减少引用计数）。

C++ 映射（你几乎不会直接写汇编，但要知道底层）

#include <atomic>

std::atomic<int> counter{0};

// C++ 的 fetch_add 在 x86 上编译为 lock xadd
int old_value = counter.fetch_add(1, std::memory_order_acq_rel);
// old_value 拿到增加前的值，counter 原子 +1

反汇编查看（GCC/Clang）：

YUV 色彩空间

Mon, 01 Jan 0001 00:00:00 +0000

一、YUV 的核心思想

把亮度和颜色分开：

Y（Luma）：灰度信息，就是黑白画面
U（Cb / Chroma Blue）：蓝色色度偏移
V（Cr / Chroma Red）：红色色度偏移

YUV 的直观理解：
  把一张彩色照片转成 YUV：
  Y = 黑白照片（完全保留了图像的细节/边缘/纹理）
  U/V = 只有模糊的颜色涂抹（人眼无法分辨色度的细节）

解码器用 Y + UV 合成彩色 → 效果和 RGB 一样，但 UV 可以省带宽。

二、RGB ↔ YUV 转换公式（手写实现）

BT.601 标准（标清视频）的转换：

#include <cstdint>
#include <algorithm>

// ============ RGB → YUV（BT.601） ============

struct YUV {
    uint8_t y, u, v;
};

YUV rgb_to_yuv(uint8_t r, uint8_t g, uint8_t b) {
    YUV out;
    // Y  =  0.299R + 0.587G + 0.114B
    // U  = -0.169R - 0.331G + 0.500B + 128
    // V  =  0.500R - 0.419G - 0.081B + 128
    //
    // 用整数运算避免浮点：
    int y = (66 * r + 129 * g + 25 * b + 128) >> 8 + 16;
    int u = (-38 * r - 74 * g + 112 * b + 128) >> 8 + 128;
    int v = (112 * r - 94 * g - 18 * b + 128) >> 8 + 128;

    out.y = std::clamp(y, 16, 235);   // 广播级范围
    out.u = std::clamp(u, 16, 240);
    out.v = std::clamp(v, 16, 240);
    return out;
}

// ============ YUV → RGB（BT.601） ============

struct RGB {
    uint8_t r, g, b;
};

RGB yuv_to_rgb(uint8_t y, uint8_t u, uint8_t v) {
    int yy = y - 16;
    int uu = u - 128;
    int vv = v - 128;

    int r = (298 * yy + 409 * vv + 128) >> 8;
    int g = (298 * yy - 100 * uu - 208 * vv + 128) >> 8;
    int b = (298 * yy + 516 * uu + 128) >> 8;

    return RGB{
        (uint8_t)std::clamp(r, 0, 255),
        (uint8_t)std::clamp(g, 0, 255),
        (uint8_t)std::clamp(b, 0, 255)
    };
}

对比测试：原始 RGB 值 → 转 YUV → 转回 RGB，验证一致性。

三类问题必须分开处理

Mon, 01 Jan 0001 00:00:00 +0000

0.1 三类问题必须分开处理

上一节：无（这是全书的起点）　|　下一节：0.2 吞吐、延迟、成本的三方权衡配套代码：00-introduction/01-three-kinds-of-problems

一句话结论

「性能」不是一个问题，而是三个不同的问题：这段代码本身快不快、这个服务能扛多少、它为什么慢。三者需要三套不同的方法，混用就会得到错误的答案。

一、从一个真实的对话开始

同事：我们的订单接口太慢了，你能不能看一下？你（凭直觉）：我先压一下看看。

这次「我先压一下」大概率会浪费半天。因为你并不知道自己在回答哪个问题：

你是想验证「订单接口的代码写得不好」吗？→ 那应该做微基准，把某个函数单独拎出来测。
你是想知道「它能扛多少流量、什么时候垮」吗？→ 那应该做负载测试。
你是想知道「它现在为什么慢、时间花在哪」吗？→ 那应该做性能剖析。

这三件事的输入、输出、工具、时间成本完全不同。 先搞清楚要做哪一件，再动手。

二、三类问题对照表

	微基准（Microbenchmark）	负载测试（Load Test）	性能剖析（Profiling）
你在问	这段代码本身有多快？	这个系统能扛多少？	现在为什么慢？
典型提问	「`copy()` 和手动复制哪个快？」	「上线前它能撑住 1000 QPS 吗？」	「P99 从 80ms 涨到 400ms，卡在哪？」
是否隔离	完全隔离，只测一个函数	不隔离，全链路一起测	不隔离，在生产同构环境上采样
典型工具	JMH、kotlinx-benchmark	k6、Gatling、wrk2	async-profiler、JFR、火焰图
主要输出	`ns/op` 或 `ops/s`	吞吐-延迟曲线、拐点、崩溃点	时间花在哪条调用链上
测量粒度	纳秒	毫秒	采样栈（可以是函数级）
主要风险	被 JIT 优化掉，测出假数据	压测机自己成为瓶颈	只看到 CPU 时间，漏掉等待

一个通俗的类比：医院检查

检查项目	对应	能回答	不能回答
化验一滴血	微基准	这个指标本身正常吗？	你能不能跑完马拉松
跑步机压力测试	负载测试	你的心肺能撑多大强度、什么时候出问题	是哪根血管堵了
拍 CT / 造影	性能剖析	到底是哪里堵了	你能跑多快

最常见的错误，是拿「化验结果」去回答「能跑多快」的问题。

为什么需要门禁

Mon, 01 Jan 0001 00:00:00 +0000

8.1 为什么需要门禁

上一节：无　|　下一节：8.2 CI 微基准门禁配套代码：08-continuous-performance/01-why-gates

一句话结论

90% 的性能问题不是「某次大改搞坏了」，而是「几十次小改动各退化 3%，累积起来翻了一倍」。 这种退化逃过所有人工评审（因为每次都在噪声范围内），只有自动化的门禁能发现它。

一、用「慢性病」理解渐进退化

一次急性心梗，你会立刻去医院。但高血压、高血脂、血糖偏高——每年只涨一点，你毫无感觉。

十年后，它们一起导致了严重问题。而如果每年体检 + 指标超阈值就干预，就能避免。

健康管理	性能管理
急性病 → 立刻就医	线上故障 → 立刻排查（第 6 章）
年度体检 + 指标趋势	门禁 + 趋势监控（本章）
血压 > 140 就干预	微基准退化 > 15% 就失败
家庭血压计（日常监测）	生产告警（实时监测）

关键：急性病靠医生，慢性病靠机制。 性能工作的大部分价值在后者。

二、渐进退化的四种典型来源

❶ 新增功能带来的额外工作

v2.3：新增"用户画像"接口，每次请求多查一次数据库
     → 订单接口的 P99 从 95ms 涨到 101ms（+6%）
     → 在噪声范围内，code review 也看不出来

为什么难发现：加一次查询看起来"很合理"，而且只涨 6%。

❷ 数据量增长

v2.3 时：订单表 100 万行，某查询走索引，8ms
v2.8 时：订单表 800 万行，同一个查询因为统计信息/选择性变化
         改走全表扫描，45ms（+460%）

为什么难发现：代码一行没改，是数据让执行计划变了。

二、核心原理图：它们在内存中长什么样？

Mon, 01 Jan 0001 00:00:00 +0000

我们用一段简单的 C++ 代码，画出它们在内存中的真实形态：

std::string a = "High Performance";
std::string b = a + " Log Server";

【 堆内存 (Heap) 】                 【 栈内存 (Stack) / 寄存器 】

┌───────────────────────┐            ┌────────────────────────┐
│ "High Performance"    │ ◄──────────┤ 变量名: a (左值 lvalue)  │ (能取地址 &a)
└───────────────────────┘            └────────────────────────┘

┌───────────────────────┐            ┌────────────────────────┐
│ "High Performance     │ ◄──────────┤ 临时变量 (纯右值 prvalue)│ (没名字, 没地址,
│  Log Server"          │            └────────────────────────┘  算完就扔)
└───────────────────────┘                        │
                                                 ▼ 拷贝赋值给
                                     ┌────────────────────────┐
                                     │ 变量名: b (左值 lvalue)  │ (能取地址 &b)
                                     └────────────────────────┘

二、`view` 和 `container` 的区别——必须搞懂

Mon, 01 Jan 0001 00:00:00 +0000

std::vector<int> data = {1, 2, 3, 4, 5};

// view（视图）：不拥有数据，不分配内存
auto v = data | std::views::filter([](int x) { return x % 2 == 1; });
// 此时什么也没发生！v 只是记住了 data 的引用和 filter 条件

for (int x : v) { // 遍历时才触发计算
    std::cout << x; // 1 3 5
}

// container（容器）：拥有数据，分配内存
std::vector<int> c;
std::copy_if(data.begin(), data.end(), std::back_inserter(c),
             [](int x) { return x % 2 == 1; });
// 此时已经完成了筛选，c 持有 [1, 3, 5]

一句话区分：view 像 string_view——只是看一眼，不拿过来。container 像 string——复制一份归自己所有。

二、Arena 分配器——最快的分配器

Mon, 01 Jan 0001 00:00:00 +0000

解决什么问题？

问题：游戏的一帧中需要频繁创建和销毁大量小对象。每次 new/delete 调用 malloc，而 malloc 内部用红黑树管理空闲块，有锁竞争，要几十纳秒甚至几微秒。

Arena 的思路：一次性批一大块内存，分配时只做指针加法（1-2 纳秒），释放时整块一起释放。

原理

class Arena {
    char* buffer_;
    size_t offset_ = 0;  // 当前分配到的位置
    size_t size_;

public:
    Arena(char* buf, size_t sz) : buffer_(buf), size_(sz) {}

    void* alloc(size_t bytes) {
        if (offset_ + bytes > size_) throw std::bad_alloc();
        void* ptr = buffer_ + offset_;
        offset_ += bytes;
        return ptr;
        // 这就是全部了！一条加法指令，约 1ns
    }

    void reset() { offset_ = 0; }  // 整块重置，不用逐个 delete
    // 没有 deallocate 方法——Arena 不支持单个释放
};

使用 Arena 的 vector 分配速度：

二、Concepts 的三种写法（看起来不一样，效果一样）

Mon, 01 Jan 0001 00:00:00 +0000

// 写法 1：template 前缀约束（最推荐，一眼看出模板类型受约束）
template <std::integral T>
T half(T x) { return x / 2; }

// 写法 2：auto 参数约束（简洁，类似泛型 lambda）
std::integral auto half(std::integral auto x) { return x / 2; }

// 写法 3：requires 子句（最灵活，可以写复杂条件）
template <typename T>
    requires std::integral<T>
T half(T x) { return x / 2; }

选哪个？

场景 1：约束很简单（比如 std::integral、std::floating_point）→ 写法 1 或 2 都行。
场景 2：约束复杂（多个条件组合）→ 定义新 Concept + 写法 1。
场景 3：约束依赖多个模板参数 → requires 子句最自然。

什么时候该调 `enqueue`？

Mon, 01 Jan 0001 00:00:00 +0000

场景	直接开线程	用线程池
任务频率高、执行时间短	❌ 创建线程开销大	✅ 复用线程
任务执行时间长（秒级）	✅ 线程数少时可以	✅ 也可以，线程池大小要控制
异步执行不关心结果	❌ 需要自己管理生命周期	✅ enqueue 后不用管
需要返回值 / 异常传递	❌ 需要额外同步	✅ 第二阶段加入 future

优先级金字塔：先问要不要做

Mon, 01 Jan 0001 00:00:00 +0000

7.1 优先级金字塔：先问要不要做

上一节：无　|　下一节：7.2 减少工作配套代码：07-optimization-and-validation/01-priority-pyramid

一句话结论

优化的收益从「不做」到「调 JVM 参数」递减，而成本和风险递增。 把顺序做反了，你会花一周调 GC 参数去优化一个本该加索引的查询。

一、用「医院分诊」理解优先级

急诊室不会按「谁先来」看病，而是按紧急程度分诊：

优先级	情况	处理
1	心跳骤停	立刻抢救
2	大出血	尽快处理
3	骨折	排队等
4	擦伤	最后处理

如果先给擦伤的人包扎，心跳骤停的人就死了。

性能优化完全一样。「不做某个功能」的收益常常大于「把它优化得快一点」。

二、六级金字塔

⑥ JVM 参数调优          ← 收益最小、风险最高、最容易做错
⑤ 微观常数优化（减少分配、避免装箱、换序列化器）
④ 缓存与池化
③ 架构与并发（批量、异步、隔离、背压）
② 算法与数据访问（复杂度、IO 次数、N+1、缺索引）
① 先问「这个功能真的需要吗」  ← 收益最高、成本最低

每一级的说明与典型收益

级别	做什么	典型收益	成本/风险
① 不必要	砍掉不必要的功能、减少返回字段、去掉重复计算	极大（直接省掉）	低（但是产品决策）
② 算法与数据访问	加索引、消除 N+1、批量查询、改进算法	数倍	低–中（改 SQL/代码）
③ 架构与并发	批量、异步化、隔离资源池、加背压	数倍	中（改架构）
④ 缓存与池化	多级缓存、连接池调优	中（P50 明显，P99 未必）	中–高（一致性风险）
⑤ 微观常数	减少分配、避免装箱、换序列化器	个位数百分比	中（可读性下降）
⑥ JVM 参数	堆大小、GC 选型	个位数百分比	高（需长期验证）

关键观察：①–③ 的收益是数倍级，⑤–⑥ 是个位数百分比级。

伪共享（False Sharing）与内存对齐（Padding）

Mon, 01 Jan 0001 00:00:00 +0000

这个问题问到了高性能并发编程的命门！伪共享是90%的性能劣化问题根源，而内存对齐是解决它的手术刀。我们今天不仅要讲理论，还要让你亲眼看到伪共享如何拖垮程序，以及如何用 alignas(64) 一招制敌。

1. 伪共享（False Sharing）的物理真相

硬件层面的"误伤"

内存布局 (缓存行大小 = 64字节):
+------------------------------------------------------------------+
| 缓存行 0x1000 - 0x103F                                           |
| +----------+----------+----------+----------+----------+         |
| | int a    | int b    | 填充     | 填充     | 填充     |         |
| | (0x1000) | (0x1004) | (0x1008) | ...      | (0x103C) |         |
| +----------+----------+----------+----------+----------+         |
+------------------------------------------------------------------+

核心A: 频繁修改 a (0x1000)
核心B: 频繁修改 b (0x1004)

虽然修改的是不同变量，但它们在同一个缓存行！
CPU被迫让这个缓存行在核心A和核心B之间"飞来飞去"。

缓存行乒乓（Cache Line Ping-Pong）

时间线 (微秒级):

[核心A] 读取缓存行 → 状态 E (独占)
[核心A] 修改 a → 状态 M (修改)
[核心B] 读取缓存行 → 需要从核心A获取 → 核心A 状态 M→S (共享)，写回主存
[核心B] 获取缓存行 → 状态 S
[核心B] 修改 b → 需要独占 → 广播 RFO (请求独占)
[核心A] 收到 RFO → 状态 S→I (失效)
[核心B] 状态 S→M (修改)
... 循环往复

每次乒乓: ~100ns 延迟 (相当于300个CPU周期)
如果每秒百万次操作 → 性能损失巨大！

2. 实战Demo：让伪共享现出原形

测试程序（对比有/无伪共享）

#include <atomic>
#include <thread>
#include <chrono>
#include <iostream>
#include <vector>

using namespace std::chrono;

// ==================== 版本1：有伪共享 ====================
struct FalseSharingStruct {
    std::atomic<int> a{0};  // 地址 0x1000
    std::atomic<int> b{0};  // 地址 0x1004 (同一缓存行!)
};
FalseSharingStruct fs_data;

void worker_false_sharing(int id, int iterations) {
    if (id == 0) {
        for (int i = 0; i < iterations; ++i) {
            fs_data.a.fetch_add(1, std::memory_order_relaxed);
        }
    } else {
        for (int i = 0; i < iterations; ++i) {
            fs_data.b.fetch_add(1, std::memory_order_relaxed);
        }
    }
}

// ==================== 版本2：无伪共享 (内存对齐) ====================
struct alignas(64) CacheLineAlignedStruct {
    std::atomic<int> a{0};  // 地址 0x1000 (缓存行开始)
    // 隐含填充：剩余60字节自动填充
};

struct alignas(64) CacheLineAlignedStruct2 {
    std::atomic<int> b{0};  // 地址 0x1040 (下一缓存行)
};

CacheLineAlignedStruct aligned_a;
CacheLineAlignedStruct2 aligned_b;

void worker_no_false_sharing(int id, int iterations) {
    if (id == 0) {
        for (int i = 0; i < iterations; ++i) {
            aligned_a.a.fetch_add(1, std::memory_order_relaxed);
        }
    } else {
        for (int i = 0; i < iterations; ++i) {
            aligned_b.b.fetch_add(1, std::memory_order_relaxed);
        }
    }
}

// ==================== 测试函数 ====================
template<typename Func>
void benchmark(const std::string& name, Func&& func, int iterations) {
    auto start = high_resolution_clock::now();
    func();
    auto end = high_resolution_clock::now();
    auto duration = duration_cast<milliseconds>(end - start).count();
    std::cout << name << ": " << duration << " ms" << std::endl;
}

int main() {
    const int THREADS = 2;
    const int ITERATIONS = 100'000'000; // 1亿次
    
    // 测试伪共享
    benchmark("False Sharing", [&]() {
        std::vector<std::thread> threads;
        for (int i = 0; i < THREADS; ++i) {
            threads.emplace_back(worker_false_sharing, i, ITERATIONS);
        }
        for (auto& t : threads) t.join();
    }, ITERATIONS);
    
    // 测试无伪共享
    benchmark("No False Sharing (aligned)", [&]() {
        std::vector<std::thread> threads;
        threads.emplace_back(worker_no_false_sharing, 0, ITERATIONS);
        threads.emplace_back(worker_no_false_sharing, 1, ITERATIONS);
        for (auto& t : threads) t.join();
    }, ITERATIONS);
    
    return 0;
}

预期运行结果

False Sharing: 2850 ms     ← 慢！
No False Sharing (aligned): 890 ms  ← 快 3.2 倍！

为什么差这么多？ 因为伪共享版本每次修改都需要缓存行失效+重新加载，相当于做了两次主存访问。

六层金字塔总览

Mon, 01 Jan 0001 00:00:00 +0000

3.1 六层金字塔总览

上一节：无　|　下一节：3.2 组件基准

一句话结论

性能测试分六层，每层回答不同的问题。 记住一条法则：要回答「为什么慢」，越往下层（越隔离）越好；要回答「能扛多少」，必须往上走（越接近真实）。

一、用汽车研发理解六层测试

汽车厂商研发一款新车，不会直接让试车员开上高速测。它会经历一整套逐级放大的测试：

汽车研发阶段	对应的性能测试	干什么	成本
零件台架试验	微基准	一个轴承在试验台上转到坏，测寿命	极低
总成试验	组件基准	发动机装在台架上跑，测功率油耗	低
整车转鼓试验	集成基准	整车在实验室里模拟行驶	中
真实道路测试	全链路负载	开上真实道路、真实天气、真实交通	高
碰撞试验	破坏性测试	故意撞毁，看怎么坏、能不能保命	高
耐久路试	浸泡测试	跑 10 万公里，看哪里先磨坏	很高
量产决策	容量测试	决定生产多少台、什么配置	很高

从这张表能读出三件事：

越往上越接近真实，也越贵。 台架试验一小时几百块，风洞试验按小时上万。
越往下越容易定位。 台架上的轴承坏了，你立刻知道是轴承的问题；整车上异响，你要查几十个可能。
每一层都有它才能发现的盲区。 台架测不出风噪，路测才能；路测测不出 10 万公里后的磨损，耐久才能。

性能测试完全一样。

二、六层详解

层级	测什么	时间尺度	单次耗时	能发现	盲区
① 微基准	单个方法/算法	纳秒–微秒	秒级	算法与常数优化、分配热点	看不到 IO、锁、GC 的真实交互
② 组件基准	Repository、序列化、缓存	微秒–毫秒	几十秒	SQL 慢、N+1、序列化开销、索引缺失	无网络、无网关、无真实并发
③ 集成基准	单服务完整启动 + 真实依赖	毫秒	分钟级	连接池、事务、启动预热、AOP 开销	无多服务放大效应
④ 全链路负载	多服务 + 网关 + 真实网络	毫秒–秒	十分钟级	排队、级联、限流、超时配合	成本高、定位难、噪声大
⑤ 专项测试	压力 / 尖峰 / 浸泡	分钟–小时	小时级	拐点、崩溃形态、资源泄漏	不回答「为什么」
⑥ 容量测试	多副本 + 负载分配	小时	小时级	副本数与规格决策	需要接近生产的拓扑

三、核心判断法则

法则一：诊断往下，容量往上

「这个接口为什么慢？」 → 往下走：组件基准 / 微基准 / 剖析
「这个服务能扛多少？」 → 往上走：全链路负载 / 容量测试

混用会怎样：

冰柱图（Icicle Graph）

Mon, 01 Jan 0001 00:00:00 +0000

一、和火焰图的区别

火焰图是自底向上（从 main 开始），冰柱图是自顶向下。

火焰图：
  顶层 = CPU 正在执行的函数（被调用者）
  底层 = 调用者

  main → process → compute  ← 看 compute 占了多少 CPU

冰柱图：
  顶层 = 调用链起点（main）
  底层 = 叶子函数

  main → process → compute  ← 看 main 是怎么一路调用到 compute 的

什么时候用冰柱图？
  你已经知道 main 是入口，想知道 main 调用了哪些路径、每条路径花了多少时间
  火焰图更适合"我有个热点函数 compute，是谁调了它"

分析流程：五步法

Mon, 01 Jan 0001 00:00:00 +0000

6.1 分析流程：五步法

上一节：无　|　下一节：6.2 延迟分解配套代码：06-analysis-and-profiling/01-analysis-workflow

一句话结论

分析就是「提出假设 → 用一条命令证伪 → 更新认知」的循环。 关键纪律是：每个假设都必须能被一条命令证伪——说不出「看什么数据能推翻它」的假设，不是假设，是感想。

一、用「侦探破案」理解分析流程

一个合格的侦探不会说「我觉得是张三是凶手」就结案。流程是：

侦探	性能分析
现场勘查：什么时候、在哪、死了谁、怎么死的	现象量化：哪个接口、多慢、从何时开始、影响范围
尸检与物证：死亡时间、凶器、痕迹	分层拆解：延迟花在哪几段，CPU 花在哪
提出嫌疑人：谁有动机、有机会	提出假设：可能是连接池排队 / GC / 慢查询
审讯验证：逐个排查不在场证明	设计验证：用一条命令确认或排除
结案：证据链完整，能回答「为什么不是别人」	结论：含贡献占比与被排除的假设

注意最后一项：合格的结案报告不只要说「是张三」，还要说「为什么不是李四」。对应到性能分析：你不仅要证明「是连接池排队」，还要说明「为什么不是 GC」。

二、五步详解

第一步：现象量化（不是「慢」，是「谁在多慢的时候慢」）

必须回答的四个问题：

问题	为什么
谁慢？	是所有接口还是某个接口？是全部实例还是某一台？
多慢？	P50 还是 P99？错对率如何？是否达标？
从何时开始？	是突变的（部署引起）还是渐变的（数据量增长/泄漏）？
影响范围？	只影响某类请求？某个地域？某种数据？

用一张表把现象量化：

## 现象量化

| 维度 | 观测值 |
| --- | --- |
| 接口 | GET /orders/{id} |
| 指标 | P99 从 80ms → 400ms（P50 从 20ms → 25ms） |
| 时间 | 2025-01-15 14:30 开始，持续至今 |
| 范围 | 所有实例；只影响带 user_id 的查询；无 user_id 的正常 |
| 错误率 | 0.1%（未变） |
| QPS | 850（未变） |
| CPU | 45%（未变） |
| 变更 | 14:00 有一次部署（版本 v2.3.1） |

这张表本身就排除了很多可能：

单例模式

Mon, 01 Jan 0001 00:00:00 +0000

一、C++11 后的正确写法

class Logger {
public:
    static Logger& instance() {
        static Logger inst;  // C++11 起：线程安全的延迟初始化
        return inst;
    }

    void log(const std::string& msg) { /* ... */ }

    // 防止拷贝和移动
    Logger(const Logger&) = delete;
    Logger& operator=(const Logger&) = delete;

private:
    Logger() = default;  // 私有构造函数，禁止外部创建
    ~Logger() = default;
};

为什么 C++11 后是线程安全的？

C++11 规定：函数内的 static 变量初始化是线程安全的，编译器会在初始化前后插入屏障。
等价于 call_once + once_flag 的效果。

二、什么时候真的需要单例？

应该用：

日志系统（整个进程只需一个日志文件写入点）
硬件资源（如串口、NPU 设备，物理上只有一份）
配置管理器（从文件加载一次配置，全局共享）

不该用：

只是为了"方便全局访问"——这是全局变量的代名词，导致隐式依赖、测试困难
如果你发现 instance() 被几十个文件调用，考虑用依赖注入替换

单变量与对照组

Mon, 01 Jan 0001 00:00:00 +0000

5.1 单变量与对照组

上一节：无　|　下一节：5.2 预热、稳态与运行时长配套代码：05-experiment-design/01-single-variable

一句话结论

一次实验只改一个变量，其余全部冻结。 没有对照组，就没有结论——你只有「改完之后的一组数字」，无法判断它是不是真的因为你的改动而变化。

一、用「试药」理解单变量

假设一个病人吃了三种药，病好了。哪种药起了作用？

可能只有第一种有效；
可能只有第三种有效；
可能前两种无效，第三种和第一种组合才有效；
甚至可能是自愈（和药无关）。

这就是「同时改三处」的问题：你得到了一个结果，但无法归因。

医学上解决这个问题的办法是随机对照试验（RCT）：

试验组：只吃新药
对照组：只吃安慰剂
其余条件（年龄、病程、饮食）尽量一致

性能实验完全一样：

医学	性能实验
试验组	改动后的版本
对照组（安慰剂）	改动前的版本（基线）
随机分组	同样的负载、数据、环境
控制变量	一次只改一个

关键：性能实验里的「安慰剂效应」同样存在——你自己的期望会影响你怎么配置环境、怎么解读数据。这就是为什么需要对照组和客观的判定标准。

二、什么叫「其余全部冻结」

一个合格的实验，除了那一个变量，下面这些都必须完全一致：

类别	具体项
代码	commit hash、依赖版本、构建产物
JVM	JDK 版本、完整启动参数（堆、GC、其他 `-XX`）
机器	实例规格、CPU 型号、是否容器、容器 limit
数据	规模、分布、缓存状态、预热程度
负载	压测脚本（必须版本化）、到达率、并发模型、时长
观测	指标采集方式、火焰图采样参数、测量点
外部条件	时间（避开备份/定时任务）、机房/可用区、下游状态

这张表就是第 1 章 1.7 节「实验元数据」的完整版。任何一项变了，实验就不是单变量的。

三、四种常见的「伪单变量」实验

❶ 同时改代码和 JVM 参数

❌ 实验：把 -Xmx 从 2g 改成 4g，同时加了一个索引
   结果：P99 降了 40%
   结论：？？？（无法归因）

修法：分成两次实验。先改索引（代码层，通常收益更大），测完；再单独调堆。

反向执行调试（Reverse Debugging）

Mon, 01 Jan 0001 00:00:00 +0000

一、什么时候用

你的程序崩溃了，但你想看崩溃前的状态（比如变量是什么时候变成非法值的）。

# 启动调试
(gdb) record                     # 开始记录执行轨迹
(gdb) run                         # 运行程序
...
Program received signal SIGSEGV   # 崩溃了

# 现在可以反向执行
(gdb) reverse-continue            # 往回执行，停在崩溃点的"前一条语句"
(gdb) print ptr                   # 看到 ptr 是 nullptr 或野指针
(gdb) reverse-step                # 一步步往回走
(gdb) watch ptr                   # 观察 ptr 是什么时候改变的
(gdb) reverse-continue            # 继续往回走，停在 ptr 被修改的地方
(gdb) print caller               # 终于找到是谁把 ptr 改坏了

二、限制

GDB 的反向执行需要记录每条指令的执行轨迹。
内存占用：每 1 秒的执行记录大约需要 100MB+ 的内存。
所以只适合调试非常短的崩溃场景（从崩溃前 1 秒开始往回查）。

可变参数模板（Variadic Templates）

Mon, 01 Jan 0001 00:00:00 +0000

一、解决什么问题？

问题：在 C++03 中，你想写一个"接收任意数量参数的函数"，只能靠：

函数重载（写 N 个版本，累死）。
C 风格的 ...（va_args，类型不安全）。

Variadic Templates 的目标：类型安全的任意参数。

二、什么时候用它？

场景	例子
包装/转发函数参数	`std::make_unique<T>(args...)`、`std::thread(func, args...)`
实现类型安全的 printf	`std::format("{} {}", a, b)`
构造 tuple	`std::tuple<int, double, string>(1, 2.0, "hello")`
实现工厂模式	`factory.create<Widget>(arg1, arg2, arg3)`
日志库	`log.info("user {} logged in at {}", name, time)`

三、递归展开：编译器是怎么处理"任意参数"的？

// 你想写一个打印任意数量、任意类型参数的函数：
print(1, 2.0, "hello", 'c');

// Variadic Templates 的做法：递归 + 终止
void print() {}  // ① 终止函数：0 个参数时调用

template <typename T, typename... Args>
void print(T first, Args... rest) {
    std::cout << first << " ";  // 打印第一个
    print(rest...);              // ② 用剩余参数继续递归
}

编译器实例化的过程：

四种执行形态：为什么必须预热

Mon, 01 Jan 0001 00:00:00 +0000

2.1 四种执行形态：为什么必须预热

上一节：无　|　下一节：2.2 JIT 的三大优化与去优化配套代码：02-jvm-performance-basics/01-execution-tiers

一句话结论

JVM 上的同一段代码，随着被调用的次数增加，会经历「解释执行 → C1 编译 → C2 编译」三种形态，性能台阶式提升。 所以你测前 100 次调用，测的其实是最慢的那种形态，它和线上稳态毫无关系。

一、用餐厅厨房理解分层编译

假设你开了一家餐厅，来了一个新厨师。看他怎么做菜：

阶段	厨师状态	类比 JVM
第 1 天	照着菜谱一步一步做，看一行做一步，很慢但立刻能上手	解释执行：逐条读取字节码并执行
做了几天后	熟练了，动作连贯，不用再看菜谱	C1 编译：编译成机器码，快，但只做简单优化
做了几百次之后	老师傅开始重新设计整个流程：提前备料、合并步骤、把常用的调料放在手边	C2 编译：做激进优化（内联、逃逸分析、循环展开）
正在做菜时被老师傅接手	这道菜做到一半，老师傅直接接手继续	OSR（栈上替换）：循环体被热点编译

关键点：

老师傅不会第一天就来。 他需要先观察你做了几百次，确认「这道菜真的是最常点的」，才值得花时间重新设计流程。
重新设计流程很费时间（编译耗时），所以只有足够热的代码才配得上 C2。
所以：前几十次调用的性能，和你线上跑了一小时之后的性能，完全是两回事。

二、三种形态的实际差异

形态	触发条件	相对速度	说明
解释执行	一开始	最慢（可能慢 5–20 倍）	逐条字节码执行，还要做类型检查
C1（客户端编译器）	调用几百次后	中等	编译快、优化少，目标是「尽快摆脱慢速解释」
C2（服务端编译器）	调用数千到上万次后	最快	编译慢、优化激进，会做基于运行时 profile 的推测性优化

具体阈值随 JDK 版本和运行情况变化（大致在数千到上万次调用 / 循环回边这个量级）。不要记具体数字，要记住「有台阶」这个事实。 需要精确数字时用 -XX:+PrintCompilation 观察自己的程序。

在你的 ScoreMaster 上应用 PGO

Mon, 01 Jan 0001 00:00:00 +0000

# 假设你的 ScoreMaster 在 RK3588 上编译

# 第一步：插桩编译
aarch64-linux-gnu-g++ -O2 -fprofile-generate -o scoremaster_test \
    src/main.cpp src/core/*.cpp src/logic/*.cpp \
    -I./3rdparty/rknn/include \
    -L./3rdparty/rknn/lib -lrknnrt

# 第二步：在开发板上用测试视频跑一次
./scoremaster_test --test-video test.h264

# 第三步：优化编译
aarch64-linux-gnu-g++ -O2 -fprofile-use -o scoremaster_opt \
    src/main.cpp src/core/*.cpp src/logic/*.cpp

# 对比优化前后：
# perf stat ./scoremaster_test     → 原始性能
# perf stat ./scoremaster_opt      → PGO 后性能
# 你可能看到 IPC 提升、cache-misses 下降

定长与不定长滑动窗口

Mon, 01 Jan 0001 00:00:00 +0000

一、什么是滑动窗口？

核心思想：在数组/字符串上维护一个"窗口"，通过移动窗口的左右边界，在一次遍历中解决问题。

滑动窗口解决的核心问题是"子数组/子串"类问题——传统需要 $O(N^2)$ 嵌套循环，滑动窗口降到 $O(N)$。

两种窗口：

定长窗口：窗口大小固定，像火车一样整体平移。
不定长窗口：窗口大小动态变化，右边界不断扩张，左边界按条件收缩。

二、不定长窗口——无重复字符的最长子串（LeetCode 3）

问题：给定字符串，找出不包含重复字符的最长子串长度。

思路：

s = "abcabcbb"

窗口演变（用 set 或 map 记录窗口内字符）：
[a]           left=0, right=0 → 不重复，窗口扩大
[a b]         left=0, right=1 → 不重复，窗口扩大
[a b c]       left=0, right=2 → 不重复，窗口扩大
[a b c a]     left=0, right=3 → 'a' 重复！左边界右移
  [b c a]     left=1, right=3 → 不重复，窗口扩大
  [b c a b]   left=1, right=4 → 'b' 重复！左边界右移
    [c a b]   left=2, right=4 → 不重复
    ...继续

最大窗口长度 = 3（"abc" 或 "bca" 或 "cab"）

整体操作流程：

封装流程（Muxing）

Mon, 01 Jan 0001 00:00:00 +0000

一、从编码后的 packet 写出文件/推流的完整流程

struct VideoEncoder {
    AVFormatContext* fmt_ctx = nullptr;
    AVCodecContext*  enc_ctx = nullptr;
    AVStream*        stream = nullptr;
};

bool setup_encoder(VideoEncoder& enc, const char* output_url,
                    int width, int height, int fps) {
    // ① 根据输出 URL 确定容器格式（.mp4 → mp4, .flv → flv, rtmp:// → flv）
    avformat_alloc_output_context2(&enc.fmt_ctx, nullptr, nullptr, output_url);
    if (!enc.fmt_ctx) return false;

    // ② 创建视频流
    enc.stream = avformat_new_stream(enc.fmt_ctx, nullptr);
    enc.stream->time_base = {1, fps};

    // ③ 配置编码器（H.264）
    const AVCodec* codec = avcodec_find_encoder(AV_CODEC_ID_H264);
    enc.enc_ctx = avcodec_alloc_context3(codec);
    enc.enc_ctx->width = width;
    enc.enc_ctx->height = height;
    enc.enc_ctx->time_base = enc.stream->time_base;
    enc.enc_ctx->pix_fmt = AV_PIX_FMT_YUV420P;

    // ④ 低延迟配置（直播场景）
    enc.enc_ctx->gop_size = 30;       // 每 30 帧一个关键帧
    enc.enc_ctx->max_b_frames = 0;    // 不要 B 帧（减少延迟）
    enc.enc_ctx->flags |= AV_CODEC_FLAG_LOW_DELAY;

    avcodec_open2(enc.enc_ctx, codec, nullptr);

    // ⑤ 编码器参数传递给流
    avcodec_parameters_from_context(enc.stream->codecpar, enc.enc_ctx);

    // ⑥ 打开输出文件
    avio_open(&enc.fmt_ctx->pb, output_url, AVIO_FLAG_WRITE);

    // ⑦ 写文件头（MP4 的 ftyp + moov 初始部分）
    avformat_write_header(enc.fmt_ctx, nullptr);
    return true;
}

// 编码并写出一帧
void encode_frame(VideoEncoder& enc, AVFrame* frame) {
    AVPacket* packet = av_packet_alloc();

    // ① 把原始帧送入编码器
    if (avcodec_send_frame(enc.enc_ctx, frame) == 0) {
        while (avcodec_receive_packet(enc.enc_ctx, packet) == 0) {
            // ② 设置时间戳
            av_packet_rescale_ts(packet, enc.enc_ctx->time_base,
                                  enc.stream->time_base);
            packet->stream_index = enc.stream->index;

            // ③ 写出 packet（内部做交错、写入容器的 mdat）
            av_interleaved_write_frame(enc.fmt_ctx, packet);
        }
    }
    av_packet_free(&packet);
}

// 编码结束后记得 flush + 写尾部
void flush_encoder(VideoEncoder& enc) {
    encode_frame(enc, nullptr);  // 送 nullptr 让编码器输出缓存的帧

    // 写文件尾（更新 moov 中的元数据）
    av_write_trailer(enc.fmt_ctx);

    avio_closep(&enc.fmt_ctx->pb);
    avformat_free_context(enc.fmt_ctx);
}

带返回值的 enqueue

Mon, 01 Jan 0001 00:00:00 +0000

class ThreadPool {
    // ... 同第一阶段 ...

    template <typename F, typename... Args>
    auto enqueue(F&& f, Args&&... args)
        -> std::future<std::invoke_result_t<F, Args...>>
    {
        using ReturnType = std::invoke_result_t<F, Args...>;

        // 把函数和参数打包成一个 packaged_task
        auto task = std::make_shared<std::packaged_task<ReturnType()>>(
            std::bind(std::forward<F>(f), std::forward<Args>(args)...)
        );

        std::future<ReturnType> result = task->get_future();

        {
            std::lock_guard<std::mutex> lock(mtx_);
            if (stop_) throw std::runtime_error("enqueue on stopped ThreadPool");
            tasks_.push([task]() { (*task)(); });
        }
        cv_.notify_one();

        return result;
    }
};

用法：

auto future = pool.enqueue(compute, 42);
// 在这里可以干其他事情...
int result = future.get();  // 阻塞等待结果

// 如果 compute 抛异常，future.get() 会重新抛出异常

帧类型

Mon, 01 Jan 0001 00:00:00 +0000

一、I / P / B 帧的物理含义

I 帧（Intra-coded frame）：
  [████████████████████████████]
  完整编码的一帧，不需要参考其他帧
  相当于一张独立的 JPEG 图片
  体积最大，但可随机访问（seek 时找最近的 I 帧）

P 帧（Predictive frame）：
  [    ████                     ]
  只存"和前一帧不一样的地方"
  需要一个参考帧（通常是前一帧）

B 帧（Bidirectionally predictive frame）：
  [       ██                     ]
  参考前后帧，压缩率最高
  需要前后帧解码后才能解码自己 → 延迟最大

GOP（Group of Pictures）：
  I B B P B B P B B P B B I B B P ...
  ├────────── GOP 1 ──────────┤├── GOP 2...
  每 12 帧一个 I 帧（通常）
  GOP 越大压缩率越高，但 seek 越慢

二、把"帧间差异"可视化的 C++ 代码

#include <vector>
#include <cstdint>
#include <cstdio>

// 模拟：计算两帧之间的差异
// 输出是一张"差帧"——像素越亮说明变化越大

struct FrameDiff {
    std::vector<uint8_t> diff_data;
    int width, height;
    int changed_pixels;   // 有多少像素变了（差 > 阈值）
    double change_ratio;  // 变化比例
};

FrameDiff compute_frame_diff(const uint8_t* frame1, const uint8_t* frame2,
                              int width, int height, int threshold = 16) {
    FrameDiff result;
    result.width = width;
    result.height = height;
    result.diff_data.resize(width * height);
    result.changed_pixels = 0;

    for (int i = 0; i < width * height; i++) {
        int diff = abs((int)frame1[i] - (int)frame2[i]);
        // 差帧可视化：差异越大像素越亮
        result.diff_data[i] = std::min(diff * 4, 255);

        if (diff > threshold) {
            result.changed_pixels++;
        }
    }

    result.change_ratio = (double)result.changed_pixels / (width * height);
    return result;
}

// 模拟"I 帧 + P 帧"的存储方式
struct CompressedFrame {
    bool is_keyframe;      // I 帧还是 P 帧
    std::vector<uint8_t> data;  // 如果是 P 帧，只存差异+位置
    size_t data_size;      // 方便对比大小
};

// I 帧：存所有像素
CompressedFrame encode_iframe(const uint8_t* frame, int w, int h) {
    CompressedFrame cf;
    cf.is_keyframe = true;
    cf.data.assign(frame, frame + w * h);  // 无损存储
    cf.data_size = cf.data.size();
    return cf;
}

// P 帧：只存和参考帧的差异
CompressedFrame encode_pframe(const uint8_t* current, const uint8_t* reference,
                               int w, int h, int threshold = 16) {
    CompressedFrame cf;
    cf.is_keyframe = false;
    cf.data.clear();

    for (int i = 0; i < w * h; i++) {
        int diff = abs((int)current[i] - (int)reference[i]);
        if (diff > threshold) {
            // 存 "位置:旧值→新值"（实际编码器中远更复杂）
            int pos = i;
            cf.data.push_back((pos >> 8) & 0xFF);
            cf.data.push_back(pos & 0xFF);
            cf.data.push_back(current[i]);
        }
    }
    cf.data_size = cf.data.size();
    return cf;
}

// 测试：对比 I 帧和 P 帧的大小
void test_frame_types() {
    const int W = 320, H = 240;
    std::vector<uint8_t> frame1(W * H), frame2(W * H);

    // 生成两帧：第二帧只有右上角 50x50 的区域变化
    for (int i = 0; i < W * H; i++) {
        frame1[i] = 128;  // 灰色背景
        frame2[i] = 128;
    }
    // 在第二帧的右上角画一个白色方块
    for (int y = 20; y < 70; y++) {
        for (int x = W - 70; x < W - 20; x++) {
            frame2[y * W + x] = 240;
        }
    }

    auto iframe = encode_iframe(frame1.data(), W, H);
    auto pframe = encode_pframe(frame2.data(), frame1.data(), W, H);

    std::cout << "I 帧大小: " << iframe.data_size << " bytes\n";
    std::cout << "P 帧大小: " << pframe.data_size << " bytes\n";
    std::cout << "压缩比:   " << (double)iframe.data_size / pframe.data_size << "x\n";

    auto diff = compute_frame_diff(frame1.data(), frame2.data(), W, H);
    std::cout << "变化像素: " << diff.changed_pixels << "/" << (W*H)
              << " (" << diff.change_ratio * 100 << "%)\n";
}

// 输出：
// I 帧大小: 76800 bytes
// P 帧大小: 7935 bytes
// 压缩比:   9.6x
// 变化像素: 2500/76800 (3.25%)
//
// P 帧比 I 帧小了 9.6 倍——只存变化的部分。
// 实际编码器（H.264）的压缩比更大，因为还用了 DCT + 量化。

常用调试命令

Mon, 01 Jan 0001 00:00:00 +0000

// 检测原始 PCM 数据是否正常（用 Audacity 或查看波形）
// 最简单的检测：打印前 10 个样本
void inspect_pcm(const int16_t* data, int count) {
    printf("First 10 PCM samples:\n");
    for (int i = 0; i < min(10, count); i++) {
        printf("  [%d] = %d\n", i, data[i]);
    }

    // 检查是否全是 0（静音文件）
    bool all_zero = true;
    for (int i = 0; i < count; i++) {
        if (data[i] != 0) { all_zero = false; break; }
    }
    printf("All zero: %s\n", all_zero ? "YES (silent!)" : "NO");
}

// 检测视频帧率是否稳定
void check_fps_stability(const vector<int64_t>& pts_list) {
    printf("Frame timestamps (ms):\n");
    for (size_t i = 0; i < pts_list.size(); i++) {
        if (i > 0) {
            int64_t delta = pts_list[i] - pts_list[i-1];
            printf("  frame %zu: delta=%lld ms (expected %.1f fps)\n",
                   i, delta, 1000.0 / delta);
        }
    }
}

归并排序（MergeSort）

Mon, 01 Jan 0001 00:00:00 +0000

一、核心流程：分治 + 合并

[3, 7, 8, 5, 2, 1, 9, 4]
         ↓ 分割
[3, 7, 8, 5]    [2, 1, 9, 4]
   ↓ 分割           ↓ 分割
[3, 7] [8, 5]   [2, 1] [9, 4]
   ↓ 分割           ↓ 分割
[3][7] [8][5]   [2][1] [9][4]
   ↓ 合并           ↓ 合并
[3, 7] [5, 8]   [1, 2] [4, 9]
   ↓ 合并           ↓ 合并
[3, 5, 7, 8]    [1, 2, 4, 9]
         ↓ 合并
[1, 2, 3, 4, 5, 7, 8, 9]

二、自顶向下（递归）实现

merge 整体操作流程：

指标分四层，缺一层就无法定位

Mon, 01 Jan 0001 00:00:00 +0000

1.1 指标分四层，缺一层就无法定位

上一节：无　|　下一节：1.2 百分位不可平均配套代码：01-metrics-and-slo/01-four-layers-of-metrics

一句话结论

性能指标分四层：业务层、延迟层、资源层、饱和度层。 只监控前两层，你会在「服务变慢了」和「为什么慢」之间卡住；而饱和度层是最早的预警信号，它在用户受影响之前就开始报警。

一、用汽车仪表盘理解「为什么指标要分层」

想象你开车，车上只有一个速度表：

速度表显示 60 km/h —— 车在正常行驶。
突然，速度掉到 20 km/h。

你知道出问题了，但完全不知道原因：是没油了？发动机过热？轮胎漏气？还是前面堵车？

现在把仪表盘补全：

仪表	对应层级	告诉你什么
速度表	业务层	车跑得快不快（QPS）
乘客的等待时间	延迟层	体验好不好（P99）
油量、转速、水温	资源层	消耗了什么（CPU / 内存 / GC）
水温警告灯、油量警示灯	饱和度层	离出问题还有多远

关键洞察：速度和等待时间都是「已经发生的结果」，而警告灯是「即将发生问题的预警」。

速度掉到 20 km/h 时，问题已经发生了，你只能被动应对。
水温警告灯亮起时，你还有时间靠边停车。

性能工程里最值钱的指标，是那些「用户还没受影响，但系统已经在告警」的指标。 这就是饱和度层。

二、四层指标详解

第 1 层：业务层 —— 「服务好不好用」

指标	含义	常见坑
QPS / RPS	每秒处理的请求数	分母应该是「成功完成」的请求
错误率	失败请求占比	必须与延迟一起看（否则会「优化」出更多错误）
超时率	超时请求占比	与错误率分开统计（超时和报错的处理方式不同）
Apdex	满意度指标（快 / 可接受 / 慢三档）	阈值必须来自业务可感知边界，不能拍脑袋

回答的问题：用户现在体验如何？

无锁自旋（Spinlock）的平替与退避策略（Backoff）

Mon, 01 Jan 0001 00:00:00 +0000

这个问题极其硬核，触及了高性能并发编程的核心痛点：如何在"极致性能"和"CPU文明"之间找到平衡。

很多新手写的自旋锁，其实就是一颗CPU核弹——一跑起来，核心温度直接飙高10度，功耗拉满，整个系统的吞吐量断崖式下跌。我们今天就把自旋的代价、退避的策略、硬件指令的妙用彻底讲透。

1. 为什么死循环会把 CPU 烧满？—— 执行单元的"狂奔"

当你写一个死循环自旋时：

while (flag.load() == true) {
    // 什么都不做，继续循环
}

硬件层面发生了什么？

执行单元全速运转：CPU的算术逻辑单元（ALU）以每纳秒一次的频率执行 load 指令和比较跳转指令。
流水线满负荷：现代CPU是超标量架构（如每周期发射4-8条指令），它会拼命预测、预取、执行这些无意义的跳转。
内存总线风暴：每次 load 都会去读 flag 所在的内存/缓存行，导致该缓存行在核心间高频震荡（乒乓）。
功耗飙升：动态频率缩放（DVFS）检测到高负载，自动提升电压和主频（如从2.0GHz飙升到4.5GHz），产生大量热量。

数据对比：

执行 pause 的自旋：CPU 进入低功耗空闲状态，功耗 ~5W。
不加 pause 的死循环：CPU 全速狂奔，功耗 ~30W（6倍差距！），且完全阻塞了同一核心上超线程兄弟线程的执行。

2. 硬件救兵：`__builtin_ia32_pause()` (即 `pause` 指令)

pause 是一条专门为了自旋锁设计的硬件指令。它在汇编层面的本质是：

spin_loop:
    pause              ; 等待几个时钟周期（降低功耗）
    cmp [flag], 0
    jne spin_loop

pause 的三重魔法：

降低功耗 & 减少热量：告诉CPU"我在自旋，别跑那么快"。这会让流水线停顿（Stall）几十到几百个周期（具体取决于CPU型号）。
释放流水线资源：让出执行单元给超线程的另一个线程，实现超线程友好。
避免内存顺序冲突：在x86的强内存模型下，pause 相当于告诉CPU"别那么激进地执行Load指令"，减少了Store Buffer的无效冲刷。

3. 退避策略（Backoff Strategy）：从"莽夫"到"智者"

如果只用 pause，在极高竞争下依然有问题：所有线程都在高频 pause+load，缓存行依然在乒乓。我们需要退避策略——“等得越久，动作越轻”。

指数退避（Exponential Backoff）—— 黄金标准

#include <atomic>
#include <thread>
#include <chrono>

class BackoffSpinLock {
    std::atomic<bool> flag{false};

public:
    void lock() {
        int backoff = 1; // 初始退避周期
        const int MAX_BACKOFF = 1 << 16; // 最大退避 (65536周期)
        
        while (true) {
            // 1. 快速路径：尝试抢锁
            if (!flag.exchange(true, std::memory_order_acquire)) {
                return; // 成功
            }
            
            // 2. 抢锁失败，开始退避
            for (int i = 0; i < backoff; ++i) {
                __builtin_ia32_pause(); // 硬件让出流水线
            }
            
            // 3. 指数增长退避时间（但有上限）
            if (backoff < MAX_BACKOFF) {
                backoff <<= 1; // 翻倍：1, 2, 4, 8, 16, ..., 65536
            }
            
            // 4. 如果退避太久了（如超过100万周期），干脆让出CPU（系统调用）
            if (backoff > 10000) {
                std::this_thread::yield(); // 触发上下文切换，让给其他进程
                backoff = 1; // 重置，重新开始快速尝试
            }
        }
    }

    void unlock() {
        flag.store(false, std::memory_order_release);
    }
};

指数退避的硬件效果

竞争激烈时 (16个线程抢一把锁):

[无退避] 
线程1-16: pause, pause, pause, ... (都卡在CAS上)
缓存行: 在16个核心间乱飞 → 延迟飙升到 500ns/次

[指数退避]
线程1抢到锁 → 执行临界区 (1μs)
线程2尝试失败 → 退避 10ns (pause×2)
线程3尝试失败 → 退避 20ns (pause×4)
...
临界区结束时，大部分线程还在退避中 → 缓存行只在线程1和少数活跃线程间传递
→ 延迟降低到 50ns/次 → 性能提升10倍！

4. 高性能自旋锁的最佳实践（工业级）

结合 pause + 指数退避 + yield 的三级防御：

时间轮（Timing Wheel）

Mon, 01 Jan 0001 00:00:00 +0000

一、优先队列定时器的瓶颈在哪？

如果你的系统有百万级定时器（比如网络服务器有 100 万个连接，每个连接保活定时器 60s），优先队列的 $O(\log N)$ 插入可能成为瓶颈。

时间轮把插入降到 $O(1)$。

二、简单时间轮

一个简单的单层时间轮（假设精度 1 秒，共 8 个槽）：

槽 0: [任务A(8s后)]  ← 指针 current
槽 1: []
槽 2: [任务B(2s后)]
槽 3: []
槽 4: []
槽 5: [任务C(5s后)]
槽 6: []
槽 7: []

指针每秒转动一格：
  current=0 → 执行槽0里的任务
  current=1 → 执行槽1里的任务
  ...

插入任务时：计算 expiry = now + delay
槽位 = (current + delay) % 8
直接放入对应槽 → O(1)

三、分层时间轮

单层时间轮的槽数 = 最大延迟。如果需要 1 小时半的定时器，单层需要 3600 个槽。分层时间轮用多层来解决：

核心思想：分离定时器线程和工作线程

Mon, 01 Jan 0001 00:00:00 +0000

定时器线程：只负责"什么时候该做什么"
    ↓ (到时间了，把任务提交到线程池)
工作线程池：只负责"做什么"
    ↓ (执行实际任务)

为什么定时器线程不直接执行任务？
  如果任务耗时 1 秒，定时器线程被阻塞 1 秒，期间所有定时器都延迟了！
  所以定时器线程只做"触发"，工作线程做"执行"。

用 Callgrind 分析你的 SPSC 队列

Mon, 01 Jan 0001 00:00:00 +0000

// 对比 SPSC Ring Buffer 和 Mutex 队列的指令级开销

#include <atomic>
#include <mutex>
#include <queue>

// SPSC 队列（你的 SimpleAsyncLogger 风格）
template<typename T>
class SPSCQueue {
    std::atomic<size_t> head_{0};
    std::atomic<size_t> tail_{0};
    T buffer_[256];

public:
    bool push(T val) {
        size_t h = head_.load(std::memory_order_relaxed);
        size_t t = tail_.load(std::memory_order_acquire);
        size_t next = (h + 1) & 255;
        if (next == t) return false;  // full
        buffer_[h] = val;
        head_.store(next, std::memory_order_release);
        return true;
    }

    bool pop(T& val) {
        size_t t = tail_.load(std::memory_order_relaxed);
        size_t h = head_.load(std::memory_order_acquire);
        if (t == h) return false;  // empty
        val = buffer_[t];
        tail_.store((t + 1) & 255, std::memory_order_release);
        return true;
    }
};

// Mutex 队列
template<typename T>
class MutexQueue {
    std::queue<T> q_;
    std::mutex mtx_;

public:
    void push(T val) {
        std::lock_guard<std::mutex> lock(mtx_);
        q_.push(val);
    }

    bool pop(T& val) {
        std::lock_guard<std::mutex> lock(mtx_);
        if (q_.empty()) return false;
        val = q_.front();
        q_.pop();
        return true;
    }
};

# 用 Callgrind 对比：
valgrind --tool=callgrind ./bench_spsc
valgrind --tool=callgrind ./bench_mutex

# callgrind_annotate 对比结果：

# SPSC Queue 的 Callgrind 输出：
# Ir: 2,100,000（每次 push 只执行大约 21 条指令）
# L1m: 1,200（缓存命中率极高，因为 head/tail 在独立缓存行）

# Mutex Queue 的 Callgrind 输出：
# Ir: 23,500,000（每次 push 约 235 条指令，多了 lock/unlock 的系统调用）
# L1m: 89,000（mutex 对象需要跨核心同步）

# SPSC 的指令数只有 Mutex 版本的 1/10。
# 面试时可以展示这个数字——"我用 Callgrind 精确验证了 SPSC 比 Mutex 快 10 倍"

经典并发数据结构手写

Mon, 01 Jan 0001 00:00:00 +0000

一、手写 MPSC（多写一读）阻塞队列

这是异步日志库的核心结构——多个生产者（业务线程）写日志，一个消费者（刷盘线程）读日志。

难点：多写需要保护，单读不需要。

整体操作流程：

push（多生产者）：
1. 获取互斥锁，保护队列的并发访问。
2. 如果队列已停止，丢弃数据。
3. 将数据推入队列。
4. 释放锁后调用 notify_one 唤醒消费者（解锁后再通知，减少线程唤醒时的锁争用）。
pop（单消费者）：
1. 获取互斥锁。
2. 等待条件：队列不为空或队列已停止（cv.wait 自动释放/重获锁）。
3. 如果已停止且队列为空，返回默认值（或抛异常）。
4. 取出队首元素并返回。
stop：
1. 获取锁，设置停止标志。
2. notify_all 唤醒消费者线程，使其从 wait 中退出。

template <typename T>
class MPSCBlockingQueue {
    std::queue<T> queue_;
    std::mutex mtx_;
    std::condition_variable cv_;
    bool stopped_ = false;

public:
    void push(T item) {
        {
            std::lock_guard<std::mutex> lock(mtx_);// ① 获取锁（多生产者互斥）
            if (stopped_) return;                  // ② 已停止则丢弃
            queue_.push(std::move(item));           // ③ 入队
        }                                          // ④ 解锁
        cv_.notify_one();                          // ⑤ 唤醒消费者（解锁后 notify 减少竞争）
    }

    T pop() {
        std::unique_lock<std::mutex> lock(mtx_);   // ① 获取锁
        cv_.wait(lock, [this] {                    // ② 等待条件：有数据或已停止
            return stopped_ || !queue_.empty();
        });

        if (stopped_ && queue_.empty()) {
            return T{};                            // ③ 已停止且无数据 → 返回空值
        }

        T item = std::move(queue_.front());         // ④ 取出队首元素
        queue_.pop();
        return item;                                // ⑤ 返回数据
    }

    void stop() {
        {
            std::lock_guard<std::mutex> lock(mtx_);// ① 获取锁
            stopped_ = true;                        // ② 设置停止标志
        }
        cv_.notify_all();                           // ③ 唤醒所有等待的线程
    }
};

为什么叫 MPSC？

编译期类型萃取（Type Traits）与 SFINAE

Mon, 01 Jan 0001 00:00:00 +0000

一、Type Traits 的本质

#include <type_traits>

// is_pointer 的底层实现（简化版）
template <typename T>
struct is_pointer_impl : false_type {};  // 默认不是指针

template <typename T>
struct is_pointer_impl<T*> : true_type {}; // T* 是指针

// 使用
static_assert(is_pointer_impl<int>::value == false);
static_assert(is_pointer_impl<int*>::value == true);

true_type 和 false_type 是什么？

struct true_type  { static constexpr bool value = true; };
struct false_type { static constexpr bool value = false; };

就这么简单——type traits 就是编译期的布尔值，通过模板特化在编译期确定。

二、SFINAE 的精髓

SFINAE（Substitution Failure Is Not An Error）—— 替换失败不是错误。

// 对于有 size() 成员的类型启用
template <typename T>
auto get_size(const T& x) -> decltype(x.size()) {
    return x.size();
}

// 对于没有 size() 但有 length() 的类型启用
template <typename T>
auto get_size(const T& x) -> decltype(x.length()) {
    return x.length();
}

// 对于没有 size() 也没有 length() 的类型启用
int get_size(...) {
    return 0;
}

// 使用
vector<int> v(10);
string s = "hello";
int n = 42;

get_size(v); // 第一个版本：v.size()
get_size(s); // 第一个版本：s.size()
get_size(n); // 第三个版本：... 匹配

编译器的视角：

观察者模式——用 vector\ 替代虚基类

Mon, 01 Jan 0001 00:00:00 +0000

一、传统观察者 vs 现代写法

传统：

struct Observer {
    virtual void onEvent(const Event&) = 0;
};

class Subject {
    std::vector<Observer*> observers_;
public:
    void attach(Observer* o) { observers_.push_back(o); }
    void notify(const Event& e) {
        for (auto* o : observers_) o->onEvent(e);
    }
};

问题：Observer 必须继承虚基类，生命周期由 Subject 外部管理（悬垂指针风险）。

现代写法：

class EventBus {
    std::vector<std::function<void(const Event&)>> handlers_;

public:
    // 接受 lambda、函数指针、任何可调用对象
    template <typename F>
    void subscribe(F&& handler) {
        handlers_.push_back(std::forward<F>(handler));
    }

    void fire(const Event& event) {
        for (auto& h : handlers_) {
            h(event);
        }
    }
};

// 使用——不需要继承任何东西
EventBus bus;
bus.subscribe([](const Event& e) {
    std::cout << "received: " << e.type << "\n";
});

Server server;
server.on_connect([&bus](ConnectionPtr conn) {
    bus.fire(Event{"connected"});
});

二、生命周期管理

现代观察者模式的最大问题：订阅者的生命周期。如果订阅者先于 EventBus 销毁，但订阅 lambda 捕获了订阅者的 this 指针，EventBus 触发事件时就是 Use-After-Free。

负载生成器：先选模型，再选工具

Mon, 01 Jan 0001 00:00:00 +0000

4.1 负载生成器：先选模型，再选工具

上一节：无　|　下一节：4.2 两类现象，两条路径配套代码：04-toolchain/01-load-generators 前置：0.6 协调遗漏（本节是它的工程落地）

一句话结论

选「开环还是闭环」比选「用哪个工具」重要得多。 同一份代码、同一个服务，两种模型测出的 P99 可能差几百倍——而工具之间的差别通常只有几成。

一、用「跑步机」理解开环与闭环

健身房里有两台跑步机：

跑步机 A（闭环）：跟着你跑

你跑得快，它就快；你跑不动了，它就慢下来。

结果：你永远不会「跑崩」，因为机器会迁就你。跑了 30 分钟，你觉得自己状态不错。

跑步机 B（开环）：按设定速度跑

设定 12 km/h，不管你跟不跟得上。你跟不上就掉下来（或者被拖着走）。

结果：你会真实地暴露极限——什么时候开始吃力、什么时候彻底跟不上。

对应到压测：

	闭环（VU 模型）	开环（到达率模型）
机制	收到响应才发下一个请求	按固定节奏发，不管响应
服务变慢时	自动减少发压	继续按计划发压（请求开始排队）
结果	P99 被系统性低估	暴露真实尾延迟
类比	「你跑不动机器就减速」	「机器不等你」

复习第 0 章 0.6 节：当服务端卡顿 1 秒时，闭环工具在这 1 秒内几乎不发请求，所以这次卡顿只被记录成 1 个慢样本，而不是几百个。服务越糟，报告越好看。

结论：默认用开环。 只有在明确要测「固定并发下的体验」时才用闭环。

二、工具对照表

工具	模型支持	脚本语言	适合场景	注意
k6	开环 + 闭环（多种 executor）	JavaScript	首选：脚本化、CI 友好、阈值断言、多场景	需要 `preAllocatedVUs` 配够
Gatling	开环（injection profile）	Scala DSL	报告漂亮、表达力强	JVM 自身需要预热与调优
wrk2	开环（恒定速率 + HdrHistogram）	Lua（弱）	验证尾延迟、轻量高并发	脚本能力弱，适合单一接口
JMeter	闭环为主	GUI/XML	协议覆盖广、插件生态	资源占用高，GUI 模式不适合正式压测
Vegeta	开环	CLI	简单场景、快速验证	报告与生态弱
Locust	开环/闭环	Python	分布式压测	单机性能一般

选择建议：

配套代码：A/B/A' 对照编排与环境漂移检测

Mon, 01 Jan 0001 00:00:00 +0000

5.1 配套代码：A/B/A’ 对照编排与环境漂移检测

对应小节：5.1 单变量与对照组核心：回滚验证（A→B→A’） 能把「环境漂移」和「真实的优化效果」区分开。

一、A/B/A’ 实验编排脚本

#!/usr/bin/env bash
# tools/run-aba-experiment.sh <EXP_ID> <VARIANT_A_REF> <VARIANT_B_REF>
#
# 执行 A → B → A' 三轮对照实验。
# A  = 基线
# B  = 优化后的版本
# A' = 回滚到基线（用于检测环境漂移）
#
# 用法示例：
#   tools/run-aba-experiment.sh E06-index-opt main feature/add-index
set -euo pipefail

EXP_ID="${1:?usage: run-aba-experiment.sh <EXP_ID> <ref_A> <ref_B>}"
REF_A="${2:?}"
REF_B="${3:?}"
DIR="docs/experiments/${EXP_ID}"
ROUNDS="${ROUNDS:-3}"          # 每个变体跑几轮

mkdir -p "$DIR/results"

echo "═══ A/B/A' 对照实验：$EXP_ID ═══"
echo "  A  = $REF_A"
echo "  B  = $REF_B"
echo "  A' = $REF_A（回滚）"
echo "  每个变体 $ROUNDS 轮"
echo

# ① 环境元数据（只记录一次，因为环境应该不变）
tools/collect-env.sh "$EXP_ID"
tools/check-environment.sh "$EXP_ID"

run_variant() {
  local variant="$1"      # A / B / A2
  local ref="$2"

  echo "───────── 变体 $variant（$ref）─────────"

  # 切换到对应版本
  git checkout "$ref" -- . 2>/dev/null || {
    echo "❌ 无法切换到 $ref，请确认分支/commit 存在且工作区干净"
    exit 1
  }
  echo "当前 commit: $(git rev-parse --short HEAD)"

  # 构建
  ./gradlew build -q

  for i in $(seq 1 "$ROUNDS"); do
    echo "  [轮 $i/$ROUNDS]"
    # 重启服务（确保同一初始状态）
    scripts/restart-app.sh "$DIR/results/gc-$variant-$i.log"
    sleep 5
    # 独立预热
    BASE_URL=http://127.0.0.1:8080 k6 run --quiet --vus 20 --duration 60s \
      loadtest/profile-constant.js > /dev/null
    # 正式测量
    BASE_URL=http://127.0.0.1:8080 RATE=500 DURATION=5m \
    k6 run --summary-export="$DIR/results/$variant-round-$i.json" \
           loadtest/profile-constant.js > /dev/null
    echo "    ✅ 完成"
  done
}

run_variant "A"  "$REF_A"
run_variant "B"  "$REF_B"
run_variant "A2" "$REF_A"

echo
echo "═══ 三轮完成，开始分析 ═══"
python3 tools/analyze-aba.py "$DIR/results"

二、A/B/A’ 结果分析（检测环境漂移）

# tools/analyze-aba.py <results_dir>
"""
分析 A/B/A' 三轮实验：
  - 计算每个变体的指标中位数
  - 检测环境漂移（A 与 A' 的差异）
  - 用 A 与 A' 的漂移幅度校正 B 的效应

判据：
  漂移 = |A' - A| / A
  如果 漂移 < 5%     → 环境稳定，B 的效应可信
  如果 漂移 5% ~ 15% → 环境有轻微漂移，B 的效应需要打折看待
  如果 漂移 > 15%    → 环境不稳定，实验需要重做
"""
import json
import pathlib
import statistics as st
import sys


def load_variant(results_dir, variant):
    """加载某个变体的所有轮次"""
    files = sorted(pathlib.Path(results_dir).glob(f"{variant}-round-*.json"))
    rounds = []
    for f in files:
        m = json.loads(f.read_text())["metrics"]
        d = m["http_req_duration"]
        rounds.append({
            "qps": m["http_reqs"]["rate"],
            "p50": d.get("med", 0),
            "p95": d.get("p(95)", 0),
            "p99": d.get("p(99)", 0),
            "err": m["http_req_failed"]["rate"],
        })
    return rounds


def summarize(rounds, key):
    vals = [r[key] for r in rounds]
    return {
        "values": vals,
        "median": st.median(vals),
        "stdev": st.stdev(vals) if len(vals) > 1 else 0.0,
        "cv": (st.stdev(vals) / st.median(vals) * 100) if len(vals) > 1 and st.median(vals) else 0.0,
    }


def main(results_dir):
    A = load_variant(results_dir, "A")
    B = load_variant(results_dir, "B")
    A2 = load_variant(results_dir, "A2")

    if not (A and B and A2):
        print(f"❌ 数据不全：A={len(A)} B={len(B)} A'={len(A2)} 轮")
        print("   请确认文件名格式为 A-round-1.json / B-round-1.json / A2-round-1.json")
        return

    print("═" * 72)
    print("A/B/A' 对照实验分析")
    print("═" * 72)
    print()

    for key, label in [("qps", "QPS"), ("p50", "P50(ms)"), ("p95", "P95(ms)"), ("p99", "P99(ms)")]:
        sa, sb, sa2 = summarize(A, key), summarize(B, key), summarize(A2, key)

        print(f"【{label}】")
        print(f"  A  : {sa['median']:8.2f}  轮间CV {sa['cv']:5.1f}%   值={[round(v,1) for v in sa['values']]}")
        print(f"  B  : {sb['median']:8.2f}  轮间CV {sb['cv']:5.1f}%   值={[round(v,1) for v in sb['values']]}")
        print(f"  A' : {sa2['median']:8.2f}  轮间CV {sa2['cv']:5.1f}%   值={[round(v,1) for v in sa2['values']]}")

        # 环境漂移
        drift = abs(sa2["median"] - sa["median"]) / sa["median"] * 100 if sa["median"] else 0
        # B 的效应
        effect = (sb["median"] - sa["median"]) / sa["median"] * 100 if sa["median"] else 0
        # 用漂移校正后的效应（取 A 和 A' 的平均作为"真实基线"）
        true_baseline = (sa["median"] + sa2["median"]) / 2
        corrected = (sb["median"] - true_baseline) / true_baseline * 100 if true_baseline else 0

        print(f"  环境漂移 |A' - A| / A = {drift:5.1f}%")
        print(f"  B 的原始效应            = {effect:+6.1f}%")
        print(f"  用漂移校正后的效应       = {corrected:+6.1f}%")

        if drift < 5:
            print("  ✅ 环境稳定，B 的效应可信")
        elif drift < 15:
            print("  ⚠️  环境有轻微漂移，建议以【校正后的效应】作为结论")
        else:
            print("  ❌ 环境不稳定（漂移 > 15%），实验需要重做")

        # 与噪声底线的对比提示
        max_cv = max(sa["cv"], sb["cv"], sa2["cv"])
        if max_cv > 10:
            print(f"  ⚠️  轮间 CV 最大 {max_cv:.1f}% > 10%，环境噪声偏大（第 7 节）")
        print()

    print("═" * 72)
    print("结论怎么写（模板）：")
    print()
    print("  变体 A（基线）P99 中位数 = ___ ms（轮间 CV ___%）")
    print("  变体 B（优化）P99 中位数 = ___ ms")
    print("  变体 A'（回滚）P99 中位数 = ___ ms")
    print()
    print("  环境漂移 = ___%（< 5% 说明环境稳定）")
    print("  优化效应 = ___%（校正后 ___%）")
    print("  与噪声底线（___%）对比：☐ 大于 ☐ 小于")
    print("  统计检验：Mann-Whitney U, p = ___")
    print("  结论：☐ 优化有效且可信 ☐ 无法确认 ☐ 环境不稳定需重做")
    print("═" * 72)


if __name__ == "__main__":
    main(sys.argv[1] if len(sys.argv) > 1 else "docs/experiments/E06/results")

三、预期输出

════════════════════════════════════════════════════════════════════════
A/B/A' 对照实验分析
════════════════════════════════════════════════════════════════════════

【P99(ms)】
  A  :   210.30  轮间CV   2.1%   值=[207.5, 210.3, 213.1]
  B  :    95.20  轮间CV   3.1%   值=[93.2, 95.2, 96.1]
  A' :   208.70  轮间CV   1.8%   值=[206.9, 208.7, 211.4]
  环境漂移 |A' - A| / A =   0.8%
  B 的原始效应            = -54.7%
  用漂移校正后的效应       = -54.4%
  ✅ 环境稳定，B 的效应可信

这份结论的完整表述：

配套代码：k6 进阶用法与压测机自查

Mon, 01 Jan 0001 00:00:00 +0000

4.1 配套代码：k6 进阶用法与压测机自查

对应小节：4.1 负载生成器基础的三种曲线在第 3 章 code 04，这里只给本章新增的部分。

一、多场景组合（一个脚本测多种流量）

// loadtest/multi-scenario.js
import http from 'k6/http';
import { check } from 'k6';
import { Trend, Rate, Counter } from 'k6/metrics';

// 自定义指标（对应第 1 章的四层指标）
const readLatency = new Trend('read_latency_ms', true);
const writeLatency = new Trend('write_latency_ms', true);
const businessErrors = new Counter('business_errors');
const okRate = new Rate('ok_rate');

export const options = {
  scenarios: {
    // 读路径：占 90% 流量，开环恒定
    read_path: {
      executor: 'constant-arrival-rate',
      rate: 450, timeUnit: '1s', duration: '10m',
      preAllocatedVUs: 500, maxVUs: 3000,
      exec: 'readScenario',
      tags: { path: 'read' },
    },
    // 写路径：占 10% 流量，开环较低速率
    write_path: {
      executor: 'constant-arrival-rate',
      rate: 50, timeUnit: '1s', duration: '10m',
      preAllocatedVUs: 200, maxVUs: 1000,
      exec: 'writeScenario',
      startTime: '30s',              // 错开启动，避免冷启动叠加
      tags: { path: 'write' },
    },
  },
  thresholds: {
    'http_req_failed{path:read}': ['rate<0.01'],
    'http_req_duration{path:read}': ['p(99)<200'],
    'read_latency_ms': ['p(99)<200'],
    'write_latency_ms': ['p(99)<500'],
    ok_rate: ['rate>0.99'],
    business_errors: ['count<100'],
  },
  discardResponseBodies: true,
  summaryTrendStats: ['avg', 'min', 'med', 'p(90)', 'p(95)', 'p(99)', 'p(99.9)', 'max'],
};

function zipf(max) {
  return Math.max(1, Math.floor(max * Math.pow(Math.random(), 3)) + 1);
}

export function readScenario() {
  const res = http.get(`${__ENV.BASE_URL}/orders/${zipf(1_000_000)}`, {
    tags: { name: 'GET /orders/{id}' },      // ⚠️ 路由模板，不是具体 URL
  });
  readLatency.add(res.timings.duration);
  const ok = check(res, { 'read ok': (r) => r.status === 200 });
  okRate.add(ok);
  if (!ok) businessErrors.add(1);
}

export function writeScenario() {
  const payload = JSON.stringify({ userId: Math.floor(Math.random() * 1000) + 1, amount: 100 });
  const res = http.post(`${__ENV.BASE_URL}/orders`, payload, {
    headers: { 'Content-Type': 'application/json', 'X-Load-Test': 'true' },
    tags: { name: 'POST /orders' },
  });
  writeLatency.add(res.timings.duration);
  const ok = check(res, { 'write ok': (r) => r.status === 201 });
  okRate.add(ok);
  if (!ok) businessErrors.add(1);
}

两个值得注意的写法：

配套代码：从延迟分解到优先级排序

Mon, 01 Jan 0001 00:00:00 +0000

7.1 配套代码：从延迟分解到优先级排序

对应小节：7.1 优先级金字塔把「延迟分解的结果」自动映射到「该从哪一级开始优化」。

一、延迟分解 → 层级映射

# tools/prioritize.py
"""
从延迟分解结果推导优化优先级。

输入：各段的占比（可从第 6.2 节的 decompose-latency.py 得到）
输出：按层级排序的优化建议
"""
import sys

# 延迟分解的段 → 对应的金字塔层级与典型动作
SEGMENT_TO_LEVEL = {
    "client_queue": {
        "label": "网络 + 客户端排队",
        "level": 1,
        "level_name": "① 先问要不要做",
        "actions": [
            "减少返回字段（少传数据 → 省 CPU/内存/网络）",
            "启用响应压缩（大响应体）",
            "就近部署（CDN / 同可用区）",
            "检查压测客户端是否与被测服务同机",
        ],
    },
    "service_queue": {
        "label": "服务排队（进 handler 之前）",
        "level": 3,
        "level_name": "③ 架构与并发",
        "actions": [
            "查连接池 pending（第 6.5 节）",
            "查线程池队列深度",
            "检查 RUNNABLE 线程数 vs CPU 核数（调度器污染）",
            "检查容器 CPU 节流（第 4.8 节）",
            "检查是否有阻塞调用在 Dispatchers.Default 上",
        ],
    },
    "app_self": {
        "label": "应用自身（序列化、业务逻辑）",
        "level": 5,
        "level_name": "⑤ 微观常数",
        "actions": [
            "采 CPU 火焰图找热点（第 6.3 节）",
            "检查是否重复序列化（JSON → Map → JSON）",
            "检查热路径日志",
            "检查装箱/对象拷贝（收益通常是个位数 %）",
        ],
    },
    "postgres": {
        "label": "PostgreSQL",
        "level": 2,
        "level_name": "② 算法与数据访问",
        "actions": [
            "查 pg_stat_statements 的 calls（N+1）与 mean（慢查询）",
            "EXPLAIN (ANALYZE, BUFFERS) 检查执行计划",
            "检查缺失的索引",
            "检查事务范围是否过大",
        ],
    },
    "redis": {
        "label": "Redis",
        "level": 2,
        "level_name": "② 算法与数据访问",
        "actions": [
            "检查大 key / 热 key",
            "检查是否有 O(N) 命令（KEYS/HGETALL 大集合）",
            "检查是否重复查询同一个 key",
        ],
    },
    "downstream": {
        "label": "下游 HTTP",
        "level": 3,
        "level_name": "③ 架构与并发",
        "actions": [
            "检查是否串行调用多个独立下游（可并行化）",
            "检查下游本身的健康度",
            "加隔板（为每个下游分配独立资源）",
            "加熔断（下游持续失败时快速失败）",
        ],
    },
}


def prioritize(segments):
    """segments: [(key, 占比%)]，按占比排序并给出层级建议"""
    print("═" * 78)
    print("优化优先级：从延迟分解推导")
    print("═" * 78)
    print()

    # 按占比排序
    ranked = sorted(segments, key=lambda x: -x[1])

    print(f"{'段':<30}{'占比':>8}{'金字塔层级':<20}{'优先级'}")
    print("-" * 78)
    for i, (key, pct) in enumerate(ranked, 1):
        info = SEGMENT_TO_LEVEL.get(key)
        if not info:
            print(f"{key:<30}{pct:>7.1f}%  {'（未知）':<20}")
            continue
        print(f"{info['label']:<30}{pct:>7.1f}%  {info['level_name']:<20}第 {i}")

    print()
    print("═" * 78)
    print("详细建议（按优先级）")
    print("═" * 78)

    for i, (key, pct) in enumerate(ranked, 1):
        info = SEGMENT_TO_LEVEL.get(key)
        if not info:
            continue
        print()
        print(f"【优先级 {i}】{info['label']} —— {pct:.1f}%")
        print(f"  层级：{info['level_name']}")
        print(f"  优化收益上限：{pct:.1f}%（即使降为 0）")
        print(f"  建议动作：")
        for a in info["actions"]:
            print(f"    - {a}")

    print()
    print("═" * 78)
    print("三个提醒：")
    print("  ① 从占比最大的一段开始 —— 它的收益上限最高")
    print("  ② 不要跳过「① 先问要不要做」—— 有时最好的优化是少做一件事")
    print("  ③ 低级优化可能是高级优化的前提（例如先简化结构再加缓存），")
    print("     但这是「为了达成更大的目标」，不是为了顺手做")
    print("═" * 78)


if __name__ == "__main__":
    # 示例：从第 6.2 节的分解结果
    example_segments = [
        ("client_queue", 5.0),
        ("service_queue", 72.0),
        ("app_self", 3.25),
        ("postgres", 16.25),
        ("redis", 1.0),
        ("downstream", 2.0),
    ]
    prioritize(example_segments)

二、候选优化的排序器

# tools/rank-optimizations.py <optimizations.json>
"""
对候选优化排序：按「收益/成本比 + 金字塔层级」综合排序。

输入格式：
[
  {
    "name": "消除 N+1（批量查询）",
    "level": 2,
    "expected_benefit_pct": 70,
    "cost": "低",
    "risk": "低",
    "effort_days": 0.5
  },
  ...
]
"""
import json
import sys

LEVEL_WEIGHT = {1: 5.0, 2: 4.0, 3: 3.5, 4: 2.0, 5: 1.0, 6: 0.5}
COST_SCORE = {"低": 3.0, "中": 1.5, "高": 0.5}
RISK_SCORE = {"低": 3.0, "中": 1.5, "高": 0.5}


def score(opt):
    """
    综合得分 = 预期收益 × 层级权重 × 成本分 × 风险分 / 投入天数^0.5

    设计意图：
      - 层级越高（数字越小）权重越大
      - 成本/风险越高，得分越低
      - 投入天数开根号（避免低估快速见效的优化）
    """
    benefit = opt["expected_benefit_pct"]
    lv = LEVEL_WEIGHT.get(opt["level"], 1.0)
    cost = COST_SCORE.get(opt["cost"], 1.0)
    risk = RISK_SCORE.get(opt["risk"], 1.0)
    days = max(opt.get("effort_days", 1.0), 0.1)
    return benefit * lv * cost * risk / (days ** 0.5)


def main(path):
    opts = json.loads(open(path).read())
    ranked = sorted(opts, key=score, reverse=True)

    print("═" * 92)
    print("候选优化排序（综合：收益 × 层级 × 成本 × 风险 / 投入）")
    print("═" * 92)
    print()
    print(f"{'#':<4}{'优化':<34}{'层级':>5}{'收益%':>8}{'成本':>6}{'风险':>6}{'天数':>7}{'得分':>9}")
    print("-" * 92)
    for i, o in enumerate(ranked, 1):
        print(f"{i:<4}{o['name'][:32]:<34}{o['level']:>5}{o['expected_benefit_pct']:>8.0f}"
              f"{o['cost']:>6}{o['risk']:>6}{o.get('effort_days', 1):>7.1f}{score(o):>9.1f}")

    print()
    print("═" * 92)
    print("建议的执行顺序（前 3 项）：")
    for i, o in enumerate(ranked[:3], 1):
        print(f"  {i}. {o['name']}")
        print(f"     层级 {o['level']}，预期收益 {o['expected_benefit_pct']}%，"
              f"成本 {o['cost']}，风险 {o['risk']}，约 {o.get('effort_days', 1)} 天")
    print()
    print("注意：")
    print("  ⚠️  最后 2 项（通常是 JVM 调优与微观常数）建议【暂缓】——")
    print("      除非前面的优化已经做完且仍不达标")
    print("═" * 92)


if __name__ == "__main__":
    if len(sys.argv) < 2:
        # 用示例数据演示
        import tempfile, os
        demo = [
            {"name": "消除 N+1（批量查询）", "level": 2, "expected_benefit_pct": 70,
             "cost": "低", "risk": "低", "effort_days": 0.5},
            {"name": "把正则提到顶层", "level": 2, "expected_benefit_pct": 40,
             "cost": "低", "risk": "低", "effort_days": 0.2},
            {"name": "阻塞调用切到 Dispatchers.IO", "level": 3, "expected_benefit_pct": 60,
             "cost": "低", "risk": "中", "effort_days": 0.5},
            {"name": "加 Redis 缓存", "level": 4, "expected_benefit_pct": 50,
             "cost": "中", "risk": "高", "effort_days": 3.0},
            {"name": "换 ZGC", "level": 6, "expected_benefit_pct": 5,
             "cost": "高", "risk": "高", "effort_days": 5.0},
            {"name": "减少装箱", "level": 5, "expected_benefit_pct": 3,
             "cost": "中", "risk": "低", "effort_days": 2.0},
        ]
        with tempfile.NamedTemporaryFile("w", suffix=".json", delete=False) as f:
            json.dump(demo, f, ensure_ascii=False)
            path = f.name
        main(path)
        os.unlink(path)
    else:
        main(sys.argv[1])

预期输出（示例数据）：

配套代码：分析工作流与假设台账

Mon, 01 Jan 0001 00:00:00 +0000

6.1 配套代码：分析工作流与假设台账

对应小节：6.1 分析流程五步法两个工具：① 现象量化表模板；② 假设台账管理（让每个假设都有验证状态）。

一、现象量化表模板

<!-- docs/experiments/E07-incident-xxx/README.md 的「现象量化」章节 -->

## 现象量化

### 基本信息
| 维度 | 观测值 |
| --- | --- |
| 发现时间 | YYYY-MM-DD HH:MM |
| 报告人 | |
| 影响 | 用户投诉 / 监控告警 / 例行检查发现 |

### 谁慢
| 维度 | 观测值 |
| --- | --- |
| 接口 | |
| 实例范围 | 全部 / 部分（哪几台） |
| 请求范围 | 全部 / 特定参数 / 特定用户 |
| 依赖范围 | 是否与某个下游相关 |

### 多慢
| 指标 | 基线 | 当前 | 变化 |
| --- | --- | --- | --- |
| P50 | | | |
| P95 | | | |
| P99 | | | |
| 错误率 | | | |
| 超时率 | | | |
| QPS | | | |

### 从何时开始
| 问题 | 答案 |
| --- | --- |
| 突变还是渐变？ | |
| 与某次发布吻合？ | （版本号 + 时间） |
| 与数据量增长吻合？ | |
| 与外部事件吻合？ | （大促、其他服务上线） |

### 资源与饱和度（用于排除）
| 指标 | 基线 | 当前 | 是否异常 |
| --- | --- | --- | --- |
| CPU（user） | | | |
| CPU（sys） | | | |
| 内存 / 堆 | | | |
| GC 停顿 P99 | | | |
| 线程数 | | | |
| 连接池 pending | | | |
| 队列深度 | | | |
| 容器节流比例 | | | |

### 初步推论（由上面的数据排除/指向什么）
- QPS 未变 + CPU 未变 → 排除「过载」
- 只在特定参数上慢 → 指向数据访问路径
- 与发布吻合 → 高度怀疑该变更

为什么这张表这么重要：它把「接口慢了」这个模糊现象变成了一组可以排除假设的事实。填完它，假设空间通常能缩小到 2–3 个。

配套代码：台阶式提升与 PrintCompilation 解读

Mon, 01 Jan 0001 00:00:00 +0000

2.1 配套代码：台阶式提升与 PrintCompilation 解读

对应小节：2.1 四种执行形态要验证的结论：同一份代码在不同调用次数下的性能是台阶式变化的，不是渐变的。

一、实验：在不同调用次数下测量同一个方法

// src/main/kotlin/lesson02/ExecutionTiers.kt
package lesson02

import kotlin.random.Random

private var sink = 0L                     // 防止死代码消除

fun work(data: IntArray): Long {
    var s = 0L
    for (v in data) s += v
    return s
}

/**
 * 用「累计调用次数」作为横轴，观察性能台阶。
 * 每一档：先跑 total 次让 JIT 有机会编译，再测 measure 次的平均耗时。
 */
fun measureAt(totalInvocations: Int, measure: Int, data: IntArray): Double {
    repeat(totalInvocations) { sink += work(data) }        // 累积热度
    val t0 = System.nanoTime()
    repeat(measure) { sink += work(data) }
    val t1 = System.nanoTime()
    return (t1 - t0).toDouble() / measure
}

fun main() {
    val rnd = Random(42)
    val data = IntArray(4096) { rnd.nextInt() }

    println("累计调用次数        单次耗时(ns/op)")
    println("-".repeat(40))
    // 每一档都从一个"新进程的视角"重新累积是不现实的，
    // 所以这里用【单调递增】的累积次数：观察曲线是否台阶式下降
    for (total in listOf(10, 100, 500, 1_000, 5_000, 20_000, 100_000, 500_000)) {
        val ns = measureAt(total, 2_000, data)
        println("%,10d        %8.1f".format(total, ns))
    }
    println()
    println("sink = $sink   （确保计算没被优化掉）")
    println()
    println("预期形态：")
    println("  10 ~ 500      : 上千 ns（解释执行 / C1）")
    println("  1e3 ~ 2e4     : 快速下降（C2 介入）")
    println("  1e5 以后      : 平台（稳态）")
    println()
    println("注意：平台【不是突然到达】的，是渐近的 —— 这正是第 4 节要讲的稳态判定问题。")
}

二、预期输出形态

累计调用次数        单次耗时(ns/op)
----------------------------------------
        10            1312.4
       100             604.8
       500             391.2
     1,000             312.7
     5,000             261.4
    20,000             240.8
   100,000             231.2
   500,000             230.4

三、观察编译事件

java -XX:+PrintCompilation \
     -cp build/classes/kotlin/main lesson02.ExecutionTiersKt

输出形如：

配套代码：同一个函数，为什么测出三个不同的数字

Mon, 01 Jan 0001 00:00:00 +0000

0.1 配套代码：同一个函数，为什么测出三个不同的数字

对应小节：0.1 三类问题必须分开处理要验证的结论：「这段代码要 2 μs」是一个不完整的陈述——真实性能取决于它在什么环境下运行。

一、这段代码想说明什么

正文里有一句话：

「我测过 JSON 序列化只用 2 μs，一个请求 10 ms，所以序列化不是瓶颈。」——这句话的结论是错的，因为在真实并发下，同一个操作可能被放大几十倍。

这段代码就是把这句话变成可观察的数字：同一个函数，在三种环境下运行——

场景	环境	预期现象
A	单线程，无竞争	最快的数字（这就是「微基准」会给你的）
B	8 个线程同时调用，有共享锁	单次耗时大幅上升
C	单线程，但有持续的对象分配	耗时上升，且 GC 开始介入

二、代码

// src/main/kotlin/lesson00/ThreeKindsOfProblems.kt
package lesson00

import java.util.concurrent.CountDownLatch
import kotlin.concurrent.thread
import kotlin.system.measureNanoTime

/** 共享的「热点数据」，用于制造锁竞争 */
private val lock = Any()
private var sharedCounter = 0L

/**
 * 被测函数：模拟一次「有点计算量 + 需要访问共享资源」的操作。
 * 注意它是完全相同的代码，三种场景下不做任何修改。
 */
fun handleRequest(seed: Int): Long {
    // ① 一点本地计算（模拟业务逻辑）
    var local = seed.toLong()
    repeat(200) { local = local * 31 + it }

    // ② 访问共享资源（模拟写指标、更新缓存、计数器）
    synchronized(lock) {
        sharedCounter += local and 0xFF
        local += sharedCounter and 0x0F
    }

    // ③ 一点分配（模拟对象创建、序列化缓冲）
    val payload = ByteArray(256)
    payload[0] = local.toByte()
    return local + payload.size
}

/** 场景 A：单线程、无竞争 —— 这就是典型微基准会报告的"性能" */
fun scenarioA(iterations: Int): Long {
    waitForJit(iterations)
    return measureNanoTime {
        var sink = 0L
        repeat(iterations) { sink += handleRequest(it) }
        check(sink != Long.MIN_VALUE)
    } / iterations
}

/** 场景 B：8 线程争用同一把锁 */
fun scenarioB(iterations: Int, threads: Int = 8): Long {
    waitForJit(iterations)
    val perThread = iterations / threads
    val start = CountDownLatch(1)
    val done = CountDownLatch(threads)
    var totalElapsed = 0L

    repeat(threads) {
        thread {
            start.await()
            val elapsed = measureNanoTime {
                var sink = 0L
                repeat(perThread) { sink += handleRequest(it) }
                check(sink != Long.MIN_VALUE)
            }
            synchronized(lock) { totalElapsed = maxOf(totalElapsed, elapsed) }
            done.countDown()
        }
    }
    start.countDown()
    done.await()
    // 每个线程各自跑了 perThread 次，用时约等于最慢那个线程的耗时
    return totalElapsed / perThread
}

/** 场景 C：单线程，但持续分配大对象，制造 GC 压力 */
fun scenarioC(iterations: Int): Long {
    waitForJit(iterations)
    val garbage = ArrayList<ByteArray>(4096)
    return measureNanoTime {
        var sink = 0L
        repeat(iterations) { i ->
            sink += handleRequest(i)
            garbage.add(ByteArray(4096))          // 每秒产生大量垃圾
            if (garbage.size > 4096) garbage.clear()
        }
        check(sink != Long.MIN_VALUE)
    } / iterations
}

/** 预热：让 JIT 完成编译，否则测到的是解释执行阶段 */
private fun waitForJit(iterations: Int) {
    var sink = 0L
    repeat(iterations / 2) { sink += handleRequest(it) }
    check(sink != Long.MIN_VALUE)
}

fun main() {
    val n = 200_000
    println("同一个 handleRequest()，三种环境下运行：\n")
    println("A 单线程无竞争      : %6d ns/op".format(scenarioA(n)))
    println("B 8 线程争用同一把锁 : %6d ns/op".format(scenarioB(n)))
    println("C 单线程 + 分配压力  : %6d ns/op".format(scenarioC(n)))
    println("\n注意：三行是同一段代码。差别只来自运行环境。")
}

三、预期输出（形态）

同一个 handleRequest()，三种环境下运行：

A 单线程无竞争      :     82 ns/op
B 8 线程争用同一把锁 :   1840 ns/op
C 单线程 + 分配压力  :    260 ns/op

注意：三行是同一段代码。差别只来自运行环境。

你的数字会不同，但趋势应该一致：B 明显比 A 慢一个数量级以上。

配套代码：四层指标的埋点骨架

Mon, 01 Jan 0001 00:00:00 +0000

1.1 配套代码：四层指标的埋点骨架

对应小节：1.1 指标分四层这份代码是可以直接抄进项目的骨架。

一、注册表与四层指标的对应关系

// src/main/kotlin/metrics/MetricsRegistry.kt
package metrics

import com.zaxxer.hikari.HikariDataSource
import io.micrometer.core.instrument.Gauge
import io.micrometer.core.instrument.MeterRegistry
import io.micrometer.core.instrument.binder.jvm.*
import io.micrometer.core.instrument.binder.system.ProcessorMetrics
import io.micrometer.core.instrument.binder.system.FileDescriptorMetrics
import io.micrometer.prometheusmetrics.PrometheusConfig
import io.micrometer.prometheusmetrics.PrometheusMeterRegistry
import java.util.concurrent.ThreadPoolExecutor
import java.util.concurrent.atomic.AtomicInteger

val registry: PrometheusMeterRegistry = PrometheusMeterRegistry(PrometheusConfig.DEFAULT)

fun registerFourLayers(ds: HikariDataSource, executor: ThreadPoolExecutor) {

    // ══════════════════════════════════════════════════════════
    // 第 3 层：资源层 —— 消耗了什么
    // 这些 binder 会自动注册一批指标，不用手写
    // ══════════════════════════════════════════════════════════
    JvmMemoryMetrics().bindTo(registry)      // jvm_memory_used_bytes / max_bytes
    JvmGcMetrics().bindTo(registry)          // jvm_gc_pause_seconds（含分位数直方图）
    JvmThreadMetrics().bindTo(registry)      // jvm_threads_live / states
    ClassLoaderMetrics().bindTo(registry)    // 类加载数量（冷启动相关）
    ProcessorMetrics().bindTo(registry)      // system_cpu_usage / process_cpu_usage
    FileDescriptorMetrics().bindTo(registry) // 文件描述符使用（连接泄漏的第一信号）

    // ══════════════════════════════════════════════════════════
    // 第 4 层：饱和度层 —— 离上限还有多远（最重要的一层）
    // ══════════════════════════════════════════════════════════

    // 数据库连接池：pending 是最关键的指标
    Gauge.builder("db.pool.pending") { ds.hikariPoolMXBean?.threadsAwaitingConnection ?: 0 }
        .description("正在等待连接的线程数（> 0 说明已经排队）")
        .register(registry)

    Gauge.builder("db.pool.active") { ds.hikariPoolMXBean?.activeConnections ?: 0 }
        .description("正在被使用的连接数")
        .register(registry)

    Gauge.builder("db.pool.idle") { ds.hikariPoolMXBean?.idleConnections ?: 0 }
        .register(registry)

    Gauge.builder("db.pool.total") { ds.hikariPoolMXBean?.totalConnections ?: 0 }
        .register(registry)

    // 线程池队列深度：持续非空说明处理不过来
    Gauge.builder("executor.queue.depth") { executor.queue.size.toDouble() }
        .description("线程池等待队列长度")
        .register(registry)

    Gauge.builder("executor.queue.remaining") { executor.queue.remainingCapacity().toDouble() }
        .description("队列剩余容量（接近 0 说明即将开始拒绝）")
        .register(registry)

    Gauge.builder("executor.active") { executor.activeCount.toDouble() }
        .register(registry)
}

为什么 pending 比 active 更重要：active 高只说明「连接都在忙」，这是正常的；pending > 0 说明「已经有请求在排队等连接」——这是已经出问题的信号。

配套代码：渐进退化模拟与门禁经济性

Mon, 01 Jan 0001 00:00:00 +0000

8.1 配套代码：渐进退化模拟与门禁经济性

对应小节：8.1 为什么需要门禁两件事：① 用数据展示「渐进退化」如何逃过人工评审；② 算清门禁的经济性。

一、渐进退化模拟

# tools/simulate_gradual_degradation.py
"""
模拟「渐进退化」：每次改动只退化 3%~15%，看多久回到起点。

同时模拟「有门禁」的情况：阈值 25%，超过就拦住。
"""
import random


def simulate(months=12, changes_per_month=4, without_gate=True, seed=42):
    """
    模拟 12 个月的性能变化。

    每次改动的退化是随机的（0%~15%），偶尔有优化（-30%~-5%）。
    返回 (时间线, 最终值, 被拦住的次数)
    """
    rnd = random.Random(seed)
    p99 = 95.0                     # 起点（第 7 章优化后的值）
    baseline = 95.0                # 基线（有门禁时的对比对象）
    timeline = [(0, p99)]
    blocked = 0

    for month in range(1, months + 1):
        for _ in range(changes_per_month):
            r = rnd.random()
            if r < 0.15:
                # 15% 概率是一次优化
                change = -rnd.uniform(0.05, 0.30)
            elif r < 0.35:
                # 20% 概率是"看起来合理但退化"的改动（新增功能）
                change = rnd.uniform(0.03, 0.15)
            elif r < 0.45:
                # 10% 概率是数据量增长的影响
                change = rnd.uniform(0.05, 0.20)
            else:
                # 55% 概率是无影响的改动
                change = rnd.uniform(-0.02, 0.02)

            new_p99 = p99 * (1 + change)

            # 有门禁时：如果相对基线退化超过阈值，拦住
            if not without_gate:
                if (new_p99 - baseline) / baseline > 0.25:
                    blocked += 1
                    continue       # 这次改动被拦住，性能不变

            p99 = new_p99

        timeline.append((month, p99))

    return timeline, p99, blocked


def main():
    print("═" * 78)
    print("渐进退化模拟：12 个月，每月 4 次改动")
    print("═" * 78)
    print()

    # 无门禁
    tl_no, final_no, _ = simulate(without_gate=True)
    # 有门禁
    tl_yes, final_yes, blocked = simulate(without_gate=False)

    print(f"{'月份':<6}{'无门禁 P99':>14}{'有门禁 P99':>14}{'差异':>12}")
    print("-" * 78)
    for (m1, v1), (m2, v2) in zip(tl_no, tl_yes):
        diff = (v2 - v1) / v1 * 100 if v1 else 0
        print(f"{m1:<6}{v1:>13.1f}ms{v2:>13.1f}ms{diff:>11.1f}%")

    print()
    print("═" * 78)
    print("结论：")
    print(f"  无门禁：95.0ms → {final_no:.1f}ms（{final_no/95.0:.2f} 倍）")
    print(f"  有门禁：95.0ms → {final_yes:.1f}ms（{final_yes/95.0:.2f} 倍）")
    print(f"  门禁拦住了 {blocked} 次退化改动")
    print()

    if final_no > 200:
        print(f"  ⚠️  无门禁的情况下，P99 已经超过 200ms（SLO 违约）")
    print()
    print("关键观察：")
    print("  ① 每次改动的退化都在 3%~20% —— 【都在噪声范围内】")
    print("  ② 12 个月累积起来，性能可能翻倍甚至更多")
    print("  ③ 人工评审发现不了单次 5% 的退化（第 5.7 节的 MDD）")
    print("  ④ 门禁的作用是【拦住累积】，不是拦住单次")
    print("═" * 78)


if __name__ == "__main__":
    main()

预期输出：

配套代码：短链服务骨架与六颗埋雷

Mon, 01 Jan 0001 00:00:00 +0000

9.1 配套代码：短链服务骨架与六颗埋雷

对应小节：9.1 项目设定与埋雷清单 这是唯一一节需要写较多业务代码的地方——之后的章节都是编排与模板。

一、目录结构

src/main/kotlin/shortlink/
├── Application.kt              # Ktor 启动 + 指标注册
├── model/
│   ├── Link.kt                 # 领域模型
│   └── Dto.kt                  # request/response
├── service/
│   ├── LinkService.kt          # 业务逻辑（含埋雷 ⑥）
│   └── CodeGenerator.kt        # 短码生成（含埋雷 ⑥）
├── repository/
│   ├── LinkRepository.kt       # 数据访问（含埋雷 ① ② ④）
│   └── LinkCache.kt            # 缓存（含埋雷 ③）
├── http/
│   └── Routes.kt               # 路由（含埋雷 ⑤）
└── metrics/
    └── Metrics.kt              # 四层指标

二、领域模型与 DTO

// model/Link.kt
package shortlink.model

import java.time.Instant

data class Link(
    val id: Long,
    val code: String,
    val url: String,
    val userId: Long,
    val createdAt: Instant,
    val hits: Long,
)

// model/Dto.kt
package shortlink.model

import kotlinx.serialization.Serializable

@Serializable
data class CreateLinkRequest(val url: String, val userId: Long = 1)

@Serializable
data class CreateLinkResponse(val code: String)

三、埋雷 ⑥：`synchronized` 生成短码

// service/CodeGenerator.kt
package shortlink.service

import java.security.SecureRandom

private const val BASE62 = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
private const val CODE_LENGTH = 6

class CodeGenerator {
    private val random = SecureRandom()

    /**
     * ═══ 埋雷 ⑥ ═══
     *
     * 问题：
     *   ① 用了 synchronized（线程级锁）—— 在协程里可能是"跨越挂起点的锁"
     *   ② 每次调用都新建 SecureRandom（其实可以用一个共享实例）
     *   ③ 冲突后的重试逻辑在 Service 层（见 LinkService）
     *
     * 症状：写路径偶发卡顿；线程 dump 可能出现 BLOCKED
     * 修法：改用 Mutex（协程感知），或去掉锁用 CAS 重试
     */
    @Synchronized
    fun generate(): String {
        val sb = StringBuilder(CODE_LENGTH)
        repeat(CODE_LENGTH) {
            sb.append(BASE62[random.nextInt(BASE62.length)])
        }
        return sb.toString()
    }
}

四、埋雷 ① ② ④：Repository 的三个问题

// repository/LinkRepository.kt
package shortlink.repository

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import shortlink.model.Link
import java.sql.Connection
import java.sql.ResultSet
import java.time.Instant
import javax.sql.DataSource

class LinkRepository(private val ds: DataSource) {

    /**
     * ═══ 埋雷 ① ═══
     * 建表时 code 列【没有唯一索引】→ 这条查询走全表扫描
     *
     * 症状：随数据量线性变慢（100 万行时约 380ms）
     * 验证：EXPLAIN (ANALYZE, BUFFERS) 会看到 Seq Scan
     * 修法：CREATE UNIQUE INDEX ON links(code)
     *
     * ═══ 埋雷 ④ ═══
     * 这里【没有】withContext(Dispatchers.IO)
     * → JDBC 是阻塞调用，直接跑在调用者的调度器上
     * → 如果调用者是 Dispatchers.Default（并行度=核数），会被占满
     *
     * 症状：CPU 低但所有接口一起慢
     * 验证：wall 火焰图 + RUNNABLE 线程数 == CPU 核数
     * 修法：withContext(Dispatchers.IO) + Semaphore 限流
     */
    suspend fun findByCode(code: String): Link? {
        return ds.connection.use { c ->              // ❌ 阻塞调用，未切调度器
            c.prepareStatement(
                "SELECT id, code, url, user_id, created_at, hits FROM links WHERE code = ?"
            ).use { ps ->
                ps.setString(1, code)
                ps.executeQuery().use { rs -> if (rs.next()) rs.toLink() else null }
            }
        }
    }

    suspend fun findById(id: Long): Link? {
        return ds.connection.use { c ->
            c.prepareStatement(
                "SELECT id, code, url, user_id, created_at, hits FROM links WHERE id = ?"
            ).use { ps ->
                ps.setLong(1, id)
                ps.executeQuery().use { rs -> if (rs.next()) rs.toLink() else null }
            }
        }
    }

    /**
     * ═══ 埋雷 ② ═══
     * 每次跳转都 UPDATE hits —— 写放大 + 行锁竞争
     *
     * 症状：高并发下热门短链的 UPDATE 争抢同一行锁；
     *       lock 火焰图有内容；pg_stat_activity 有 wait_event_type=Lock
     * 修法：批量/异步累加（但收益 < MDD，本 Lab 会否决它）
     */
    suspend fun incrementHits(id: Long) {
        ds.connection.use { c ->
            c.prepareStatement("UPDATE links SET hits = hits + 1 WHERE id = ?").use { ps ->
                ps.setLong(1, id)
                ps.executeUpdate()
            }
        }
    }

    suspend fun insert(code: String, url: String, userId: Long): Link {
        return ds.connection.use { c ->
            c.prepareStatement(
                "INSERT INTO links (code, url, user_id) VALUES (?, ?, ?) RETURNING id, created_at, hits"
            ).use { ps ->
                ps.setString(1, code)
                ps.setString(2, url)
                ps.setLong(3, userId)
                ps.executeQuery().use { rs ->
                    rs.next()
                    Link(rs.getLong(1), code, url, userId, rs.getTimestamp(2).toInstant(), rs.getLong(3))
                }
            }
        }
    }

    private fun ResultSet.toLink() = Link(
        getLong("id"), getString("code"), getString("url"),
        getLong("user_id"), getTimestamp("created_at").toInstant(), getLong("hits"),
    )
}

五、埋雷 ③：缓存 TTL 无抖动

// repository/LinkCache.kt
package shortlink.repository

import com.github.benmanes.caffeine.cache.Cache
import com.github.benmanes.caffeine.cache.Caffeine
import shortlink.model.Link
import java.time.Duration

class LinkCache {

    /**
     * ═══ 埋雷 ③ ═══
     * 所有 key 用【同一个固定 TTL】→ 同一批写入的 key 会同时失效
     *
     * 症状：数据库 QPS 出现周期性脉冲（每 10 分钟一次）
     *       —— 只有浸泡测试（≥1 小时）才能观察到
     * 验证：把 DB QPS 的脉冲时刻与 TTL(10min) 对齐
     * 修法：TTL 加随机抖动（±20%）
     */
    private val cache: Cache<String, Link> = Caffeine.newBuilder()
        .maximumSize(100_000)
        .expireAfterWrite(Duration.ofMinutes(10))       // ❌ 无抖动
        .recordStats()
        .build()

    fun get(code: String): Link? = cache.getIfPresent(code)

    fun put(code: String, link: Link) {
        cache.put(code, link)
    }

    fun invalidate(code: String) {
        cache.invalidate(code)
    }

    fun hitRate(): Double = cache.stats().hitRate()
    fun stats() = cache.stats()
}

六、Service 层：编排 + 短码冲突重试

// service/LinkService.kt
package shortlink.service

import shortlink.model.Link
import shortlink.repository.LinkCache
import shortlink.repository.LinkRepository
import org.slf4j.LoggerFactory

class LinkService(
    private val repo: LinkRepository,
    private val cache: LinkCache,
    private val codeGenerator: CodeGenerator,
) {
    private val log = LoggerFactory.getLogger(LinkService::class.java)

    /**
     * 读取路径：缓存优先，未命中查库并回填
     *
     * 注意：这里没有 withContext(Dispatchers.IO) —— 由 Repository 负责（而它也没有，
     *      所以整个链路跑在调用者的调度器上 → 埋雷 ④ 生效）
     */
    suspend fun resolve(code: String): Link? {
        // ① 先查缓存
        cache.get(code)?.let { return it }

        // ② 未命中 → 查库
        val link = repo.findByCode(code) ?: return null

        // ③ 回填缓存
        cache.put(code, link)

        // ④ 累加计数（埋雷 ②）
        repo.incrementHits(link.id)

        return link
    }

    /** 写入路径：生成短码 + 冲突重试 */
    suspend fun create(url: String, userId: Long): String {
        repeat(5) { attempt ->
            val code = codeGenerator.generate()        // 埋雷 ⑥：synchronized
            try {
                repo.insert(code, url, userId)
                return code
            } catch (e: Exception) {
                // 唯一索引冲突（code 已存在）—— 这是【正常业务】，不是故障
                if (isUniqueViolation(e)) {
                    log.debug("code collision on attempt {}: {}", attempt, code)
                    // 继续重试
                } else {
                    throw e
                }
            }
        }
        throw IllegalStateException("failed to generate unique code after 5 attempts")
    }

    private fun isUniqueViolation(e: Exception): Boolean =
        e.message?.contains("duplicate key") == true ||
        e.message?.contains("unique constraint") == true
}

注意 isUniqueViolation 这一段的含义：

零拷贝核心武器 1：`mmap` 内存映射与 DMA

Mon, 01 Jan 0001 00:00:00 +0000

mmap 是零拷贝技术的第一把核心武器。它解决的是传统 IO 中最痛苦的一步：内核缓冲区 → 用户缓冲区的 CPU 拷贝。

它的核心思想极其简单，但硬件实现极其精妙：让用户态程序直接看到内核的 Page Cache，而不是把数据拷贝一份给用户。

1. 传统 read() 的内存布局 vs mmap 的内存布局

传统 `read()`：数据被拷贝了一次

+-------------------+          +-------------------+
|   用户态地址空间   |          |   内核态地址空间   |
|                   |          |                   |
|  +-------------+  |          |  +-------------+  |
|  | 用户缓冲区   |  |          |  | Page Cache  |  |
|  | (buf)       |  |          |  | (磁盘数据)   |  |
|  +------^------+  |          |  +------^------+  |
|         |         |          |         |         |
|         +---- CPU 拷贝 (memcpy) ----+         |
|                   |          |                   |
|                   |          |  +------+------+  |
|                   |          |  | 磁盘/文件    |  |
|                   |          |  +-------------+  |
+-------------------+          +-------------------+

数据路径：磁盘 → (DMA) → Page Cache → (CPU 拷贝) → 用户缓冲区

音频主时钟同步

Mon, 01 Jan 0001 00:00:00 +0000

一、为什么用音频做主时钟

音频时钟：声卡以固定采样率播放，每一帧时长精确可计算
  一帧 1024 个样本，48000Hz → 每帧时长 = 1024/48000 = 21.33ms
  声卡中断或 DMA 传输时精确触发

视频时钟：显示器刷新率不稳定（VSync/Gsync/丢帧）
  一帧 60fps → 16.67ms
  实际可能因为解码延迟、渲染延迟而漂移

所以：
  播放器初始化时记录音频开始播放的时钟
  每一帧音频计算出当前的"期望位置"
  视频根据音频位置决定"是丢帧还是重复帧"

二、实现逻辑

// 最简单的音视频同步逻辑（伪代码）

struct SyncClock {
    // 音频时钟（主时钟）
    int64_t audio_start_time;          // 开始播放时的系统时间（毫秒）
    size_t total_samples_played;       // 已播放的总采样数
    int sample_rate;                   // 采样率

    // 获取当前音频播放位置（毫秒）
    double audio_clock() {
        double seconds = (double)total_samples_played / sample_rate;
        return seconds * 1000.0;
    }

    // 判断视频帧是否同步
    SyncAction check_video_sync(double video_pts_ms) {
        double audio_pts_ms = audio_clock();
        double diff = video_pts_ms - audio_pts_ms;

        // 偏差阈值
        if (diff < -100.0) {
            // 视频比音频快了 100ms 以上 → 需要等待（重复上一帧）
            return SyncAction::DELAY;
        } else if (diff > 100.0) {
            // 视频比音频慢了 100ms 以上 → 需要丢帧
            return SyncAction::DROP;
        } else {
            // 在同步范围内，正常显示
            return SyncAction::SHOW;
        }
    }
};

enum class SyncAction { SHOW, DELAY, DROP };

三、同步策略对比

视频快了（视频 PTS < 音频时钟）：
    策略一：把等待时间计入，推迟显示当前帧
    策略二：重复显示上一帧（画面静止，但感觉不到）
    后果：画面延迟增大，但不会卡顿

视频慢了（视频 PTS > 音频时钟）：
    策略一：直接丢弃当前帧（跳帧）
    策略二：跳过解码，直接拿下一帧
    后果：画面有轻微跳帧，但声音保持连续

经验法则：
    快 20ms 以内 → 忽略（人眼感觉不到）
    快 20-100ms → 延迟显示
    快 100ms+ → 丢帧

    播放器选择"丢帧保留音频同步"：
    声音卡顿是最容易被注意到的，画面稍微跳一下在可接受范围。

项目设定与埋雷清单

Mon, 01 Jan 0001 00:00:00 +0000

9.1 项目设定与埋雷清单

上一节：无　|　下一节：9.2 步骤一：定义目标配套代码：09-capstone/01-project-setup

一句话结论

为了让这个实战有东西可查，你必须故意保留几个已知问题。 一个"什么都对"的服务，练不出定位能力——六颗埋雷是本章最重要的准备。

一、服务设计：短链服务

两个接口

POST /links              创建短链
  body: { "url": "https://example.com/very/long/url" }
  → { "code": "aB3xK9" }

GET /{code}              跳转
  → 302 Location: https://example.com/very/long/url

为什么这两个接口够用：

特征	对应知识点
读多写少（读:写 ≈ 50:1）	缓存策略（第 7.4 节）
热门短链被反复访问	幂律分布（第 5.5 节）
读路径有缓存命中/未命中	缓存对 P99 的影响（第 7.4 节）
写路径有唯一索引冲突	数据库错误处理（第 6.6 节）
代码短（6 位 base62）	可以自然地做"加索引/不加索引"的对比

数据表

CREATE TABLE links (
    id          BIGSERIAL PRIMARY KEY,
    code        TEXT NOT NULL,              -- 短码
    url         TEXT NOT NULL,              -- 原始 URL
    user_id     BIGINT NOT NULL,            -- 创建者（用于热点分析）
    created_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
    hits        BIGINT NOT NULL DEFAULT 0   -- 访问计数（用于写路径演示）
);

-- ⚠️ 注意：故意先不建 code 的唯一索引（见埋雷清单）

二、六颗埋雷（本章的核心准备）

这六个问题对应第 6 章的六个瓶颈模式。请在实现时刻意保留它们，不要提前修。

高性能索引树原理

Mon, 01 Jan 0001 00:00:00 +0000

一、红黑树（`std::map`）—— 为什么遍历时缓存不友好？

红黑树的内存布局：

每个节点独立 new 分配，分散在堆上：

堆地址 0x1000: [key=5 | left→0x2000 | right→0x3000 | parent→null | color=BLACK]
堆地址 0x2000: [key=3 | left→null  | right→null  | parent→0x1000 | color=RED  ]
堆地址 0x3000: [key=7 | left→null  | right→null  | parent→0x1000 | color=RED  ]

中序遍历（按 key 顺序）：

访问 3 → 跳到 0x2000    ← Cache Miss（和 5 不在同一缓存行）
访问 5 → 跳到 0x1000    ← Cache Miss 或 Hit（可能被访问过）
访问 7 → 跳到 0x3000    ← Cache Miss

每个节点跳转都是指针追访。和 std::list 的遍历一样，缓存命中率接近 0%。

`constexpr` 与 C++20 Concepts

Mon, 01 Jan 0001 00:00:00 +0000

一、`constexpr` —— 让代码在编译期运行

// 编译期阶乘
constexpr int factorial(int n) {
    if (n <= 1) return 1;
    return n * factorial(n - 1);
}

int arr[factorial(5)]; // ✅ 编译期求值，arr 大小 120

int x = 5;
int y = factorial(x); // ❌ 运行时调用（x不是编译期常量）
constexpr int z = factorial(5); // ✅ 编译期调用

consteval（C++20）：强制编译期执行，不允许运行时调用。

consteval int double_it(int n) {
    return n * 2;
}

constexpr int x = double_it(21);  // ✅ 42
int y = double_it(21);            // ✅ 编译器推导为 constexpr
int z = double_it(x);             // ✅ 可以
int runtime_val = std::rand();
int w = double_it(runtime_val);   // ❌ 编译错误：consteval 不允许运行时调用

二、C++20 Concepts —— 摆脱 SFINAE 噩梦

// 定义 Concept
template <typename T>
concept Hashable = requires(T a) {
    { std::hash<T>{}(a) } -> std::convertible_to<size_t>;
};

// 使用 Concept 约束模板
template <Hashable T>
void process_hash(const T& value) {
    auto h = std::hash<T>{}(value);
}

// 或者更简约的写法
void process_hash(const Hashable auto& value) {
    auto h = std::hash<T>{}(value);
}

// 错误信息对比
process_hash(42);   // ✅ int 有 hash 特化
process_hash("hello"); // ✅ const char* 有 hash 特化

struct MyType {};
process_hash(MyType{}); // ❌ 编译错误："MyType 不满足 Hashable 约束"
                        //    而不是几万行的模板实例化失败堆栈！

Concepts 的 3 大价值：

`perf top` —— 实时热点监控

Mon, 01 Jan 0001 00:00:00 +0000

一、线上排查用

# 查看整个系统实时热点
perf top

# 只看某个进程
perf top -p <pid>

# 只看某个 CPU 核心
perf top -C 0

# 只看内核态
perf top -k 1

适用场景：

程序运行中突然 CPU 飙高到 100%，但不能停掉程序。
用 perf top -p <pid> 直接看到当前哪个函数在吃 CPU。

输出示例：
  PerfTop:    5000 irqs/sec  kernel:10.0%  exact:  100.0%
   40.2%  libc-2.31.so      [.] malloc            ← 内存分配是热点
   25.1%  my_program         [.] serialize_packet  ← 序列化函数
   12.3%  [kernel]           [.] tcp_sendmsg       ← 内核 TCP 发送

  → 马上知道：程序在频繁 malloc，需要优化内存分配策略。

`std::any` —— 能存任意类型的容器

Mon, 01 Jan 0001 00:00:00 +0000

和 `void*` 有什么区别？

// void*：完全不安全
void* storage = new int(42);
// 一年后别的开发者：
int* p = static_cast<int*>(storage); // 假设有人告诉他是 int
// 但如果存储的是 double 呢？💥

// std::any：安全
std::any storage = 42;
storage = 3.14;
storage = std::string("hello");

// 取出时必须指定类型，错了就抛异常
try {
    int val = std::any_cast<int>(storage); // ❌ 当前是 string
} catch (const std::bad_any_cast&) {
    std::cout << "wrong type";
}

什么时候真的需要 `any`？

很少。variant 比 any 更好（variant 在编译期知道可能的类型集，any 不知道）。

少数的场景：插件系统/动态配置系统，你需要存储"类型完全未知、运行时才能确定"的数据：

// 配置系统：每个配置项的类型只能在加载时确定
std::unordered_map<std::string, std::any> runtime_config;

runtime_config["timeout"] = 30;      // int
runtime_config["rate"] = 3.14;       // double
runtime_config["name"] = "server"s;  // string

// 运行时才知道类型
std::string key = get_user_input();  // 用户输入 "rate"
if (runtime_config[key].has_value()) {
    // 但这里不知道是 int 还是 double，只能 try 所有类型
}

能用 variant 的场景就别用 any，因为 any 底层用虚表做类型擦除，每次 any_cast 都有一次 RTTI 比较。

`std::unordered_map` 哈希表与 `std::map` 红黑树

Mon, 01 Jan 0001 00:00:00 +0000

一、`std::map` 红黑树的物理布局

std::map<int, string> m;
m[5] = "five";
m[3] = "three";
m[7] = "seven";

内存中的红黑树结构:
堆地址 0x1000: 节点 3 [left=null|right=0x2000|parent=0x3000|color=RED  |"three"]
堆地址 0x2000: 节点 7 [left=null|right=null |parent=0x3000|color=BLACK|"seven"]
堆地址 0x3000: 节点 5 [left=0x1000|right=0x2000|parent=null|color=BLACK|"five" ]
        ↑
        | (根节点，平衡二叉树)

遍历时的缓存表现：每次通过指针跳到下一节点，和 list 一样——缓存命中率极低。

面试高频题：“为什么 map 的插入是 $O(\log N)$ 但实际可能比 unordered_map 的 $O(1)$ 更快？”

当 N 很小（< 1000）时，红黑树的 $\log N$ 大约 10 次比较，而哈希表需要计算哈希值（几十条指令）+ 取模 + 可能的冲突解决。
哈希表在元素少时，负载因子低，桶空间浪费大，缓存命中率比红黑树还差。

二、`std::unordered_map` 开链哈希表

unordered_map<int, string> um;
um.max_load_factor(1.0);

桶数组 (Bucket Array, 连续内存):
+───────+───────+───────+───────+───────+
| 桶 0  | 桶 1  | 桶 2  | 桶 3  | ...  |
+───┬───+───┬───+───┬───+───┬───+───┬───+
    │       │       │       │
    ▼       ▼       ▼       ▼
   节点     节点     nullptr 节点
   [5]     [13]             [7]
    │       │                │
    ▼       ▼                ▼
  nullptr  nullptr          nullptr
  每个桶指向一个单向/双向链表的头节点

Rehash 的代价：

`std::weak_ptr` —— 循环引用的解药

Mon, 01 Jan 0001 00:00:00 +0000

一、循环引用崩溃现场

struct Node {
    shared_ptr<Node> next;
};

auto a = make_shared<Node>();
auto b = make_shared<Node>();
a->next = b;
b->next = a;  // 💥 循环引用！

a.ptr → [Node A | next→b的control_block]    ref_count_A = 2 (a + b->next)
b.ptr → [Node B | next→a的control_block]    ref_count_B = 2 (b + a->next)

a.reset() → ref_count_A = 1 (还被 b->next 持有) → 不释放
b.reset() → ref_count_B = 1 (还被 a->next 持有) → 不释放
→ 两个节点永远不释放！

二、用 `weak_ptr` 破解

struct Node {
    weak_ptr<Node> next; // 不增加引用计数！
};

a->next = b;  // weak_ptr = b → weak_count++，ref_count 不变
b->next = a;  // 同上

a.reset() → ref_count_A = 0 → 释放 A → b->next 变成空悬
b.reset() → ref_count_B = 0 → 释放 B
✅ 完美释放！

三、`weak_ptr.lock()` 的底层安全检查

shared_ptr<Node> sp = weak_node.lock(); // 安全提升
if (sp) {
    // 此时对象一定活着，sp 持有引用计数
}

底层做了什么：

ARM 架构下的核心兵器：LL/SC (Link-Load / Store-Conditional)

Mon, 01 Jan 0001 00:00:00 +0000

这个问题切中了移动端和服务器端底层设计的根本分歧。很多从x86转到ARM的开发者，第一反应就是：“为什么ARM没有lock cmpxchg？"。

答案很哲学：x86是复杂（CISC）的"霸道总裁”，而ARM是精简（RISC）的"优雅绅士"。前者直接给你原子指令，后者给你两条指令让你自己组合，以此换取极致的灵活性。

1. 为什么手机芯片（ARM）不直接用 CAS？

直接原因：CAS（Compare-And-Swap）是一个"读-改-写"三合一的巨无霸指令。 在RISC哲学里，一条指令只做一件事。如果强行在ARM里塞入cmpxchg，会：

增加晶体管开销：需要复杂的微码控制器。
破坏多核扩展性：未来的ARM可能几百个核，硬件的CAS逻辑会变成瓶颈。
功耗太高：手机对功耗极其敏感，cmpxchg需要持续锁住总线等待结果，而ARM的LL/SC允许在失败时提前释放。

根本区别在于：

x86的CAS：你告诉CPU “你要么成功，要么失败”，CPU内部硬扛所有冲突。
ARM的LL/SC：CPU告诉你 “我给你做个标记，你试着改，如果我发现有人动过，我就让你重试”——把"判断冲突"的主动权交给软件。

2. 核心兵器拆解：LL（Load-Link）与 SC（Store-Conditional）

这是ARM体系（以及RISC-V、PowerPC）的原子操作基石。

指令原型（ARMv8 示例）

; 假设我们要实现原子自增: *ptr += 1

1.  LL  x0, [x1]      ; Load-Link: 将 x1 地址的值读入 x0，并打上"独占标记"
2.  ADD x0, x0, #1    ; 普通加法（此时还没写回）
3.  SC  x0, [x1]      ; Store-Conditional: 尝试把 x0 写入 x1
                       ; 如果成功，x0=0；如果失败（独占标记丢失），x0=1
4.  CBNZ x0, retry    ; 如果 x0 != 0，跳回重试

硬件执行流程（独占监视器机制）

[ 核心A ]                           [ 核心B ]                    [ 全局监视器 ]
    |                                    |                              |
    |--- 1. LL (读取地址P) -------------->| ---------------------------> | 记录: 核心A 正在监视 地址P
    |   (核心A: 拿到数据10)              |                              | (Exclusive Monitor 置位)
    |                                    |                              |
    |   (此时核心A做加法,但没写)          |--- 对同一地址P 执行写操作 --> | 检测到冲突!
    |                                    | (核心B: 写入11)             | 标记: 核心A 的监视失效
    |                                    |                              |
    |--- 3. SC (尝试写回11) ------------->| ---------------------------> | 检查: 核心A 的监视还在吗?
    |   (返回失败: x0=1)                 |                              | 回复: 不在 (已失效)
    |                                    |                              |
    |--- 4. 检测失败 -> 跳转重试        |                              |

3. 硬件独占监视器（Exclusive Monitor）的工作原理

这是LL/SC的灵魂。它不是锁，而是一个监听状态的触发器。分为两级：

C++ 线程模型怎么选？

Mon, 01 Jan 0001 00:00:00 +0000

模型	典型代表	适合场景
单线程 Reactor	Redis、Node.js	I/O 密集、处理快的业务
多线程 Reactor + ThreadPool	Nginx、Netty	通用网络服务
Proactor (io_uring)	SPDK、Seastar	极高性能、用户态驱动
每个连接一个线程	简单 demo	连接数少（<1000）

CI 微基准门禁

Mon, 01 Jan 0001 00:00:00 +0000

8.2 CI 微基准门禁

上一节：8.1 为什么需要门禁　|　下一节：8.3 全链路性能门禁配套代码：08-continuous-performance/02-ci-benchmark-gate

一句话结论

CI 门禁的三条设计纪律：相对比较（不设绝对阈值）、宽松阈值（高于噪声底线）、先报告后失败。 违反任何一条，门禁都会沦为「重跑一下就过」的噪声源。

一、用「体重秤的警报」理解阈值

你家的体重秤误差是 ±1 kg。你设了一个警报：「体重涨了 0.5 kg 就提醒我」。

结果：警报天天响（因为噪声就有 1 kg），三天后你就把它关掉了。

正确做法：

① 先测出秤的实际误差（±1 kg）
② 警报阈值设成 2 kg（误差的 2 倍）
③ 只有真的涨了 2 kg 才提醒

CI 门禁完全一样：阈值必须高于噪声，否则就会被忽略。

二、三条设计纪律

纪律一：相对比较，不设绝对阈值

# ❌ 绝对阈值：换 runner 型号就全线失败
- name: Check performance
  run: |
    SCORE=$(read_score)
    if [ "$SCORE" -lt 16000 ]; then exit 1; fi   # 硬编码数字

# ✅ 相对比较：与仓库中的基线比
- name: Compare against baseline
  run: python3 tools/compare_benchmark.py current.json perf/baseline.json --threshold 0.15

为什么：CI runner 的型号、负载、邻居会变化，绝对阈值意味着每次换环境都要重调，而且调的过程中会放松阈值（最终变成形式主义）。

clangd —— IDE 集成的实时分析

Mon, 01 Jan 0001 00:00:00 +0000

一、clangd 是什么

clangd 是 LLVM 的 LSP（Language Server Protocol） 实现，为编辑器提供代码补全、跳转定义、实时错误提示、重构建议。

# 安装
brew install llvm  # macOS，包含 clangd
apt install clangd  # Linux

# 生成编译数据库（clangd 需要知道编译选项）
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON .
# 生成 compile_commands.json 文件

二、和 CLion 的配合

CLion 默认自带 clangd 支持。
VSCode 需要安装 clangd 插件（禁用默认的 C++ IntelliSense）。

配置后得到的实时提示：
  - 输入时显示类型不匹配
  - 悬停查看函数签名
  - 自动显示 clang-tidy 警告（红线）
  - 代码补全（包含 STL 模板的展开结果）
  - 重构（重命名变量/函数、提取函数）

Copy-and-Swap 惯用法

Mon, 01 Jan 0001 00:00:00 +0000

一、异常安全的赋值运算符

class Buffer {
    int* data_;
    size_t size_;

public:
    // 拷贝构造
    Buffer(const Buffer& other) : size_(other.size_) {
        data_ = new int[size_];
        std::copy(other.data_, other.data_ + size_, data_);
    }

    // 析构
    ~Buffer() { delete[] data_; }

    // 赋值运算符——Copy-and-Swap 写法
    Buffer& operator=(Buffer other) {  // 传值：拷贝构造或移动构造
        swap(other);
        return *this;
    }

    // 交换
    void swap(Buffer& other) noexcept {
        std::swap(data_, other.data_);
        std::swap(size_, other.size_);
    }
};

为什么这种写法是异常安全的？

传统写法：

Buffer& operator=(const Buffer& other) {
    delete[] data_;              // 先释放旧资源
    data_ = new int[other.size_]; // 如果这里 new 抛异常 → data_ 悬垂！💥
    size_ = other.size_;
    std::copy(...);
    return *this;
}

Copy-and-Swap：先拷贝（可能抛异常，但原对象不受影响），如果拷贝成功，再交换指针。即使拷贝抛出异常，原对象不变。

FLV 格式

Mon, 01 Jan 0001 00:00:00 +0000

一、FLV 的结构

FLV Header（9 字节）：
  签名 "FLV"（3 字节）
  版本 1（1 字节）
  标志（1 字节）：bit0=视频存在, bit2=音频存在
  头部大小 = 9（4 字节）

FLV Tag 序列：
  [PreviousTagSize=0][Tag1][PreviousTagSize][Tag2]...

每个 Tag：
  ┌─────────────────────────────────────┐
  │ Tag 类型：8=音频, 9=视频, 18=脚本   │ 1 字节
  │ 数据大小                             │ 3 字节
  │ 时间戳（毫秒）                       │ 3 字节
  │ 时间戳扩展（毫秒高位）               │ 1 字节
  │ StreamID（总是 0）                   │ 3 字节
  │ Tag 数据                             │ 可变
  └─────────────────────────────────────┘

视频 Tag 的数据格式：
  [帧类型(4bit) | 编码器ID(4bit)][编码数据]
  帧类型：1=关键帧, 2=非关键帧
  编码器ID：7=H.264
  H.264 数据开头是 AVCDecoderConfigurationRecord（编码器配置，包含 sps/pps）

音频 Tag 的数据格式：
  [音频格式(4bit) | 采样率(2bit) | 位深(1bit) | 声道(1bit)][音频数据]
  音频格式：10=AAC
  AAC 数据开头是 AudioSpecificConfig

二、RTMP 为什么用 FLV？

RTMP 发送的流式数据本质上就是 FLV Tag 流。推流端把编码后的 H.264 帧打包成 FLV VideoTag，通过 RTMP Chunk 发送给服务器，服务器直转发给拉流端。flv.js 做的就是把收到的 FLV Tag 解包，喂给浏览器的 MediaSource API 播放。

JIT 的三大优化与去优化

Mon, 01 Jan 0001 00:00:00 +0000

2.2 JIT 的三大优化与去优化

上一节：2.1 四种执行形态　|　下一节：2.3 微基准四大陷阱配套代码：02-jvm-performance-basics/02-jit-optimizations-and-deopt

一句话结论

C2 编译器会基于「运行时观察到的现象」做推测性优化——比如「这个调用点永远只有一种类型」。一旦推测被打破，它会撤销优化、退回慢速路径。 这就是「去优化」，也是性能无端抖动的常见来源。

一、先看三大优化（用厨房类比）

接着上一节的餐厅比喻。老师傅（C2）在观察了足够多次之后，会做三件事：

优化一：方法内联（Inlining）—— 把常用步骤直接展开

原来：每次要做「去冰箱拿鸡蛋」这个动作，都要走过去、打开冰箱、拿蛋、关门。厨师会把它写成一个标准动作反复执行。

老师傅的做法：既然每次都这样，那我干脆把这个动作直接展开到主流程里，不用来回跑（省掉「方法调用的开销」），而且展开之后还能看到更大的优化空间（比如发现「拿蛋之后马上要打蛋」，可以合并）。

技术含义：把被调用方法的字节码直接嵌入调用方，消除调用开销，并为后续优化（常量传播、死代码消除）创造条件。

这也是为什么火焰图会「丢帧」：内联之后，中间那个方法在调用栈上就不存在了。

优化二：逃逸分析（Escape Analysis）—— 只在内部用的东西，不用真造一个

原来：厨房要盛一份配菜，得专门洗一个盘子、装盘、用完再洗。

老师傅发现：这个盘子只在厨房内部用，端出去之前就被吃掉了……那我为什么还要真的拿一个盘子？直接在案板上处理完就行。

同理，还有两个衍生优化：

锁消除：如果一把锁只在内部用、不会被别的厨师碰到，那就没必要真锁。
标量替换：如果一个对象只在内部用，可以把它拆成几个局部变量，连对象都不分配。

技术含义：如果 JIT 能证明一个对象不会「逃逸」出当前方法/线程，就可以把它分配在栈上（甚至拆成标量），从而减少堆分配与 GC 压力。

这解释了一个反直觉的现象：有些看起来「创建了很多对象」的代码，实测非常快——因为那些对象根本没被真正创建。

优化三：基于 profile 的推测优化 —— 按「最常发生的情况」设计流程

老师傅观察到：来这里的客人99% 都点同一道招牌菜。于是他干脆把这道菜的料都提前备好放在手边。

风险：如果有一天来了个点别的菜的客人，他准备的料全用不上，还得临时找——比原来更慢。

技术含义：C2 会记录调用点的类型分布。如果它发现「这个接口调用永远指向同一个实现类」，就会把虚调用（间接跳转）优化成直接调用（甚至内联掉）。这叫 monomorphic（单态） 调用点。

如果后来出现了第二种类型，就叫 bimorphic（双态）；出现多种类型就是 megamorphic（巨态），此时 JIT 会放弃优化，退回慢速的虚调用。

二、去优化：优化被撤销的瞬间

什么是去优化

当 C2 的推测被打破时，它必须撤销已经生成的机器码，退回到解释执行或较低优化的版本，然后带着新信息重新编译。

① C2 假设「这个调用点只有 A 类型」→ 生成直接调用 A 的机器码（很快）
② 某次请求带来了 B 类型
③ 假设被打破 → 当前机器码作废（made not entrant）
④ 退回解释执行 / 重新走 C1、C2 编译
⑤ 期间性能明显下降（可能出现毫秒级甚至更长的抖动）

触发去优化的常见原因：

Massif —— 堆内存分析

Mon, 01 Jan 0001 00:00:00 +0000

一、什么时候用

程序的 RSS（驻留内存）超出预期，想知道谁分配了这么多内存。

# 运行 Massif
valgrind --tool=massif ./my_program

# 输出文件：massif.out.12345

# 用 ms_print 生成报告
ms_print massif.out.12345

# 输出：
# ---------------------------------------------------------------------------
# Command:    ./my_program
# Massif output
# ---------------------------------------------------------------------------
#     MB
#  3.25 ┤                  ╭╮
#  2.99 ┤                  ││ ╭──╮
#  2.74 ┤                  ││ │  │
#  2.48 ┤      ╭──╮       │╰─╯  ╰──╮
#  2.23 ┤      │  │       │        │
#  1.97 ┤      │  ├───────╯        │
#  1.72 ┤  ╭───╯  │                │
#  1.46 ┤  │      │                │
#  1.21 ┤  │      │                │
#  0.95 ┤──╯      │                │
#      ─┴─────────┴────────────────
#       0      7.9       15.8      time(s)
#
# 可以看到在第 8 秒左右有一次大幅的内存分配。
# 看下面的详细信息找谁分配了这些内存：

# --------------------------------------------------------------------------
#   n    time(B)    total(B)   useful-heap(B)  extra-heap(B)  stacks(B)
# --------------------------------------------------------------------------
#  20     7,891,234   3,123,456   3,100,000       23,456       12,345
#  99.2% (3,100,000) 的堆内存分配在 process_frame 中
#  其中 80% 是在 process_frame → allocate_frame_buffer
#  说明大部分内存被帧缓冲占用了

PGO 的注意事项

Mon, 01 Jan 0001 00:00:00 +0000

PGO 最常见的问题：训练数据不具代表性。

❌ 错误的训练负载：
  ./scoremaster --test-video single_static_frame.h264
  → 只有 1 帧画面，profile 显示"detect 分支 100% 走缓存路径"
  → 优化后实际跑视频时 detect 分支频繁缓存未命中，变慢了

✅ 正确的训练负载：
  ./scoremaster --test-video typical_match.h264
  → 包含各种比赛场景的长时间视频
  → 覆盖了"有球/没球/密集/稀疏"等各种路径
  → PGO 优化的代码对真实场景最友好

其他注意：
  - 每次代码更新后需要重新收集 profile（旧的 .gcda 不能用）
  - 多线程程序：profile 数据不会包含线程调度的时序信息
  - PGO 不是魔法：算法复杂度上的优化（O(N^2) → O(N)）比 PGO 的 10-30% 提升大得多

RAII 封装——ScopeGuard

Mon, 01 Jan 0001 00:00:00 +0000

一、RAII 的本质

RAII（Resource Acquisition Is Initialization）的核心思想：资源获取和对象构造绑定，资源释放和对象析构绑定。

你每天都在用：

std::lock_guard<std::mutex> lock(mtx);  // 构造时 lock，析构时 unlock
std::ifstream file("data.txt");          // 构造时 open，析构时 close
std::unique_ptr<Foo> ptr(new Foo);       // 构造时 new，析构时 delete

二、ScopeGuard——通用的 RAII 封装

场景：函数中间有多个 return 点，每个 return 前都要做同样的清理：

void process() {
    FILE* f = fopen("data.txt", "r");
    // ... 如果这里 return 了，f 没关
    if (something) return;
    // ... 如果这里抛异常，f 没关
    fclose(f);
}

ScopeGuard 让你在构造时注册一个清理函数，析构时自动执行：

class ScopeGuard {
    std::function<void()> cleanup_;
    bool active_ = true;
public:
    explicit ScopeGuard(std::function<void()> cleanup)
        : cleanup_(std::move(cleanup)) {}

    ~ScopeGuard() {
        if (active_) cleanup_();  // 析构时执行清理
    }

    // 如果成功，可以调用 dismiss 取消清理
    void dismiss() { active_ = false; }
};

void process() {
    FILE* f = fopen("data.txt", "r");
    ScopeGuard close_file([&] { if (f) fclose(f); });

    if (something) return;  // 析构 ScopeGuard → 自动 fclose
    // ... 正常处理
    close_file.dismiss();    // 成功，不再需要自动清理
    fclose(f);               // 手动关闭
}

更简洁的宏（很多 C++ 项目这么用）：

RGB ↔ YUV 转换（sws_scale）

Mon, 01 Jan 0001 00:00:00 +0000

一、为什么需要它

从桌面采集（DXGI/PipeWire）拿到的是 BGRA/RGBA 帧，编码器只接受 YUV420P。sws_scale 一次性完成：

色彩空间转换（RGB → YUV）
色度下采样（4:4:4 → 4:2:0）
图像缩放（可选）

struct ColorConverter {
    SwsContext* sws_ctx = nullptr;
    int src_w, src_h, dst_w, dst_h;
    AVPixelFormat src_fmt, dst_fmt;

    bool init(int src_w, int src_h, AVPixelFormat src_fmt,
              int dst_w, int dst_h, AVPixelFormat dst_fmt) {
        this->src_w = src_w; this->src_h = src_h;
        this->dst_w = dst_w; this->dst_h = dst_h;
        this->src_fmt = src_fmt; this->dst_fmt = dst_fmt;

        sws_ctx = sws_getContext(
            src_w, src_h, src_fmt,        // 输入格式
            dst_w, dst_h, dst_fmt,        // 输出格式
            SWS_BILINEAR,                 // 插值算法（性能 vs 质量）
            nullptr, nullptr, nullptr      // 滤波器参数（默认）
        );
        return sws_ctx != nullptr;
    }

    // 把 BGRA 桌面采集帧转为 YUV420P（AVFrame）
    void convert(const uint8_t* bgra_data, int bgra_stride, AVFrame* out_frame) {
        // 封装 sws_scale 需要的数据
        uint8_t* src_data[1] = { (uint8_t*)bgra_data };
        int src_linesize[1] = { bgra_stride };

        sws_scale(sws_ctx,
                  src_data, src_linesize, 0, src_h,
                  out_frame->data, out_frame->linesize);
    }

    ~ColorConverter() {
        sws_freeContext(sws_ctx);
    }
};

// 使用示例：
// ColorConverter conv;
// conv.init(1920, 1080, AV_PIX_FMT_BGRA,   // 桌面采集的格式
//           1920, 1080, AV_PIX_FMT_YUV420P); // 编码器需要的格式
//
// AVFrame* yuv_frame = av_frame_alloc();
// yuv_frame->format = AV_PIX_FMT_YUV420P;
// yuv_frame->width = 1920;
// yuv_frame->height = 1080;
// av_frame_get_buffer(yuv_frame, 32);
//
// conv.convert(bgra_buffer, 1920 * 4, yuv_frame);
// // yuv_frame 现在有 YUV420P 数据，可以送给编码器

二、sws_scale 一步完成的操作对比

如果你手动做：
  BGRA → 逐像素转 YUV444 → UV 下采样到 4:2:0 → 分配 Y/U/V 三个缓冲区
  → 至少 3 次内存操作，3 个循环

sws_scale 一次调用：
  sws_scale(ctx, src, src_linesize, 0, h, dst, dst_linesize);
  内部 SIMD 优化：一次循环完成色彩转换 + 下采样 + 写入三个平面
  → 1 次内存操作，速度是手写的 3-5 倍

SPMC (单写多读) 与线程池任务分发（Work-Stealing）

Mon, 01 Jan 0001 00:00:00 +0000

1. SPMC（单写多读）的硬件本质

场景定义

1个写者（Writer）：生产数据（如配置更新、日志聚合、时钟信号）。
N个读者（Reader）：各自独立消费数据（如多个统计线程、监控面板、热备进程）。

硬件挑战：写者如何让所有读者看到最新数据？

方案A：共享锁（`std::shared_mutex`）—— 读者间乒乓

std::shared_mutex mtx;
int shared_data;

void writer() {
    std::unique_lock lock(mtx);
    shared_data = new_value; // 独占锁 → 缓存行 E→M
}

void reader() {
    std::shared_lock lock(mtx);
    int local = shared_data; // 共享锁 → 缓存行 E→S
}

硬件代价：

写者修改时，发 RFO（Read For Ownership），使所有读者的缓存行失效（I状态）。
读者读时，重新从主存/写者缓存加载（Cache Miss + 总线流量）。
缓存行在N+1个核心间频繁迁移，延迟随读者数线性增加。

方案B：RCU（Read-Copy-Update）—— 读者零开销

std::atomic<int*> global_ptr; // 指向共享数据的指针

void writer() {
    int* old = global_ptr.load(std::memory_order_acquire);
    int* new_data = new int(*old); // 拷贝
    *new_data = new_value;
    global_ptr.store(new_data, std::memory_order_release); // 发布新指针
    // 等待所有读者退出后，delete old (延迟回收)
}

void reader() {
    int* data = global_ptr.load(std::memory_order_acquire);
    int local = *data; // 完全无锁，无原子操作（除了指针load）
}

硬件行为：

ThreadSanitizer（TSan）

Mon, 01 Jan 0001 00:00:00 +0000

一、它能抓到什么

// 数据竞争（Data Race）—— 无锁编程最常见的 Bug

int shared_counter = 0;

void worker() {
    for (int i = 0; i < 100000; i++) {
        shared_counter++;  // 不是原子的！多个线程同时写
    }
}

void test_race() {
    std::thread t1(worker);
    std::thread t2(worker);
    t1.join();
    t2.join();
    // 最终结果不一定是 200000，且 TSan 会报告数据竞争
}

TSan 的输出：

WARNING: ThreadSanitizer: data race
  Write of size 4 at 0x7f1234567890 by thread T2:
    #0 worker() test.cpp:5 (test+0x...)

  Previous write of size 4 at 0x7f1234567890 by thread T1:
    #0 worker() test.cpp:5 (test+0x...)

  Location is global 'shared_counter' at 0x7f1234567890

二、用法

g++ -fsanitize=thread -g -O1 -o test test.cpp
./test

三、TSan 的限制

1. 要求所有代码（含第三方静态库）都加 -fsanitize=thread 编译。
   如果一个 .a 文件没有 TSan 检测，里面即使有 race 也检测不到。

2. 不能和 ASan 同时使用（TSan 用 shadow memory 检测 race，ASan 也用它检测越界）。

3. 运行速度慢约 5-10 倍。

4. 假阳性：有些"逻辑上不会出问题"的数据竞争也会被报告。
   比如你的 SPSC 队列中，生产者和消费者操作不同变量但在同一缓存行，
   TSan 可能因为同一缓存行的两个不同变量而报 false positive。

Type Erasure 的实战场景

Mon, 01 Jan 0001 00:00:00 +0000

一、插件系统

你写了一个事件处理系统，允许用户注册回调处理事件。你不想强制用户继承 EventHandler 接口：

class EventBus {
    std::vector<std::function<void(const Event&)>> handlers_;
public:
    void register(std::function<void(const Event&)> handler) {
        handlers_.push_back(std::move(handler));
    }

    void fire(const Event& evt) {
        for (auto& h : handlers_) h(evt);
    }
};

// 用户不需要继承任何东西，传个 lambda 就行
EventBus bus;
bus.register([](const Event& e) { /* 处理 */ });

二、什么时候用 Type Erasure，什么时候用 variant？

如果你在编译期知道所有可能的类型：
  用 std::variant<Circle, Square>  ← 更快，没有虚函数调用

如果你要在运行时支持任意新类型：
  用 Type Erasure  ← 灵活，但有一次虚函数调用

如果你要让用户不需要改继承关系：
  用 Type Erasure  ← 非侵入式

三、核心伪代码：编译器是怎么看它们的？

Mon, 01 Jan 0001 00:00:00 +0000

如果我们要写一个接收不同值类型的函数，编译器在底层是通过不同的引用符号来重载和区分它们的：

函数 处理数据(左值引用 T& 变量) {
    // 编译器说：传进来的是个正经左值（有名字、有地址）。
    // 我必须小心翼翼地复制它，绝对不能破坏原数据！
    执行深拷贝(变量);
}

函数 处理数据(右值引用 T&& 变量) {
    // 编译器说：传进来的是个右值（纯右值或将亡值，反正它马上要死了）。
    // 太好了！我可以合法当劫匪，直接偷走它的堆内存指针！
    执行零拷贝所有权转移(变量);
}

三、PMR（多态分配器）——C++17 的标准方案

Mon, 01 Jan 0001 00:00:00 +0000

你不需要手写分配器——标准库给你了

#include <memory_resource>

// 1. 分配一个缓冲区（可以栈上，可以堆上）
char buffer[1024 * 1024];  // 1MB

// 2. 创建 monotonic_buffer_resource（就是上面的 Arena）
std::pmr::monotonic_buffer_resource pool(buffer, sizeof(buffer));

// 3. 创建 pmr::vector，指定使用 pool
std::pmr::vector<int> vec(&pool);
vec.reserve(100000);  // 从 pool 分配，不调用 malloc

// 4. pool 析构时自动释放整个 buffer

PMR 提供的三种 Resource

Resource	行为	适用场景
`monotonic_buffer_resource`	只加偏移，不释放单个对象，整块释放	同 Arena，几乎最快
`unsynchronized_pool_resource`	对象池，管理不同大小的块，可释放单个	需要频繁 alloc/dealloc 相同大小的对象（单线程）
`synchronized_pool_resource`	同上，但线程安全	多线程共享同一个分配器

实战：用 PMR 优化日志处理

// 场景：HTTP 请求处理，每次请求需要构建大量 string
// 每次请求结束后，这些 string 全部可以释放

struct RequestContext {
    std::pmr::string method;
    std::pmr::string path;
    std::pmr::vector<std::pmr::string> headers;
    std::pmr::string body;
    // 所有 pmr::string 使用同一个 pool

    explicit RequestContext(std::pmr::memory_resource* pool)
        : method(pool), path(pool), headers(pool), body(pool) {}
};

// 每次请求创建一个 arena
char buffer[1024 * 64]; // 64KB 足够一次请求
std::pmr::monotonic_buffer_resource pool(buffer, sizeof(buffer));
RequestContext ctx(&pool);
// ... 处理请求 ...
// ctx 析构时，pool 复位，64KB 零碎分配一次性释放

三、四种 requires 表达式——到底怎么读？

Mon, 01 Jan 0001 00:00:00 +0000

template <typename T>
concept Example = requires(T a, T b) {
    // ① 简单要求：这个表达式必须能编译
    a + b;          // T 必须支持 operator+(T, T)
    a.begin();      // T 必须有 begin() 成员

    // ② 类型要求：这个类型必须存在
    typename T::value_type;   // T 必须有 value_type 成员类型
    typename T::iterator;     // T 必须有 iterator 成员类型

    // ③ 复合要求：表达式必须有特定返回类型
    { a * b } -> std::convertible_to<int>;
    // a * b 必须能编译，且结果能隐式转 int

    // ④ 嵌套要求：里面的约束必须满足
    requires std::is_destructible_v<T>;
    // T 必须是可析构的
};

理解方式：把 requires(...) 读作**“检查这些代码能否编译通过”**。如果里面所有代码都能编译，Concept 为 true，否则为 false。

三、常用的 View——什么时候用？

Mon, 01 Jan 0001 00:00:00 +0000

View	作用	什么时候用
`filter(pred)`	筛选满足条件的元素	过滤无效数据、错误剔除
`transform(func)`	对每个元素做转换	数据类型转换、字段提取、数值计算
`take(N)`	取前 N 个	分页（取第 1 页）、取 TopK
`drop(N)`	跳过前 N 个	分页（跳过前一页）
`reverse`	反转顺序	最近操作记录（最新在最前）
`join`	展平嵌套容器	`vector<vector<int>>` 变 `vector<int>`
`split(delim)`	按分隔符分割	CSV 解析、命令行参数分割

组合使用案例：日志分析

std::vector<LogEntry> logs = get_logs();

// 需求：找出最近 10 条 ERROR 级别的错误消息，按倒序显示
auto recent_errors = logs
    | std::views::filter([](const LogEntry& e) { return e.level == "ERROR"; })
    | std::views::reverse                              // 最新的在前面
    | std::views::take(10)                             // 只要 10 条
    | std::views::transform([](const LogEntry& e) { return e.message; });
// 一次遍历完成，没有中间容器，没有多余拷贝

两类现象，两条路径

Mon, 01 Jan 0001 00:00:00 +0000

4.2 两类现象，两条路径

上一节：4.1 负载生成器　|　下一节：4.3 async-profiler

一句话结论

剖析工具选错的代价，是得到「没有瓶颈」这个错误结论。 记住一条分叉：CPU 高 → 用 on-CPU 采样；CPU 不高但慢 → 用 wall-clock 采样。 这两条路径的差别，比工具之间的差别重要得多。

一、用厨房理解两种「慢」

一家餐厅出菜慢，有两种完全不同的原因：

现象	厨房状态	类比后端
灶台全开着，厨师忙不过来	CPU 时间被占满	CPU 高：真在算
厨师都闲着，在等食材送到	CPU 空闲，时间花在等待	CPU 不高：在等 IO / 锁 / 下游

关键洞察：这两种情况的排查手段完全不同。

第一种：看「谁在占用灶台」→ on-CPU 采样，找最宽的函数。
第二种：看「厨师在等什么」→ wall-clock 采样，找阻塞点。

如果对第二种情况用第一种工具：你会看到一张几乎空白的火焰图（因为 CPU 没在干活），然后得出「没有瓶颈」的错误结论。

这是新手最常见的分析错误，也是最浪费时间的一种——因为你会反复采集、反复看空图，怀疑是工具坏了。

二、分叉决策表

现象	首选工具	事件类型	你会看到
CPU 接近饱和（> 70%）	async-profiler / JFR	`cpu` / `jdk.ExecutionSample`	火焰图顶部有明确的宽块
CPU 低（< 40%）但延迟高	async-profiler	`wall`	线程大面积停在等待栈上
CPU 的 `sys` 占比高	系统工具 + 火焰图	`cpu`（看内核栈）	系统调用、锁、页错误
GC 停顿与延迟尖刺对齐	GC 日志 / JFR	`jdk.GCPhasePause`	周期性停顿
分配速率高	async-profiler	`alloc`	谁在制造垃圾
吞吐上不去但 CPU 不高	async-profiler	`lock`	锁争用
所有指标都正常但用户说慢	看测量点（第 1 章 1.3）	客户端/网关/tracing	问题可能在网络或上游

三、四种事件的完整分工

事件	采样依据	回答	典型发现
`cpu`	CPU 时间	谁在消耗 CPU？	热点函数、算法问题、序列化开销
`wall`	墙上时间	时间都花在哪（含等待）？	阻塞 IO、锁等待、下游慢
`alloc`	分配的对象	谁在制造 GC 压力？	装箱、字符串拼接、正则编译
`lock`	锁等待时间	谁在抢锁？	锁竞争、临界区过大

记忆方法：

减少工作：最可靠的一类优化

Mon, 01 Jan 0001 00:00:00 +0000

7.2 减少工作：最可靠的一类优化

上一节：7.1 优先级金字塔　|　下一节：7.3 并发与并行配套代码：07-optimization-and-validation/02-reduce-work

一句话结论

与其把一件事做得更快，不如不做它。 「减少工作」类的优化（批处理、消除 N+1、提前剪枝、避免重复序列化）收益最确定、副作用最小、几乎不需要权衡——因为没有引入新的组件、缓存或并发。

一、用「少跑腿」理解减少工作

你每天要跑 5 趟超市，每趟 20 分钟，共 100 分钟。

优化方向	做法	效果
提高速度	开车更快（危险）	100 → 80 分钟
减少工作 ⭐	一次买齐（列清单）	100 → 24 分钟

后者的收益是前者的 8 倍，而且没有风险。

后端完全一样：把 N 次查询合并成 1 次，比「把每次查询优化得快 20%」收益大得多。

二、五种「减少工作」的模式

❶ 批处理：N 次变 1 次

// ❌ N 次往返
val orders = ids.map { repo.findById(it) }        // 100 次查询

// ✅ 1 次往返
val orders = repo.findByIds(ids)                  // 1 次：where id = any(?)

典型收益：组件基准实测（第 3 章 3.2 节）——批量比循环快 82 倍（P99 从 210 ms 降到 6.2 ms）。

参数化基准测试

Mon, 01 Jan 0001 00:00:00 +0000

一、自动生成测试用例

#include <benchmark/benchmark.h>
#include <vector>
#include <algorithm>

// 测试不同 N 下 vector 的插入性能
static void BM_Vector_PushBack(benchmark::State& state) {
    for (auto _ : state) {
        std::vector<int> v;
        // state.range(0) 是传入的参数
        for (int i = 0; i < state.range(0); i++) {
            v.push_back(i);
        }
        benchmark::DoNotOptimize(v);
    }
}
// 生成一系列参数：8, 16, 32, 64, 128, 256, 512, 1024
BENCHMARK(BM_Vector_PushBack)->RangeMultiplier(2)->Range(8, 8 << 7);

// 测试不同的 reserve 策略
static void BM_Vector_Reserve(benchmark::State& state) {
    for (auto _ : state) {
        std::vector<int> v;
        v.reserve(state.range(0));
        for (int i = 0; i < state.range(0); i++) {
            v.push_back(i);
        }
        benchmark::DoNotOptimize(v);
    }
}
BENCHMARK(BM_Vector_Reserve)->RangeMultiplier(2)->Range(8, 8 << 7);

// 对比两个版本的输出，可以看到 reserve 后的版本快多少

二、对比测试结果

./bench

# 输出示例：
# -------------------------------------------------------------------------
# Benchmark                               Time   CPU     Iterations
# -------------------------------------------------------------------------
# BM_Vector_PushBack/8                   23 ns  22 ns     31875984
# BM_Vector_PushBack/64                 155 ns 155 ns      4514715
# BM_Vector_PushBack/512                1252 ns 1250 ns     560000
# BM_Vector_PushBack/4096              10123 ns 10120 ns     69173
# BM_Vector_PushBack/32768            101234 ns 101200 ns     6917
#
# BM_Vector_Reserve/8                    12 ns  12 ns     58337169  ← 快了近一倍
# BM_Vector_Reserve/64                   83 ns  83 ns      8435509
# BM_Vector_Reserve/512                 551 ns  551 ns     1269806
# BM_Vector_Reserve/4096               4123 ns  4120 ns     169720
# BM_Vector_Reserve/32768             37893 ns  37890 ns     18475

# 结论：reserve 后 push_back 快约 2x（省掉了多次扩容 + 搬移）

三、用 `compare.py` 生成对比报告

# 先编译优化前的版本
g++ -O2 -o bench_before bench.cpp -lbenchmark
./bench_before --benchmark_out=before.json --benchmark_out_format=json

# 修改代码做优化

# 再编译优化后的版本
g++ -O2 -o bench_after bench.cpp -lbenchmark
./bench_after --benchmark_out=after.json --benchmark_out_format=json

# 用 benchmark 自带的比较脚本生成报告
python3 /path/to/benchmark/tools/compare.py benchmarks before.json after.json

# 输出：
# Run on (8 X 2400 MHz CPU s)
# CPU Caches:
#   L1 Data 32K (x4)
#   L1 Instruction 32K (x4)
#   L2 Unified 256K (x4)
#   L3 Unified 8192K (x1)
# Loading benchmarks...
# Comparing before.json to after.json
# Benchmark                          Time        CPU     Time Old   Time New  CPU Old   CPU New
# --------------------------------------------------------------------------------------------
# BM_Vector_PushBack/8              -0.4868    -0.4868        23        12       22        12
# BM_Vector_PushBack/64             -0.4623    -0.4623       155        83      155        83
# BM_Vector_PushBack/512            -0.5595    -0.5595      1252       551     1250       552
# 负值表示时间减少了（变快了），所以这个优化是有效的

取消定时器

Mon, 01 Jan 0001 00:00:00 +0000

为什么要用 shared_ptr<bool> 而不是直接删除任务？

// 取消方式
auto timer_id = timer.addTimer(100ms, [] { ... });
// 取消：标记为已取消
*timer_id = true;

为什么不能直接从优先队列删除？

std::priority_queue 不提供按值删除的接口。
即使可以，删除后要调整堆，$O(\log N)$。

惰性删除：标记任务为取消（*cancelled = true），到期检查时看到已取消就不执行。虽然任务还在队列里占空间，但避免了删除的开销。如果取消的任务不多，这完全可以接受。

吞吐、延迟、成本的三方权衡

Mon, 01 Jan 0001 00:00:00 +0000

0.2 吞吐、延迟、成本的三方权衡

上一节：0.1 三类问题必须分开处理　|　下一节：0.3 延迟是分布，不是数字

一句话结论

「让性能变好」是一句没有意义的话。 任何优化都是在「吞吐量、延迟、资源成本」三者之间做取舍——你必须说清楚：在什么成本约束下，把哪个指标改善到什么程度。

一、用一个快递公司的故事理解三者关系

假设你开了一家快递站，每天要送 1000 个包裹：

策略	吞吐量	单个包裹的延迟	成本
一件一送：每来一个包裹就派一辆车	低（一天最多几十趟）	极低（来了就走）	极高（要几十辆车、几十个司机）
攒够 100 件送一趟	高（10 趟送完）	高（第一个包裹要等到第 100 个才出发）	低（一辆车就够）

看出来了吗？「吞吐高」和「延迟低」在这里是直接冲突的。

再看第三个维度：那辆车的载重、司机的数量、仓库的大小——这就是资源成本。想同时提高吞吐、降低延迟，唯一办法是加钱（更多车辆、更多司机）。

性能优化就是这么回事：

性能优化的本质，是在给定的成本预算下，重新分配「吞吐—延迟」这一对矛盾。

所以当有人说「我要性能更好」时，你必须追问：

「你能接受多大成本？你更在意「每秒处理更多」还是「每个请求更快」？」

二、三个指标的通俗定义与精确含义

2.1 吞吐量（Throughput）

通俗：单位时间能干完多少活。
精确：每秒完成的请求数（req/s、QPS、RPS）。注意分母是「成功完成」的请求数——返回 500 的错误请求不该算进吞吐。

2.2 延迟（Latency / Response Time）

通俗：一个请求从发出到收到结果，等了多久。
精确：必须说明是哪个点测的——客户端观测、网关观测、服务端 handler 内部，三者数值不同（第 1 章会展开）。

2.3 资源成本（Cost / Resource）

通俗：为了达到上面两个数字，花了多少钱。
精确：CPU 核数、内存、连接数、副本数、以及这些折算成的账单。

记住：延迟和吞吐是「结果」，成本是「代价」。只谈前两个而不谈代价的性能报告，是不完整的。

三、一个具体的数字例子：批量 vs 单条

假设你在写一个批量导入功能，要往数据库插 1000 行。

方案 A：逐条插入

堆排序（HeapSort）

Mon, 01 Jan 0001 00:00:00 +0000

一、核心思路：利用二叉堆

堆排序分两步：

建堆：把数组变成最大堆（父节点 ≥ 子节点）。
排序：反复把堆顶（最大值）交换到数组末尾，然后调整剩余部分为堆。

heapify 整体操作流程：

初始化：假设当前节点 i 是最大值，记录其左右子节点位置。
找最大：比较 nums[i] 与其左右子节点，将最大值的索引赋值给 largest。
交换与下沉：如果 largest != i，交换 nums[i] 和 nums[largest]，然后递归对 largest 位置进行 heapify（下沉调整）。

heapSort 整体操作流程：

建堆：从最后一个非叶子节点（n/2 - 1）开始，从下往上调用 heapify，构建最大堆。
排序：循环 n-1 次：将堆顶（最大值）与末尾元素交换 → 堆大小减 1 → 对堆顶执行 heapify 恢复堆性质。
结果：所有元素交换完毕后，数组按升序排列。

void heapify(vector<int>& nums, int n, int i) {
    int largest = i;                               // ① 假设当前节点最大
    int left = 2 * i + 1;                          // ② 左子节点
    int right = 2 * i + 2;                         // ③ 右子节点

    if (left < n && nums[left] > nums[largest])    // ④ 左子更大 → 更新
        largest = left;
    if (right < n && nums[right] > nums[largest])  // ⑤ 右子更大 → 更新
        largest = right;

    if (largest != i) {                            // ⑥ 最大值不是当前节点
        swap(nums[i], nums[largest]);              // ⑦ 交换，让最大值上浮
        heapify(nums, n, largest);                 // ⑧ 递归下沉被换下去的节点
    }
}

void heapSort(vector<int>& nums) {
    int n = nums.size();

    for (int i = n / 2 - 1; i >= 0; i--) {         // ① 从最后一个非叶子节点开始建堆
        heapify(nums, n, i);
    }

    for (int i = n - 1; i > 0; i--) {              // ② 逐个取出堆顶
        swap(nums[0], nums[i]);                    // ③ 堆顶（最大值）放到末尾
        heapify(nums, i, 0);                       // ④ 对剩余 i 个元素调整堆
    }
}

建堆的过程（nums = [3, 7, 8, 5, 2, 1, 9]）：

常见问题排查清单

Mon, 01 Jan 0001 00:00:00 +0000

一、推流失败

# ① 先确认端口通不通
telnet rtmp-server.com 1935

# ② 用 ffmpeg 命令行测试推流（排除代码问题）
ffmpeg -f lavfi -i testsrc -f flv rtmp://server/live/test

# 如果 ffmpeg 能推，你的代码不能，说明是代码问题
# 如果 ffmpeg 也不能推，说明是服务器/网络问题

二、画面花屏

可能原因：
  GOP 设置太大 → 播放器丢失了第一个 I 帧，后续 P 帧无法解码
  解决方案：
    - -g 15（每 15 帧插一个 I 帧）
    - 播放器等待下一个 I 帧
    - 推流开始时先发送一段静音帧让播放器稳定

  H.264 sps/pps 丢失：
    sps/pps 是 H.264 的解码配置，必须在第一个 I 帧之前发送
    RTMP 连接时先发送 AVCDecoderConfigurationRecord（包含 sps/pps）
    然后在每个关键帧前重复发送 sps/pps（称为"extra data"）

三、音画不同步

排查步骤：
  1. 用 ffprobe 检查时间基是否一致
     ffprobe input.mp4 -show_streams
     看 video 和 audio 的 time_base

  2. 检查是否有 B 帧导致 PTS/DTS 错位
     ffprobe -show_frames input.mp4 | grep pict_type
     如果有 B 帧，确保解码时按照 DTS 顺序，显示时按照 PTS 顺序

  3. 检查 PTS 是否有跳变
     打印每帧的 PTS，看是否单调递增
     如果 PTS 回退或大幅跳变，说明时间戳设置有问题

  4. 编码前后的 time_base 转换是否正确
     av_packet_rescale_ts 必须使用正确的输入/输出 time_base

四、推流延迟大

可能原因和解决方法：

  问题：编码器缓冲太多帧（lookahead）
  解决：-tune zerolatency, -rc_mode cbr

  问题：GOP 太大（关键帧间隔太长）
  解决：-g 15 或 -g 30

  问题：B 帧引入延迟
  解决：-bf 0（不用 B 帧）

  问题：网络拥塞
  解决：降低码率 -b:v 1000k（1Mbps）
       使用 CBR（固定码率）而不是 VBR（可变码率）

  问题：RTMP Chunk 大小设置不合理
  解决：RTMP 默认 chunk_size = 128，不需要改

延迟分解：把总账拆成明细

Mon, 01 Jan 0001 00:00:00 +0000

6.2 延迟分解：把总账拆成明细

上一节：6.1 分析流程五步法　|　下一节：6.3 火焰图读法配套代码：06-analysis-and-profiling/02-latency-decomposition

一句话结论

「这个接口要 400 ms」是一个总账。 分析的第一步是把它拆成网络 / 排队 / 应用 / 各依赖几段——因为不同的段对应完全不同的修法，而总账无法告诉你该改哪里。

一、用「工厂流水线的工时分析」理解延迟分解

工厂发现「一件产品从下单到发货要 8 天」，要改进就得知道这 8 天花在哪：

工序	耗时	占 8 天的比例
订单排队等排产	3 天	37%
原料采购	2 天	25%
生产加工	1 天	12%
质检	0.5 天	6%
包装入库	0.5 天	6%
发货运输	1 天	12%

看到这张表，改进方向立刻明确：优化「生产加工」（只占 12%）最多省 1 天；而"订单排队"占了 3 天——那才是大头。

后端的延迟分解完全一样，而且结论常常反直觉：

一个 P99 = 200 ms 的接口：
  网络 + 客户端排队   70 ms  (35%)
  网关 + 服务排队     90 ms  (45%)  ← 真正的瓶颈
  应用自身代码         7 ms  (3.5%) ← 你想优化的地方
  数据库              25 ms  (12.5%)
  缓存 + 下游          8 ms  (4%)

你写的代码只占 3.5%。 如果只优化它，最多省 7 ms。

建造者模式（Builder）

Mon, 01 Jan 0001 00:00:00 +0000

一、什么时候用？

场景：构造一个对象需要十几个参数，有些必填、有些可选、有些有依赖关系：

// ❌ 构造函数方式——十几个参数，调用者分不清谁是谁
HttpRequest req("POST", "http://api.example.com/data", 
                10000,  // timeout
                true,   // keepalive
                "gzip", // encoding
                ...);

// ✅ Builder 方式——逐步设置，可读性强
HttpRequest req = HttpRequest::Builder()
    .method("POST")
    .url("http://api.example.com/data")
    .timeout(10000)
    .keepalive(true)
    .encoding("gzip")
    .build();

二、Builder 的现代 C++ 写法

class HttpRequest {
public:
    class Builder {
        std::string method_ = "GET";
        std::string url_;
        int timeout_ = 5000;
        bool keepalive_ = true;
        std::string encoding_ = "utf-8";

    public:
        Builder& method(std::string m) { method_ = std::move(m); return *this; }
        Builder& url(std::string u)    { url_ = std::move(u);   return *this; }
        Builder& timeout(int t)        { timeout_ = t;          return *this; }

        // [[nodiscard]] 防止调用者忘了调用 build()
        [[nodiscard]] HttpRequest build() {
            // 可以在 build 时做参数校验
            if (url_.empty()) throw std::invalid_argument("url required");
            return HttpRequest(std::move(method_), std::move(url_),
                              timeout_, keepalive_, std::move(encoding_));
        }
    };

private:
    HttpRequest(std::string method, std::string url, int timeout,
                bool keepalive, std::string encoding)
        : method_(std::move(method)), url_(std::move(url)),
          timeout_(timeout), keepalive_(keepalive), encoding_(std::move(encoding)) {}
};

关键：Builder 只是中间媒介，build() 才真正构造对象。构造函数的参数可以是 private 的，强制用户通过 Builder 创建。

执行过程

Mon, 01 Jan 0001 00:00:00 +0000

调用者线程：                 工作线程：
enqueue(compute, 42)
  ↓
创建 packaged_task<int()>
  ↓
把 task 包装成 void() lambda
放入任务队列
  ↓
cv.notify_one() ──────────→ 唤醒等待的工作线程
  ↓                           ↓
返回 future<int>             取任务，执行 (*task)()
  ↓                           ↓
调用 future.get() ←────────── 结果存入 future
  ↓                           阻塞直到结果就绪
拿到结果 42

折叠表达式（Fold Expressions）

Mon, 01 Jan 0001 00:00:00 +0000

一、解决什么问题？

问题：在 C++17 之前，你想对可变参数包做一个"累加"操作，必须写递归模板：

// C++11 风格的求和（痛苦）
auto sum() { return 0; }  // 终止
template <typename T, typename... Args>
auto sum(T first, Args... rest) {
    return first + sum(rest...); // 递归
}

折叠表达式：一句话搞定。

二、四种折叠——看明白一张表就够了

语法	名称	对 `(1, 2, 3, 4)` 的展开
`(args + ...)`	一元右折叠	`(1 + (2 + (3 + 4)))`
`(... + args)`	一元左折叠	`(((1 + 2) + 3) + 4)`
`(0 + ... + args)`	二元右折叠	`(0 + (1 + (2 + 3)))`
`(args + ... + 0)`	二元左折叠	`(((1 + 2) + 3) + 0)`

要不要区分左和右？

无锁编程的 ABA 问题实战解法

Mon, 01 Jan 0001 00:00:00 +0000

这是无锁编程中最隐蔽、最难调试的陷阱——比内存分配器更"邪门"，因为它在单线程下完全不存在，只有在多线程高并发下才会随机触发，导致数据损坏或程序崩溃。

1. ABA 问题的本质（硬件视角回顾）

我们之前讲过 ABA 问题的硬件根源，现在从实战角度重新审视：

// 场景：无锁栈的 pop 操作（有 ABA 漏洞）
std::atomic<Node*> head{nullptr};

bool pop(Node*& result) {
    Node* old_head = head.load(std::memory_order_acquire);
    Node* new_head;
    do {
        if (!old_head) return false;
        new_head = old_head->next;  // ← 读取 old_head 的 next
    } while (!head.compare_exchange_weak(old_head, new_head,
              std::memory_order_release, std::memory_order_relaxed));
    
    result = old_head;  // ← 此时 old_head 可能已经被其他线程释放！
    return true;
}

ABA 攻击时序：

[时刻 T1] 线程A 读取 head = 节点X (地址 0x1000)
[时刻 T2] 线程B 弹出节点X → head = 节点Y
[时刻 T3] 线程B 释放节点X（delete / free）
[时刻 T4] 线程B 分配新节点Z，恰好复用地址 0x1000
[时刻 T5] 线程B push 节点Z → head = 0x1000
[时刻 T6] 线程A 执行 CAS：当前 head (0x1000) == 期望值 (0x1000) → ✅ 成功！
          new_head = old_head->next = 0x1000->next (此时是节点Z的next)
          head = new_head（可能是垃圾地址）

结果：head 指向了完全无关的地址，数据结构被破坏。

无锁链表与无锁栈（Michael-Scott Queue）

Mon, 01 Jan 0001 00:00:00 +0000

恭喜你，终于来到了并发编程的巅峰战场：无锁数据结构（Lock-Free Data Structures）。这不仅是C++高性能开发的皇冠明珠，也是你之前所有硬件知识（CAS、内存屏障、缓存行）的终极应用。

我们先解剖无锁栈，再深入Michael-Scott (MS) 无锁队列，最后解决那个最棘手的问题：无锁环境下，怎么安全地释放内存？

1. 无锁栈（Lock-Free Stack）：最简单的无锁结构

基于我们之前讲的 compare_exchange_weak，实现一个无锁栈非常简单：

template<typename T>
class LockFreeStack {
    struct Node {
        T data;
        Node* next;
    };
    std::atomic<Node*> head{nullptr};

public:
    void push(T value) {
        Node* new_node = new Node{value, nullptr};
        Node* old_head = head.load(std::memory_order_relaxed);
        do {
            new_node->next = old_head; // 设置新节点的next指向旧栈顶
        } while (!head.compare_exchange_weak(old_head, new_node,
                 std::memory_order_release, std::memory_order_relaxed));
    }

    // ⚠️ 危险版本：有ABA问题 + 内存释放问题
    bool pop(T& result) {
        Node* old_head = head.load(std::memory_order_relaxed);
        Node* new_head;
        do {
            if (!old_head) return false;
            new_head = old_head->next; // 读取next
        } while (!head.compare_exchange_weak(old_head, new_head,
                 std::memory_order_acquire, std::memory_order_relaxed));
        
        result = old_head->data;
        delete old_head; // 💥 灾难：其他线程可能还在访问这个节点！
        return true;
    }
};

这里有两个致命问题：

步骤一：定义目标

Mon, 01 Jan 0001 00:00:00 +0000

9.2 步骤一：定义目标

上一节：9.1 项目设定与埋雷清单　|　下一节：9.3 步骤二：搭服务与数据用到：第 1 章（SLO 四要素、延迟预算）配套代码：09-capstone/02-step1-goals 产出：docs/slo.md

一句话结论

这一步决定后面所有工作的方向。 没有 SLO，「优化」就是无的放矢——因为你不知道要优化到多少才算够。

一、要回答的三个问题

问题	为什么必须先答
峰值 QPS 是多少？	决定容量规划与压测强度
用户能接受多慢？	决定 SLO 阈值（不能拍脑袋）
数据会涨到多大？	决定测试数据量与容量规划的时间跨度

如果这三个答不出来：

① 去问业务方（这是产品决策，不是技术决策）
② 或者从现有监控里取真实数据
③ 实在拿不到 → 在 SLO 表里标注「待确认」，并写明打算怎么获取

「待确认」本身就是一个有价值的产出——它暴露了「目前的性能目标没有依据」这个事实。

二、SLO 表（四要素）

<!-- docs/slo.md -->

# SLO 表

> 最后更新：YYYY-MM-DD　|　对应版本：<commit>
> 填写说明：四要素缺一不可。写不出来的标「待确认」，并注明获取方式。

## 接口 1：GET /{code}（跳转）

| 字段 | 值 |
| --- | --- |
| 接口 | `GET /{code}` |
| 关键路径 | 客户端 → 服务 → Redis → PostgreSQL |
| **目标 QPS（峰值）** | 3000 |
| **P50 / P95 / P99 / P999** | 5 / 30 / 100 / 300 ms |
| **错误率阈值** | < 0.1% |
| 超时率阈值 | < 0.05% |
| 负载前提：数据量 | 100 万条 links |
| 负载前提：**数据分布** | **幂律（齐夫，alpha≈1.2）**：前 1% 的 code 承担 40% 访问 |
| 负载前提：缓存状态 | warm（预热 5 分钟） |
| **测量点** | 压测客户端（最接近用户体验） |
| 预热时长 | 60 秒 |
| 稳态时长 | 10 分钟 |
| 验收轮次 | ≥ 3 轮，取中位数 |
| 环境 | 单实例 4C8G；压测客户端独立进程 |
| **崩溃线** | P99 > 1s 或错误率 > 1% 持续 30 秒 |
| 测量日期与版本 | YYYY-MM-DD，commit `abc1234` |

**待确认项**：
- [ ] 峰值 QPS 的真实数据（向业务方确认 / 从监控取值）
- [ ] 数据量的一年增长预期

## 接口 2：POST /links（创建短链）

| 字段 | 值 |
| --- | --- |
| 接口 | `POST /links` |
| 目标 QPS | 60（读:写 ≈ 50:1） |
| P50 / P95 / P99 | 20 / 60 / 150 ms |
| 错误率阈值 | < 0.5%（唯一索引冲突是正常业务，单独统计） |
| 负载前提 | 100 万条已有数据；URL 平均长度 60 字符 |
| 测量点 | 压测客户端 |
| 崩溃线 | P99 > 1s |

注意三处刻意的设计：

百分位不可平均：直方图才是正解

Mon, 01 Jan 0001 00:00:00 +0000

1.2 百分位不可平均：直方图才是正解

上一节：1.1 指标分四层　|　下一节：1.3 测量点配套代码：01-metrics-and-slo/02-percentiles-and-aggregation 前置：0.3 延迟是分布（百分位的定义）

一句话结论

百分位是一个「位置」，不是一个「可加减的量」。 把多台机器的 P99 求平均，得到的数字不代表任何一台机器、也不代表任何用户。正确做法是：采集直方图（分桶统计），在查询时合并后再算百分位。

一、用考试成绩理解「位置」与「数量」的区别

一个班 50 个学生考试。老师说：

「我们班的平均分是 78 分。」「我们班的第 95 百分位分数是 96 分。」

现在把三个班合起来，问「全校的 P95 是多少」：

班级	人数	平均分	P95 分
一班	50	78	96
二班	50	80	97
三班	50	76	95

❌ 错误做法：(96 + 97 + 95) / 3 = 96。

为什么错：「第 95 百分位」是「排在第 95% 位置上的那个分数」。三个班的「第 95% 位置」是三个不同的位置，把它们平均，得到的不是任何一个真实位置上的分数。

✅ 正确做法：把 150 个分数合在一起重新排序，再取第 95% 位置。这个结果可能不是 96、97、95 中的任何一个。

第一阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

CRTP 本质：
    编译期多态，基类知道派生类类型
    用 static_cast<Derived*> 消除虚函数间接调用

核心价值：
    短小高频函数快 3-5 倍（可内联）
    enable_shared_from_this 是标准库案例

代价：
    不同派生类不能放同一个容器
    每实例化一次生成一份代码

第七阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

PTS vs DTS：
    DTS = 解码器使用的顺序
    PTS = 显示时使用的顺序
    B 帧导致两者不一致

音频主时钟：
    音频位置 = 已播放样本数 / 采样率
    视频根据音频位置决定丢帧或等待

同步阈值：
    偏差 < ±20ms：忽略
    偏差 20-100ms：延迟显示或跳帧
    偏差 > 100ms：必须纠正（音频优先）

第二阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

火焰图生成：
  perf record → perf script → FlameGraph.pl → SVG

火焰图解读：
  宽条 = 热点，平顶 = 函数自身耗时
  尖顶 = 大部分时间在子函数

冰柱图：
  自顶向下，适合看调用路径分布

第六阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

RTMP：实时性最好的传统直播协议（1-3 秒延迟）
    基于 TCP，握手后持续推送 FLV Tag
    Chunk 分片保证音频不被大视频包阻塞

HLS：兼容性最好的直播协议（6-30 秒延迟）
    把直播切成 TS 片段 + m3u8 播放列表
    iOS 原生支持，其他平台通过 <video> 播放

选型：
    实时互动（连麦/直播）→ RTMP 或 WebRTC
    点播/录播 → HLS（兼容性最好）
    浏览器直播 → HTTP-FLV（flv.js）

简易 Work-Stealing 实现

Mon, 01 Jan 0001 00:00:00 +0000

class WorkStealingThreadPool {
    std::vector<std::thread> workers_;
    std::vector<std::deque<std::function<void()>>> queues_;
    std::vector<std::mutex> mtxs_;         // 每个队列一把锁
    std::atomic<bool> stop_{false};

public:
    WorkStealingThreadPool(size_t threads)
        : workers_(threads), queues_(threads), mtxs_(threads)
    {
        for (size_t i = 0; i < threads; i++) {
            workers_[i] = std::thread([this, i] { worker_loop(i); });
        }
    }

    void enqueue(size_t thread_id, std::function<void()> task) {
        std::lock_guard<std::mutex> lock(mtxs_[thread_id]);
        queues_[thread_id].push_front(std::move(task));  // 放入自己的 front
    }

    // 提交到负载最轻的线程
    void enqueue(std::function<void()> task) {
        // 找队列最短的线程
        size_t min_idx = 0;
        size_t min_size = queues_[0].size();
        for (size_t i = 1; i < queues_.size(); i++) {
            if (queues_[i].size() < min_size) {
                min_size = queues_[i].size();
                min_idx = i;
            }
        }
        enqueue(min_idx, std::move(task));
    }

private:
    void worker_loop(size_t my_id) {
        while (!stop_) {
            std::function<void()> task;
            bool found = false;

            // 1. 先看自己的队列
            {
                std::lock_guard<std::mutex> lock(mtxs_[my_id]);
                if (!queues_[my_id].empty()) {
                    task = std::move(queues_[my_id].front());
                    queues_[my_id].pop_front();
                    found = true;
                }
            }
            if (found) { task(); continue; }

            // 2. 自己队列空，开始偷取
            for (size_t i = 0; i < queues_.size(); i++) {
                size_t victim = (my_id + 1 + i) % queues_.size();
                if (victim == my_id) continue;

                std::lock_guard<std::mutex> lock(mtxs_[victim]);
                if (!queues_[victim].empty()) {
                    task = std::move(queues_[victim].back());
                    queues_[victim].pop_back();
                    found = true;
                    break;
                }
            }
            if (found) { task(); continue; }

            // 3. 所有队列都空，让出 CPU
            std::this_thread::yield();
        }
    }
};

这个实现有个问题：没有用条件变量。空等时线程会不断 yield，浪费 CPU。工业级 Work-Stealing 通常加一个全局条件变量做"所有队列空了就休眠，有新任务就唤醒所有"的机制。

组件基准：性价比最高的一层

Mon, 01 Jan 0001 00:00:00 +0000

3.2 组件基准：性价比最高的一层

上一节：3.1 六层金字塔总览　|　下一节：3.3 集成基准与全链路配套代码：03-test-pyramid/02-component-benchmark

一句话结论

后端 80% 的性能问题（慢 SQL、N+1、序列化开销、索引缺失、锁竞争）都能在组件基准里被发现，而它的迭代成本只有几十秒。 这是投入产出比最高的一层，也是大多数团队完全缺失的一层。

一、用「台架试验」理解组件基准

汽车厂商测发动机，会把它装在台架上：接上真实的油路、水路、排气，但不装在整车上。

为什么？

台架的好处	对应组件基准
环境可控、可重复	固定数据集、固定随机种子
出问题立刻知道是发动机的	慢就是这条 SQL 慢，不会怪到网络上
一次试验几分钟，一天能试几十轮	一次基准几十秒，快速迭代
能测到极限工况（红线转速）	能测到极端数据（1 亿行、热点 key）

关键：台架用的是真发动机，不是模型。同理，组件基准必须用真实数据库（Testcontainers 起的 PostgreSQL），不能用 H2 之类替代品——因为索引行为、执行计划、锁机制完全不同。

用 H2 做基准的后果：在 H2 上很快的查询，在 PostgreSQL 上可能因为执行计划不同而慢 100 倍。你会得到「测试通过、上线爆炸」的经典结局。

二、组件基准测什么：四件事分开测

一个接口的真实成本 = SQL 执行 + 驱动/ORM 映射 + 业务逻辑 + 序列化。必须分开测，否则你只知道总数，不知道哪块贵。

测什么	怎么测	常见发现
① 纯 SQL 执行	直接用 JDBC 执行，不含映射	缺索引、全表扫描、锁等待
② 驱动/ORM 映射	对比「JDBC 结果集 → 对象」与①的差值	ORM 的反射开销、N+1
③ 业务逻辑	用固定输入调用 service 方法，mock 掉 IO	算法问题、重复计算
④ 序列化	单独测 JSON 编解码	反射型序列化器、大对象

为什么必须分开：假设你测出「接口总耗时 60 ms」，你无法判断该优化哪个。分开之后：

编码器基础流程

Mon, 01 Jan 0001 00:00:00 +0000

一、从原始帧→编码流的四个阶段

原始 YUV 帧
    │
    ▼
① 预测（Prediction）
   帧内预测：用当前帧已编码的区域预测当前块（I 帧适用）
   帧间预测：用前一帧搜索最相似的块，记录位移向量（P 帧适用）
   输出 = 残差块（原始块 - 预测块）
    │
    ▼
② 变换（DCT）
   把残差块从"空间域"转成"频域"
   DCT 后：低频系数（左上角）很大 → 人眼敏感
          高频系数（右下角）很小 → 人眼不敏感
    │
    ▼
③ 量化（Quantization）
   把 DCT 系数除以量化步长 → 高频系数变成 0
   "丢掉人眼不敏感的信息"——这是有损压缩的核心
    │
    ▼
④ 熵编码（Entropy Coding）
   Huffman / 算术编码 → 无损压缩
   CABAC（H.264 默认）：比 CAVLC 压缩率高 10%，但计算量大 3x
    │
    ▼
H.264 码流

二、手写简化 DCT（了解原理即可）

真正的编码器用整数 DCT（如 HEVC 的 4x4 DCT），这里用简化版展示原理：

编译器重排 vs CPU 乱序执行

Mon, 01 Jan 0001 00:00:00 +0000

这个问题是理解内存屏障的终极门槛！很多开发者分不清"编译器重排"和"CPU乱序执行"，更不清楚Store Buffer和Invalidation Queue如何"合谋"制造出反直觉的内存可见性问题。

我们先从硬件架构出发，解剖现代CPU的"谎言"，再深入两种重排的本质区别。

1. 编译器重排 vs CPU乱序执行：本质区别

编译器重排（Compile-time Reordering）

发生时机：编译阶段（静态）

动机：优化寄存器分配、指令流水线。

// C++ 源码
int a = 1;  // 操作1
int b = 2;  // 操作2

// 编译器可能重排为（如果操作1更耗时）
int b = 2;  // 操作2 先执行
int a = 1;  // 操作1 后执行

关键：编译器认为单线程下结果等价，但多线程下可能暴露问题。

CPU乱序执行（Out-of-Order Execution）

发生时机：运行阶段（动态）

动机：填充流水线气泡，提高执行效率。

; 汇编代码（编译器生成顺序）
MOV [addr1], 1   ; 写操作1
MOV R1, [addr2]  ; 读操作2

; CPU实际执行（如果addr1 cache miss）
MOV R1, [addr2]  ; 先执行读（因为不需要等写完成）
MOV [addr1], 1   ; 后执行写

关键：CPU通过重排序缓冲区（ROB） 保证单线程语义，但多线程下其他核心看到的是乱序结果。

对比总结表

维度	编译器重排	CPU乱序执行
发生阶段	编译时	运行时
控制者	编译器（GCC/Clang）	CPU硬件（乱序执行单元）
防护手段	`asm volatile("" ::: "memory")`	`mfence` / `lfence` / `sfence`
C++控制	`std::atomic` 的 memory_order	同上（硬件层面）
可见性	二进制代码顺序已变	二进制顺序不变，但执行顺序变

2. Store Buffer（写缓冲区）：CPU的"谎言"之一

为什么需要Store Buffer？

核心问题：L1缓存写入太慢（需要等待缓存行变为E/M状态，可能要发RFO等待其他核心响应）。

色度采样（Chroma Subsampling）

Mon, 01 Jan 0001 00:00:00 +0000

一、为什么 UV 可以压缩？

一张 1920×1080 的图片，Y 分量保留了所有边缘和纹理细节。把 UV 分辨率降低到 960×540，人眼几乎看不出区别——因为人眼对颜色的空间分辨率远低于亮度。

原始 RGB：1920×1080 × 3 bytes = 6.2 MB
YUV 4:4:4：1920×1080 + 1920×1080 + 1920×1080 = 也 6.2 MB（没省空间）
YUV 4:2:0：1920×1080(Y) + 960×540(U) + 960×540(V) = 3.1 MB → 省了 50%

二、4:4:4 / 4:2:2 / 4:2:0 图解

符号含义："J:a:b"
  J = 水平参考宽度（通常 4 个像素）
  a = 第一行每个 J 像素中有几个色度样本
  b = 第二行中多出的色度样本数

4:4:4（无压缩）
  像素位置: 0    1    2    3    4    5    6    7
  Y:        Y0   Y1   Y2   Y3   Y4   Y5   Y6   Y7
  U:        U0   U1   U2   U3   U4   U5   U6   U7
  V:        V0   V1   V2   V3   V4   V5   V6   V7
  每个像素都有自己的 Y/U/V → 数据量 = 1920×1080×3

4:2:2（水平减半）
  像素位置: 0    1    2    3    4    5    6    7
  Y:        Y0   Y1   Y2   Y3   Y4   Y5   Y6   Y7
  U:        U0        U2        U4        U6
  V:        V0        V2        V4        V6
  每 2 个像素共享一组 UV → 数据量 = 1920×1080 × 2
  常见于专业视频采集、广播设备

4:2:0（水平和垂直都减半）
  像素位置: 0    1    2    3
  第 0 行 Y: Y00  Y10  Y20  Y30
            U:  U00       U20
            V:  V00       V20
  第 1 行 Y: Y01  Y11  Y21  Y31
            U:  (使用第 0 行的 U/V，不重复存储)
            V:
  每 4 个像素共享一组 UV → 数据量 = 1920×1080 × 1.5
  所有视频编码标准（H.264/HEVC/VP9/AV1）的默认格式

三、4:4:4 → 4:2:0 下采样的手写实现

#include <vector>
#include <cstdint>

// 把 YUV 4:4:4 的 UV 平面下采样为 4:2:0
// 输入：UV 平面和 Y 一样大（w × h）
// 输出：UV 平面各缩小为 (w/2) × (h/2)
void subsample_420(const uint8_t* src_u, const uint8_t* src_v,
                   uint8_t* dst_u, uint8_t* dst_v,
                   int width, int height) {
    int uv_w = width / 2;
    int uv_h = height / 2;

    for (int y = 0; y < uv_h; y++) {
        for (int x = 0; x < uv_w; x++) {
            // 4:2:0 的 U/V 取 2×2 块的均值
            int sum_u = 0, sum_v = 0;
            for (int dy = 0; dy < 2; dy++) {
                for (int dx = 0; dx < 2; dx++) {
                    int src_idx = (y * 2 + dy) * width + (x * 2 + dx);
                    sum_u += src_u[src_idx];
                    sum_v += src_v[src_idx];
                }
            }
            int dst_idx = y * uv_w + x;
            dst_u[dst_idx] = sum_u / 4;
            dst_v[dst_idx] = sum_v / 4;
        }
    }
}

四、三种采样格式的数据量对比

void print_sizes(int width, int height) {
    int y_size = width * height;
    int uv_444 = width * height;
    int uv_422 = (width / 2) * height;
    int uv_420 = (width / 2) * (height / 2);

    auto fmt = [](int bytes) {
        if (bytes > 1024 * 1024)
            return std::to_string(bytes / 1024 / 1024) + "MB";
        return std::to_string(bytes / 1024) + "KB";
    };

    std::cout << width << "x" << height << " 一帧:\n"
              << "  RGB24:     " << fmt(y_size * 3) << "\n"
              << "  YUV 4:4:4: " << fmt(y_size + uv_444 * 2) << "\n"
              << "  YUV 4:2:2: " << fmt(y_size + uv_422 * 2) << "\n"
              << "  YUV 4:2:0: " << fmt(y_size + uv_420 * 2) << "\n";
}

// print_sizes(1920, 1080);
// 输出：
//   RGB24:     6.2 MB
//   YUV 4:4:4: 6.2 MB
//   YUV 4:2:2: 4.1 MB
//   YUV 4:2:0: 3.1 MB

观察点（Watchpoint）

Mon, 01 Jan 0001 00:00:00 +0000

一、看变量值什么时候变了

// 一个典型的 Bug：某个全局变量被意外修改
int g_counter = 0;

void thread_a() {
    for (int i = 0; i < 100; i++) {
        g_counter++;   // 正常递增
    }
}

void thread_b() {
    // 某个地方错误地重置了 g_counter
    if (some_condition) {
        g_counter = 0; // ⚠️ 不该在这重置
    }
}

(gdb) watch g_counter             # g_counter 的值变化时停下
(gdb) continue
...

# 第一次触发：
Hardware watchpoint 1: g_counter
Old value = 42
New value = 0
# 线程 2 把 g_counter 从 42 改成了 0

(gdb) bt                          # 看调用栈，找到重置的代码位置
#0 thread_b() at bug.cpp:15       # 第 15 行就是罪魁祸首

其他观察点：

配套代码：CI 微基准门禁

Mon, 01 Jan 0001 00:00:00 +0000

8.2 配套代码：CI 微基准门禁

对应小节：8.2 CI 微基准门禁四个部分：① CI workflow；② 比较脚本；③ 噪声分析；④ 误报日志。

一、CI workflow（完整版）

# .github/workflows/perf-gate.yml
name: perf-gate

on:
  push:
    branches: [main]              # ⚠️ 只在主干跑
  workflow_dispatch:

jobs:
  micro-benchmark:
    # ⚠️ 生产项目应使用自建、规格固定的 runner
    runs-on: ubuntu-latest
    timeout-minutes: 30

    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: '21'

      - uses: actions/cache@v4
        with:
          path: ~/.gradle
          key: gradle-${{ hashFiles('**/*.gradle.kts') }}

      # ① 记录 CI 环境（用于判断"环境是否变化"）
      - name: Record CI environment
        run: |
          {
            echo "runner_os=$(uname -s -r -m)"
            echo "cpus=$(nproc)"
            echo "mem=$(free -h | awk '/Mem:/{print $2}')"
            echo "java=$(java -version 2>&1 | head -1)"
            echo "commit=${{ github.sha }}"
          } | tee perf-ci-env.txt

      # ② 跑基准
      - name: Run benchmarks
        run: ./gradlew benchmark -q

      # ③ 与基线对比
      #    ⚠️ 第一阶段用 --report-only（只报告不失败），观察两周确认零误报
      #       第二阶段去掉 --report-only 启用失败
      - name: Compare against baseline
        id: compare
        continue-on-error: true
        run: |
          python3 tools/compare_benchmark.py \
            build/reports/benchmarks/main.json \
            perf/baseline.json \
            --threshold 0.25 \
            --report-only \
            --output perf-result.md

      # ④ 把结果写到 CI 摘要（开发者不用点开日志就能看到）
      - name: Publish summary
        if: always()
        run: |
          cat perf-result.md >> $GITHUB_STEP_SUMMARY
          echo "" >> $GITHUB_STEP_SUMMARY
          echo "### CI 环境" >> $GITHUB_STEP_SUMMARY
          cat perf-ci-env.txt >> $GITHUB_STEP_SUMMARY

      # ⑤ 上传原始数据（便于事后分析）
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: benchmark-results-${{ github.sha }}
          path: |
            build/reports/benchmarks/
            perf-result.md
            perf-ci-env.txt

      # ⑥ 启用失败（第二阶段才打开）
      # - name: Fail on regression
      #   if: steps.compare.outcome == 'failure'
      #   run: exit 1

注意第 ③ 步的注释：先用 --report-only 观察两周——这是避免门禁被过早讨厌的关键（第 8.2 节）。

配套代码：SLO 表与延迟预算校验

Mon, 01 Jan 0001 00:00:00 +0000

9.2 配套代码：SLO 表与延迟预算校验

对应小节：9.2 步骤一：定义目标

一、SLO 定义文件

# perf/slo.yaml —— 单一事实源：文档、门禁、告警都从这里读
service: shortlink
version: "1.0"
owner: "@backend-team"
updated: "2024-06-01"

slis:
  # ── 接口级 ──
  - name: redirect_latency
    description: "跳转接口的端到端延迟"
    metric: "http_server_requests_seconds"
    labels: { uri: "/{code}", method: GET }
    unit: ms

  - name: create_latency
    description: "创建接口的端到端延迟"
    metric: "http_server_requests_seconds"
    labels: { uri: "/links", method: POST }
    unit: ms

  - name: redirect_availability
    description: "跳转接口的成功率"
    metric: "app_requests_failed / app.requests.total"
    labels: { uri: "/{code}" }
    unit: ratio

  - name: dependency_latency
    description: "数据库查询延迟（依赖级）"
    metric: "app_db_query_seconds"
    unit: ms

# ── 关键：错误预算的分子要排除"正常业务失败" ──
exclusions:
  - "短码冲突（业务正常，重试成功）"
  - "用户输入的非法 URL（归 4xx，不计失败）"

slos:
  - sli: redirect_latency
    objective: "P99 < 100ms"
    window: "28d"
    error_budget: "1% 的请求可超 100ms"

  - sli: create_latency
    objective: "P99 < 200ms"      # 写路径预算更宽（有 INSERT）
    window: "28d"
    error_budget: "1%"

  - sli: redirect_availability
    objective: ">= 99.9%"
    window: "28d"
    error_budget: "0.1% = 43.2min/月"

  - sli: dependency_latency
    objective: "P99 < 60ms"       # 依赖预算 = 端到端预算的一部分
    window: "28d"

budget:
  latency_budget:
    total_ms: 100
    allocations:
      - { component: "网关/负载均衡", ms: 5,  type: serial }
      - { component: "Ktor 路由与序列化", ms: 5, type: serial }
      - { component: "业务逻辑", ms: 10, type: serial }
      - { component: "数据库查询", ms: 60, type: critical, parallel_with: ["缓存查询"] }
      - { component: "缓存查询", ms: 2,  type: parallel }
      - { component: "余量", ms: 18, type: reserve }
    notes: |
      数据库与缓存是【互斥】的（缓存未命中才查库），
      所以最大路径 = 串行部分 + max(数据库, 缓存) = 80 + 60 = 140ms？❌

      不对 —— 串行部分只有 网关+路由+业务 = 20ms，
      加上 max(60, 2) = 60ms，总计 80ms，留 20ms 余量 ✅

二、延迟预算校验器

#!/usr/bin/env python3
"""tools/validate-budget.py —— 校验延迟预算是否自洽

只做三件事：
  1. 串行项相加 + 并行项取最大 <= 总预算
  2. 每项都有明确的 type（serial/parallel/critical/reserve）
  3. 余量 >= 20%（否则没有容错空间）
"""
import sys
import yaml


def validate(path: str) -> int:
    with open(path) as f:
        slo = yaml.safe_load(f)

    budget = slo["budget"]["latency_budget"]
    total = budget["total_ms"]
    allocs = budget["allocations"]

    errors = []

    # ── ① 每项必须声明 type ──
    for a in allocs:
        if "type" not in a:
            errors.append(f"「{a['component']}」缺少 type 字段")

    serial = [a for a in allocs if a["type"] in ("serial", "critical")]
    parallel = [a for a in allocs if a["type"] == "parallel"]
    reserve = [a for a in allocs if a["type"] == "reserve"]

    serial_sum = sum(a["ms"] for a in serial)
    parallel_max = max((a["ms"] for a in parallel), default=0)

    # ── ② 并行项必须真的并行（不能有依赖关系）──
    # 简化：只检查是否显式声明了 parallel_with
    for a in parallel:
        if "parallel_with" not in a:
            errors.append(
                f"「{a['component']}」标为 parallel 但未声明 parallel_with —— "
                f"无法证明它真的并行"
            )

    worst_path = serial_sum + parallel_max
    reserve_ms = sum(a["ms"] for a in reserve)
    reserve_pct = reserve_ms / total * 100

    # ── ③ 最坏路径 + 余量 <= 总预算 ──
    if worst_path + reserve_ms > total:
        errors.append(
            f"预算超支：最坏路径 {worst_path}ms + 余量 {reserve_ms}ms "
            f"= {worst_path + reserve_ms}ms > 总预算 {total}ms"
        )

    # ── ④ 余量比例 ──
    if reserve_pct < 20:
        errors.append(
            f"余量只有 {reserve_pct:.0f}%（< 20%）—— "
            f"没有容错空间，任何一项超支都会击穿 SLO"
        )

    # ── 输出 ──
    print(f"总预算：{total}ms")
    print(f"串行路径：{serial_sum}ms  " + " + ".join(f"{a['ms']}" for a in serial))
    print(f"并行取最大：{parallel_max}ms  " + ", ".join(a["component"] for a in parallel))
    print(f"最坏路径：{worst_path}ms")
    print(f"余量：{reserve_ms}ms ({reserve_pct:.0f}%)")
    print()

    if errors:
        print("❌ 预算校验失败：")
        for e in errors:
            print(f"   • {e}")
        return 1

    print("✅ 预算自洽")
    print()
    print(f"解读：最坏路径 {worst_path}ms，留 {total - worst_path}ms 余量")
    print(f"      → 只要依赖不超过各自预算，端到端不会击穿 {total}ms")
    return 0


if __name__ == "__main__":
    sys.exit(validate(sys.argv[1] if len(sys.argv) > 1 else "perf/slo.yaml"))

三、把 SLO 变成压测阈值

#!/usr/bin/env bash
# tools/gen-k6-thresholds.sh —— 从 slo.yaml 生成 k6 的 thresholds 片段
# 为什么这么做：阈值和 SLO 必须是【同一个数字】，否则会漂移
set -euo pipefail

SLO="${1:-perf/slo.yaml}"
OUT="perf/thresholds.js"

python3 - "$SLO" > "$OUT" <<'PY'
import sys, yaml

with open(sys.argv[1]) as f:
    slo = yaml.safe_load(f)

print("// 本文件由 tools/gen-k6-thresholds.sh 自动生成 —— 请勿手改")
print("// 改 SLO 请改 perf/slo.yaml，然后重跑生成脚本")
print("export const thresholds = {")

for s in slo["slos"]:
    sli = s["sli"]
    obj = s["objective"]                      # 例如 "P99 < 100ms"

    if "P99 <" in obj:
        ms = obj.split("<")[1].strip().rstrip("ms")
        # 门禁阈值 = SLO 阈值 × 1.0（不做额外收紧）
        # 为什么不像常规那样收紧 1.5 倍：这里是在【验证 SLO】，
        # 不是在【卡回归】——回归门禁见第 9.9 节
        print(f"  '{sli}': ['p(99)<{ms}'],")

print("};")
PY

echo "✅ 已生成 $OUT"
echo
cat "$OUT"

生成的片段：

配套代码：减少工作的五种模式

Mon, 01 Jan 0001 00:00:00 +0000

7.2 配套代码：减少工作的五种模式

对应小节：7.2 减少工作每种模式给「反例 → 正例 → 验证方法」，以及一份可自动扫描的审查清单。

一、❶ 批处理：N 次变 1 次

// ❌ 反例：N 次往返
suspend fun loadOrdersBad(ids: List<Long>): List<Order> =
    ids.map { repo.findById(it) ?: error("not found") }      // N 次查询

// ✅ 正例 1：批量查询（= any）
suspend fun loadOrdersGood(ids: List<Long>): List<Order> = withContext(Dispatchers.IO) {
    ds.connection.use { c ->
        c.prepareStatement("select id, user_id, amount from orders where id = any(?)").use { ps ->
            ps.setArray(1, c.createArrayOf("bigint", ids.toTypedArray()))
            ps.executeQuery().use { rs ->
                buildList { while (rs.next()) add(rs.toOrder()) }
            }
        }
    }
}

// ✅ 正例 2：分批（避免单次 IN 列表过长，也便于控制内存）
suspend fun loadOrdersBatched(ids: List<Long>, batchSize: Int = 500): List<Order> =
    ids.chunked(batchSize).flatMap { chunk -> loadOrdersGood(chunk) }

// ✅ 正例 3：并行分批（IO 密集，且下游能承受）
suspend fun loadOrdersParallel(ids: List<Long>, batchSize: Int = 500): List<Order> =
    coroutineScope {
        ids.chunked(batchSize)
            .map { chunk -> async(Dispatchers.IO) { loadOrdersGood(chunk) } }
            .awaitAll()
            .flatten()
    }

验证方法：

配套代码：延迟分解的 PromQL 与自动计算

Mon, 01 Jan 0001 00:00:00 +0000

6.2 配套代码：延迟分解的 PromQL 与自动计算

对应小节：6.2 延迟分解把「三段减法」变成可执行的查询与脚本。

一、三段分解的 PromQL

-- ═══════════════════════════════════════════════════════════
-- ① 服务端完整延迟（进入 handler 到响应写完）
-- ═══════════════════════════════════════════════════════════
histogram_quantile(0.99,
  sum by (le) (rate(http_server_requests_seconds_bucket{uri="/orders/{id}"}[5m])))

-- ═══════════════════════════════════════════════════════════
-- ② 应用内延迟（handler 内部）
-- ═══════════════════════════════════════════════════════════
histogram_quantile(0.99,
  sum by (le) (rate(app_handler_duration_seconds_bucket[5m])))

-- ═══════════════════════════════════════════════════════════
-- ③ 服务排队 = ① − ②
-- ═══════════════════════════════════════════════════════════
histogram_quantile(0.99,
  sum by (le) (rate(http_server_requests_seconds_bucket{uri="/orders/{id}"}[5m])))
-
histogram_quantile(0.99,
  sum by (le) (rate(app_handler_duration_seconds_bucket[5m])))

-- ═══════════════════════════════════════════════════════════
-- ④ 各依赖
-- ═══════════════════════════════════════════════════════════
histogram_quantile(0.99, sum by (le) (rate(dep_postgres_seconds_bucket[5m])))
histogram_quantile(0.99, sum by (le) (rate(dep_redis_seconds_bucket[5m])))
histogram_quantile(0.99, sum by (le) (rate(dep_downstream_seconds_bucket[5m])))

-- ═══════════════════════════════════════════════════════════
-- ⑤ 应用自身开销 = ② − Σ依赖
--    ⚠️ 只在【串行调用】时成立；并行调用会算出负数
-- ═══════════════════════════════════════════════════════════
histogram_quantile(0.99, sum by (le) (rate(app_handler_duration_seconds_bucket[5m])))
-
(
  histogram_quantile(0.99, sum by (le) (rate(dep_postgres_seconds_bucket[5m])))
  +
  histogram_quantile(0.99, sum by (le) (rate(dep_redis_seconds_bucket[5m])))
  +
  histogram_quantile(0.99, sum by (le) (rate(dep_downstream_seconds_bucket[5m])))
)

⚠️ 重要提醒：分位数相减是近似（第 6.2 节）。它适合判断「哪段是大头」，不适合精确归因。精确归因需要 tracing 的 span 树。

二、自动分解脚本（从 Prometheus 拉数据）

# tools/decompose-latency.py <PROMETHEUS_URL> <URI_LABEL> [--percentile 0.99]
"""
从 Prometheus 拉取各段延迟，生成分解表。

用法：
  python3 tools/decompose-latency.py http://localhost:9090 '/orders/{id}'
"""
import json
import sys
import urllib.parse
import urllib.request


def query(prom_url, expr):
    url = f"{prom_url}/api/v1/query?" + urllib.parse.urlencode({"query": expr})
    try:
        with urllib.request.urlopen(url, timeout=10) as r:
            data = json.load(r)
        if data["status"] != "success":
            return None
        result = data["data"]["result"]
        return float(result[0]["value"][1]) if result else None
    except Exception as e:
        print(f"  ⚠️  查询失败: {e}", file=sys.stderr)
        return None


def hq(metric, selector="", q=0.99):
    return (f'histogram_quantile({q}, sum by (le) '
            f'(rate({metric}_bucket{selector}[5m])))')


def main():
    prom = sys.argv[1] if len(sys.argv) > 1 else "http://localhost:9090"
    uri = sys.argv[2] if len(sys.argv) > 2 else ""
    q = 0.99
    if "--percentile" in sys.argv:
        q = float(sys.argv[sys.argv.index("--percentile") + 1])

    print("═" * 70)
    print(f"延迟分解（P{q*100:.0f}，URI={uri or '全部'}）")
    print("═" * 70)
    print()

    selector = f'{{uri="{uri}"}}' if uri else ""

    segments = {
        "① 服务端完整延迟": hq("http_server_requests_seconds", selector, q),
        "② 应用内延迟": hq("app_handler_duration_seconds", "", q),
        "③ dep.postgres": hq("dep_postgres_seconds", "", q),
        "④ dep.redis": hq("dep_redis_seconds", "", q),
        "⑤ dep.downstream": hq("dep_downstream_seconds", "", q),
    }

    values = {}
    for label, expr in segments.items():
        v = query(prom, expr)
        values[label] = v

    server = values["① 服务端完整延迟"]
    inapp = values["② 应用内延迟"]
    deps = [values["③ dep.postgres"], values["④ dep.redis"], values["⑤ dep.downstream"]]

    def fmt(v):
        return f"{v*1000:.1f} ms" if v is not None else "n/a"

    # 打印各段
    print(f"{'段':<22}{'P' + str(int(q*100)):<10}{'占比'}")
    print("-" * 70)
    print(f"{'① 服务端完整延迟':<22}{fmt(server):<12}100%")
    print(f"{'② 应用内延迟':<22}{fmt(inapp):<12}"
          f"{(inapp/server*100):.1f}%" if server and inapp else "n/a")

    if server and inapp:
        queued = server - inapp
        print(f"{'③ 服务排队（①−②）':<22}{fmt(queued):<12}{queued/server*100:.1f}%")

    for label, v in zip(["④ dep.postgres", "⑤ dep.redis", "⑥ dep.downstream"], deps):
        if v is not None and server:
            print(f"{label:<22}{fmt(v):<12}{v/server*100:.1f}%")

    # 应用自身开销
    if inapp and all(d is not None for d in deps):
        dep_sum = sum(deps)
        self_cost = inapp - dep_sum
        print("-" * 70)
        if self_cost < 0:
            print(f"{'⑦ 应用自身（②−Σ依赖）':<22}{fmt(self_cost):<12}"
                  f"❌ 负数！说明链路中有并行调用，不能简单相减")
            print("   → 用 tracing 的 span 树看关键路径（第 6.2 节）")
        else:
            print(f"{'⑦ 应用自身（②−Σ依赖）':<22}{fmt(self_cost):<12}"
                  f"{self_cost/server*100:.1f}%")

    print()
    print("═" * 70)
    print("判读：")
    print("  哪一段占比最大，就从那一段开始排查。")
    print("  ⚠️  分位数相减是近似，只用于判断「哪段是大头」。")
    print("     精确归因请用 tracing span 树（同一批请求的各段耗时）。")
    print("═" * 70)


if __name__ == "__main__":
    main()

三、基于 tracing 的精确分解（推荐）

分位数相减是近似。精确做法是用 tracing：每个请求的 span 树里都有各段的真实耗时。

配套代码：时长规划与预热判定

Mon, 01 Jan 0001 00:00:00 +0000

5.2 配套代码：时长规划与预热判定

对应小节：5.2 预热、稳态与运行时长两件事：① 由周期推导时长；② 自动判定预热是否结束。

一、时长规划器

// src/main/kotlin/experiment/DurationPlanner.kt
package experiment

import kotlin.math.max

/**
 * 压测时长规划。
 *
 * 核心公式：稳态时长 ≥ 最长周期 × 2
 *   1 次 → 只能确认「这个事件发生过」
 *   2 次 → 能确认「它的影响是稳定的、可重复的」
 */
data class Periods(
    val gcOldGenMinutes: Double = 5.0,        // 从 GC 日志推算（两次 Full/Mixed GC 的间隔）
    val cacheTtlMinutes: Double = 30.0,       // 缓存 TTL（本地 + Redis，取较大者）
    val scheduledTaskMinutes: Double = 60.0,  // 最长定时任务间隔
    val poolRecycleMinutes: Double = 30.0,    // 连接池/线程池 idle 回收
    val warmupMinutes: Double = 2.0,          // 从滚动 CV 判定（第 2 章 2.4）
)

data class DurationPlan(
    val longestPeriodMinutes: Double,
    val warmupMinutes: Double,
    val steadyStateMinutes: Double,
    val totalMinutes: Double,
    val warnings: List<String>,
)

fun planDuration(p: Periods): DurationPlan {
    val longest = listOf(
        p.gcOldGenMinutes, p.cacheTtlMinutes, p.scheduledTaskMinutes, p.poolRecycleMinutes
    ).max()

    var steady = longest * 2
    val warnings = mutableListOf<String>()

    // 下限保护：即使公式算出更短，也至少 3 分钟
    if (steady < 3.0) {
        warnings += "按公式只需 %.1f 分钟，但低于 3 分钟会混入测量噪声与过渡态——已提升到 3 分钟"
            .format(steady)
        steady = 3.0
    }

    // 上限提醒：超过 2 小时成本过高，建议分层
    if (steady > 120) {
        warnings += "稳态需要 %.0f 分钟（> 2 小时），成本很高。建议：".format(steady)
        warnings += "  ① 测试环境可调短缓存 TTL（例如 30 分钟 → 5 分钟）"
        warnings += "  ② 把长周期问题交给专门的浸泡测试（1–12 小时），"
        warnings += "     日常优化验证只用 10–20 分钟覆盖 GC 周期"
    }

    // 检查是否某个周期被显著低估
    if (p.scheduledTaskMinutes < p.cacheTtlMinutes * 0.2) {
        warnings += "定时任务间隔（%.0f 分钟）远小于缓存 TTL（%.0f 分钟）——确认是否真的存在这么频繁的任务"
            .format(p.scheduledTaskMinutes, p.cacheTtlMinutes)
    }

    return DurationPlan(
        longestPeriodMinutes = longest,
        warmupMinutes = p.warmupMinutes,
        steadyStateMinutes = steady,
        totalMinutes = p.warmupMinutes + steady,
        warnings = warnings,
    )
}

/** 从实际场景推导周期（辅助函数） */
fun periodsFromGcLog(p99GcIntervalMinutes: Double, cacheTtl: Double, taskInterval: Double) =
    Periods(
        gcOldGenMinutes = p99GcIntervalMinutes,
        cacheTtlMinutes = cacheTtl,
        scheduledTaskMinutes = taskInterval,
        poolRecycleMinutes = cacheTtl / 2,     // 池回收通常与 TTL 同量级
    )

fun main() {
    println("═══ 场景一：典型 Web 服务 ═══")
    val p1 = Periods()   // 默认值
    printPlan(p1)

    println()
    println("═══ 场景二：轻量服务（周期都较短）═══")
    printPlan(Periods(
        gcOldGenMinutes = 2.0,
        cacheTtlMinutes = 10.0,
        scheduledTaskMinutes = 15.0,
        poolRecycleMinutes = 5.0,
    ))

    println()
    println("═══ 场景三：有每小时对账任务（成本高）═══")
    printPlan(Periods(
        gcOldGenMinutes = 5.0,
        cacheTtlMinutes = 30.0,
        scheduledTaskMinutes = 60.0,
        poolRecycleMinutes = 30.0,
    ))
}

private fun printPlan(p: Periods) {
    val plan = planDuration(p)
    println("各周期：GC %.0f / 缓存 %.0f / 定时任务 %.0f / 池回收 %.0f 分钟"
        .format(p.gcOldGenMinutes, p.cacheTtlMinutes, p.scheduledTaskMinutes, p.poolRecycleMinutes))
    println("最长周期 = %.0f 分钟".format(plan.longestPeriodMinutes))
    println("预热     = %.0f 分钟（不计入统计）".format(plan.warmupMinutes))
    println("稳态测量 = %.0f 分钟".format(plan.steadyStateMinutes))
    println("总时长   = %.0f 分钟".format(plan.totalMinutes))
    plan.warnings.forEach { println("  ⚠️  $it") }
}

预期输出：

配套代码：直方图合并实验

Mon, 01 Jan 0001 00:00:00 +0000

1.2 配套代码：直方图合并实验

对应小节：1.2 百分位不可平均要验证的结论：把多实例的 P99 求平均，会错得离谱且方向不确定；合并直方图才是正解。

一、先实现一个最小的直方图

真实系统里这件事由 Prometheus 的 histogram 完成，但自己实现一遍（30 行）能彻底消除困惑。

// src/main/kotlin/lesson01/BucketHistogram.kt
package lesson01

/**
 * 分桶直方图：只记录"每个桶里有多少个样本"。
 * 关键性质：**桶计数可以相加**，所以多实例的直方图能合并。
 *
 * @param bounds 桶的**上边界**（升序），例如 [5, 10, 20, 50, 100]
 *               最后一个桶是 (bounds.last(), +∞)
 */
class BucketHistogram(private val bounds: DoubleArray) {

    /** counts[i] = 落在第 i 个桶里的样本数；counts 比 bounds 多一个（溢出桶） */
    val counts = LongArray(bounds.size + 1)

    fun observe(value: Double) {
        val i = bounds.indexOfFirst { value <= it }
        counts[if (i < 0) bounds.size else i]++
    }

    fun total(): Long = counts.sum()

    /** ✅ 合并：这就是 Prometheus 的 `sum by (le)` 在做的事 */
    fun merge(other: BucketHistogram): BucketHistogram {
        require(bounds.contentEquals(other.bounds)) { "桶边界必须一致才能合并" }
        val merged = BucketHistogram(bounds)
        for (i in counts.indices) merged.counts[i] = counts[i] + other.counts[i]
        return merged
    }

    /**
     * 取分位数。返回"包含该分位数的桶的上边界"。
     * 这是 Prometheus histogram_quantile 的简化版——真实实现会在桶内做线性插值，
     * 所以这里的结果会有轻微偏差，但足够说明问题。
     */
    fun quantile(q: Double): Double {
        val target = q * total()
        var cumulative = 0L
        for (i in counts.indices) {
            cumulative += counts[i]
            if (cumulative >= target) {
                return if (i == 0) bounds[0] else bounds[i - 1]
            }
        }
        return bounds.last()
    }

    fun average(): Double {
        // 注意：直方图本身算不出精确平均值（丢失了桶内分布），这里用桶上边界近似
        var sum = 0.0
        var n = 0L
        for (i in counts.indices) {
            val representative = if (i == 0) bounds[0] else bounds[i - 1]
            sum += representative * counts[i]
            n += counts[i]
        }
        return if (n == 0L) 0.0 else sum / n
    }
}

/** 构造两个"实例"的直方图：A 健康，B 有 1% 的慢请求 */
fun buildTwoInstances(bounds: DoubleArray, samplesPerInstance: Int = 100_000): Pair<BucketHistogram, BucketHistogram> {
    val a = BucketHistogram(bounds)
    val b = BucketHistogram(bounds)

    var seed = 12345L
    fun nextDouble(): Double {
        // 简单的确定性伪随机，便于复现
        seed = seed * 6364136223846793005L + 1442695040888963407L
        return ((seed ushr 11).toDouble() / (1L shl 53).toDouble())
    }

    repeat(samplesPerInstance) {
        // 实例 A：99% 在 4~7ms，1% 在 15~25ms
        a.observe(if (nextDouble() < 0.01) 15 + nextDouble() * 10 else 4 + nextDouble() * 3)
        // 实例 B：99% 在 4~7ms，1% 在 1800~2200ms
        b.observe(if (nextDouble() < 0.01) 1800 + nextDouble() * 400 else 4 + nextDouble() * 3)
    }
    return a to b
}

fun main() {
    val bounds = doubleArrayOf(5.0, 10.0, 20.0, 50.0, 100.0, 200.0, 500.0, 1000.0, 2500.0)
    val (a, b) = buildTwoInstances(bounds)

    val p99a = a.quantile(0.99)
    val p99b = b.quantile(0.99)
    val p99merged = a.merge(b).quantile(0.99)

    println("=== 实验：两个实例的 P99 ===")
    println("A 实例 P99          : %8.1f ms".format(p99a))
    println("B 实例 P99          : %8.1f ms".format(p99b))
    println()
    println("❌ 两个 P99 求平均   : %8.1f ms   ← 不代表任何真实用户".format((p99a + p99b) / 2))
    println("✅ 合并直方图后计算  : %8.1f ms   ← 这才是真实用户看到的分位数".format(p99merged))
    println()
    println("误差                : %.1f 倍".format(((p99a + p99b) / 2) / p99merged))
    println("说明：B 的慢请求只占总样本的 0.5%%，还没到 P99 的位置，")
    println("      所以真实的 P99 依然落在快请求区间。")
    println()

    // ── 反过来：慢请求占比变大时，平均反而会低估 ──────────────
    println("=== 反向验证：把 B 的慢请求比例提高到 5% ===")
    val bounds2 = bounds
    val c = BucketHistogram(bounds2)
    val d = BucketHistogram(bounds2)
    var seed = 999L
    fun nextDouble(): Double {
        seed = seed * 6364136223846793005L + 1442695040888963407L
        return ((seed ushr 11).toDouble() / (1L shl 53).toDouble())
    }
    repeat(100_000) {
        c.observe(if (nextDouble() < 0.01) 15 + nextDouble() * 10 else 4 + nextDouble() * 3)
        d.observe(if (nextDouble() < 0.05) 1800 + nextDouble() * 400 else 4 + nextDouble() * 3)
    }
    val p99c = c.quantile(0.99)
    val p99d = d.quantile(0.99)
    val p99merged2 = c.merge(d).quantile(0.99)
    println("C 实例 P99          : %8.1f ms".format(p99c))
    println("D 实例 P99          : %8.1f ms".format(p99d))
    println("❌ 两个 P99 求平均   : %8.1f ms".format((p99c + p99d) / 2))
    println("✅ 合并直方图后计算  : %8.1f ms".format(p99merged2))
    println()
    println("这次「求平均」是【低估】了。同一个错误做法，")
    println("在不同的流量分布下会朝相反方向错 —— 这就是它最危险的地方。")
}

二、预期输出

=== 实验：两个实例的 P99 ===
A 实例 P99          :     20.0 ms
B 实例 P99          :   2500.0 ms

❌ 两个 P99 求平均   :   1260.0 ms   ← 不代表任何真实用户
✅ 合并直方图后计算  :     20.0 ms   ← 这才是真实用户看到的分位数

误差                : 63.0 倍

=== 反向验证：把 B 的慢请求比例提高到 5% ===
C 实例 P99          :     20.0 ms
D 实例 P99          :   2500.0 ms
❌ 两个 P99 求平均   :   1260.0 ms
✅ 合并直方图后计算  :   2500.0 ms

这次「求平均」是【低估】了。

请注意两次实验的对比：同样的错误做法，第一次高估 63 倍，第二次低估 2 倍。

配套代码：组件基准（Testcontainers + 采样循环）

Mon, 01 Jan 0001 00:00:00 +0000

3.2 配套代码：组件基准（Testcontainers + 采样循环）

对应小节：3.2 组件基准这份代码可以直接改造成你自己项目的组件基准。

一、测试容器与数据准备

// src/test/kotlin/bench/ComponentBenchmarkBase.kt
package bench

import com.zaxxer.hikari.HikariConfig
import com.zaxxer.hikari.HikariDataSource
import org.testcontainers.containers.PostgreSQLContainer
import org.testcontainers.junit.jupiter.Container
import org.testcontainers.junit.jupiter.Testcontainers
import java.sql.Connection
import kotlin.random.Random

@Testcontainers
abstract class ComponentBenchmarkBase {

    companion object {
        /**
         * 关键：容器在整个测试类生命周期内复用。
         * 每次启动容器要几秒到几十秒，会严重污染测量。
         */
        @Container
        @JvmStatic
        val pg: PostgreSQLContainer<*> = PostgreSQLContainer("postgres:16-alpine")
            .withDatabaseName("bench")
            .withUsername("bench")
            .withPassword("bench")
            .withReuse(true)
    }

    protected lateinit var ds: HikariDataSource

    protected fun startPool(poolSize: Int = 10) {
        ds = HikariDataSource(HikariConfig().apply {
            jdbcUrl = pg.jdbcUrl
            username = pg.username
            password = pg.password
            maximumPoolSize = poolSize
        })
    }

    /**
     * 建表 + 灌数据。
     *
     * ⚠️ 三个关键决策：
     *   1. 数据量 10 万行（与线上同数量级，否则执行计划不同）
     *   2. 幂律热点（前 1% 用户占大部分查询）
     *   3. 故意留一个【没有索引】的列，作为阳性对照
     */
    protected fun seedData(rows: Int = 100_000) {
        ds.connection.use { c ->
            c.createStatement().execute("""
                create table if not exists orders (
                    id          bigserial primary key,
                    user_id     bigint not null,
                    status      text   not null,
                    amount      bigint not null,
                    created_at  timestamptz not null default now()
                )
            """.trimIndent())

            // 用幂律分布生成 user_id：少数用户占大部分订单
            val rnd = Random(42)
            c.prepareStatement("insert into orders(user_id, status, amount) values (?, ?, ?)").use { ps ->
                for (i in 1..rows) {
                    // 幂律：u^3 让值集中在小区间（热点用户）
                    val u = rnd.nextDouble()
                    val userId = (1 + (1_000 * Math.pow(u, 3.0))).toLong()
                    ps.setLong(1, userId)
                    ps.setString(2, if (i % 10 == 0) "REFUNDED" else "PAID")
                    ps.setLong(3, rnd.nextLong(100, 100_00))
                    ps.addBatch()
                    if (i % 5_000 == 0) ps.executeBatch()
                }
                ps.executeBatch()
            }

            // ✅ 建索引：user_id（读路径的主索引）
            c.createStatement().execute("create index if not exists idx_orders_user_id on orders(user_id)")
            // ❌ 故意不建 status 的索引 —— 作为"缺索引"的阳性对照

            c.createStatement().execute("analyze orders")
        }
    }

    protected fun <T> withConn(block: (Connection) -> T): T = ds.connection.use(block)
}

二、采样循环与百分位统计

// src/test/kotlin/bench/Sampling.kt
package bench

/**
 * 组件基准的采样工具。
 *
 * 为什么不用 JMH：
 *   - 数据库查询有副作用（改变缓存、锁、统计信息），JMH 的"重复执行同一状态"不成立
 *   - 数据库延迟是重尾的，需要看分布而不是均值
 *   - 需要统计"查询次数"来发现 N+1
 */
class Sampler(
    private val warmup: Int = 5_000,
    private val rounds: Int = 30_000,
) {
    private var queryCount = 0L

    fun <T> run(label: String, body: (Int) -> T): LongArray {
        queryCount = 0

        // ① 预热：让连接池填满、PG 缓存热起来、JIT 完成编译
        repeat(warmup) { body(it) }

        // ② 采样：每次单独计时
        val samples = LongArray(rounds)
        for (i in 0 until rounds) {
            val t0 = System.nanoTime()
            body(i)
            samples[i] = System.nanoTime() - t0
        }

        samples.sort()
        println("%-38s P50 %8.1f us   P95 %8.1f us   P99 %8.1f us   查询数 %d".format(
            label,
            pct(samples, 0.50) / 1000.0,
            pct(samples, 0.95) / 1000.0,
            pct(samples, 0.99) / 1000.0,
            queryCount,
        ))
        return samples
    }

    /** 让被测代码能报告"这一轮执行了几次查询"——用于发现 N+1 */
    fun countQuery() { queryCount++ }

    companion object {
        fun pct(sorted: LongArray, q: Double): Double =
            sorted[((sorted.size - 1) * q).toInt().coerceIn(0, sorted.size - 1)].toDouble()

        fun report(title: String, sorted: LongArray, queryCount: Long = -1) {
            println("$title: P50=%.1f P95=%.1f P99=%.1f us%s".format(
                pct(sorted, 0.50) / 1000, pct(sorted, 0.95) / 1000, pct(sorted, 0.99) / 1000,
                if (queryCount >= 0) "  查询数=$queryCount" else ""))
        }
    }
}

三、四件事分开测

// src/test/kotlin/bench/OrderRepositoryBenchmark.kt
package bench

import org.junit.jupiter.api.BeforeAll
import org.junit.jupiter.api.Test
import kotlin.random.Random

class OrderRepositoryBenchmark : ComponentBenchmarkBase() {

    @BeforeAll
    fun setUp() {
        startPool(poolSize = 10)
        seedData(rows = 100_000)
    }

    private val sampler = Sampler(warmup = 5_000, rounds = 30_000)

    // ── ① 主键查询（走主键索引） ──────────────────────────────
    @Test
    fun `1 - findById`() {
        sampler.run("① findById（主键）") { i ->
            withConn { c ->
                c.prepareStatement("select id, user_id, amount from orders where id = ?").use { ps ->
                    ps.setLong(1, 1L + Random(i).nextInt(100_000))
                    ps.executeQuery().use { rs -> while (rs.next()) rs.getLong(3) }
                }
            }
            sampler.countQuery()
        }
    }

    // ── ② 二级索引查询（走 user_id 索引 + 回表） ──────────────
    @Test
    fun `2 - findByUserId`() {
        sampler.run("② findByUserId（二级索引）") { i ->
            withConn { c ->
                c.prepareStatement(
                    "select id, amount from orders where user_id = ? order by created_at desc limit 20"
                ).use { ps ->
                    ps.setLong(1, 1L + Random(i).nextInt(1_000))
                    ps.executeQuery().use { rs -> while (rs.next()) rs.getLong(2) }
                }
            }
            sampler.countQuery()
        }
    }

    // ── ③ 无索引列（全表扫描）—— 阳性对照 ────────────────────
    @Test
    fun `3 - findByStatus（无索引，全表扫描）`() {
        sampler.run("③ findByStatus（⚠️ 无索引）") { i ->
            withConn { c ->
                c.prepareStatement(
                    "select id, amount from orders where status = ? limit 20"
                ).use { ps ->
                    ps.setString(1, if (i % 2 == 0) "PAID" else "REFUNDED")
                    ps.executeQuery().use { rs -> while (rs.next()) rs.getLong(2) }
                }
            }
            sampler.countQuery()
        }
    }

    // ── ④ 批量查询 vs 循环单查（量化 N+1 的代价） ─────────────
    @Test
    fun `4a - N+1 循环单查（100 次）`() {
        sampler.run("④a 循环单查 ×100（N+1）") { _ ->
            val ids = (1L..100L).map { (it * 7919) % 100_000 + 1 }
            ids.forEach { id ->
                withConn { c ->
                    c.prepareStatement("select amount from orders where id = ?").use { ps ->
                        ps.setLong(1, id)
                        ps.executeQuery().use { rs -> while (rs.next()) rs.getLong(1) }
                    }
                }
                sampler.countQuery()
            }
        }
    }

    @Test
    fun `4b - 批量查询（1 次）`() {
        sampler.run("④b 批量查询（= any）") { _ ->
            val ids = (1L..100L).map { (it * 7919) % 100_000 + 1 }
            withConn { c ->
                c.prepareStatement("select id, amount from orders where id = any(?)").use { ps ->
                    ps.setArray(1, c.createArrayOf("bigint", ids.toTypedArray()))
                    ps.executeQuery().use { rs -> while (rs.next()) rs.getLong(2) }
                }
            }
            sampler.countQuery()
        }
    }
}

四、预期输出与判读

① findById（主键）                  P50    380.2 us   P95    890.1 us   P99   2104.3 us   查询数 30000
② findByUserId（二级索引）           P50   1180.4 us   P95   3402.7 us   P99   8706.2 us   查询数 30000
③ findByStatus（⚠️ 无索引）          P50  18234.6 us   P95  42108.9 us   P99  96412.5 us   查询数 30000
④a 循环单查 ×100（N+1）              P50 182340.0 us   P95 402118.0 us   P99 512004.0 us   查询数 3000000
④b 批量查询（= any）                 P50   1804.3 us   P95   3102.8 us   P99   6208.1 us   查询数 30000

四个结论直接从这张表读出来：

配套代码：调用点类型数量与去优化

Mon, 01 Jan 0001 00:00:00 +0000

2.2 配套代码：调用点类型数量与去优化

对应小节：2.2 JIT 的三大优化与去优化要验证的结论：同一个调用点混入的类型越多，性能越差；而且退化不是按比例发生的。

一、实验：单态 / 双态 / 巨态

// src/main/kotlin/lesson02/CallSitePolymorphism.kt
package lesson02

import kotlin.random.Random

/** 一个有多个实现的接口 */
interface Handler {
    fun handle(v: Int): Int
}

class HandlerA : Handler { override fun handle(v: Int) = v + 1 }
class HandlerB : Handler { override fun handle(v: Int) = v * 2 }
class HandlerC : Handler { override fun handle(v: Int) = v - 3 }
class HandlerD : Handler { override fun handle(v: Int) = v xor 7 }
class HandlerE : Handler { override fun handle(v: Int) = v shr 1 }

private var sink = 0L

/**
 * 关键：这里只有一个调用点 `h.handle(v)`。
 * 传入的 Handler 实现类数量，决定了这个调用点的"态"。
 */
fun runLoop(handlers: Array<Handler>, iterations: Int): Long {
    var acc = 0L
    var state = 12345
    repeat(iterations) {
        state = state * 1103515245 + 12345            // 简单的伪随机，避免被优化
        val h = handlers[(state ushr 16) and (handlers.size - 1)]
        acc += h.handle(it)                            // ← 唯一的调用点
    }
    sink += acc
    return acc
}

fun measure(handlers: Array<Handler>, warmup: Int = 2_000_000, measure: Int = 5_000_000): Double {
    repeat(warmup) { runLoop(handlers, 100) }
    val t0 = System.nanoTime()
    runLoop(handlers, measure)
    val t1 = System.nanoTime()
    return (t1 - t0).toDouble() / measure
}

fun main() {
    // 注意：handlers.size 必须是 2 的幂，上面的位运算取模才正确
    val cases = listOf(
        "单态（1 种实现）" to arrayOf<Handler>(HandlerA()),
        "双态（2 种实现）" to arrayOf<Handler>(HandlerA(), HandlerB()),
        "四态（4 种实现）" to arrayOf<Handler>(HandlerA(), HandlerB(), HandlerC(), HandlerD()),
        "巨态（8 种实现）" to arrayOf<Handler>(
            HandlerA(), HandlerB(), HandlerC(), HandlerD(),
            HandlerE(), HandlerA(), HandlerB(), HandlerC()
        ),
    )

    println("调用点的类型数量 → 单次耗时")
    println("-".repeat(46))
    val baseline = measure(cases[0].second)
    for ((label, handlers) in cases) {
        val ns = measure(handlers)
        println("%-18s %8.2f ns/op   (%.2fx)".format(label, ns, ns / baseline))
    }
    println()
    println("sink = $sink")
    println()
    println("预期：类型越多越慢。注意『双态』相对『单态』的退化幅度——")
    println("      即使只有 2 种类型，JIT 也无法再做单态内联优化。")
}

二、预期输出形态

调用点的类型数量 → 单次耗时
----------------------------------------------
单态（1 种实现）        4.12 ns/op   (1.00x)
双态（2 种实现）        7.83 ns/op   (1.90x)
四态（4 种实现）       12.41 ns/op   (3.01x)
巨态（8 种实现）       18.06 ns/op   (4.38x)

关键不是具体倍数，而是趋势：即使只有 2 种实现，退化也很明显（接近 2 倍）。这就是「1% 的慢路径拖累 99% 的快路径」的微观机制。

零拷贝核心武器 2：Linux 新一代 `io_uring`

Mon, 01 Jan 0001 00:00:00 +0000

io_uring 可以理解为 Linux 在 I/O 模型上的一个分水岭。它设计的目标，就是彻底解决 epoll 等传统模型在应对海量 I/O 时的根本性能痛点，为无锁队列和零拷贝提供了一条直达内核的“绿色通道”。

1. 破局：从“系统调用”到“共享队列”

传统 I/O 模型（如 epoll）的性能瓶颈在于，每次发起和完成 I/O 操作，都需要通过系统调用陷入内核，这伴随着昂贵的上下文切换和 CPU 缓存污染。

io_uring 最核心的变革在于：它创建了两个在用户态和内核态之间共享的环形缓冲区（Ring Buffer），作为通信的主通道，从而极大减少了系统调用次数。

2. 架构：SQ 与 CQ 双环形缓冲区

io_uring 的核心就是两个通过 mmap 共享的队列：

提交队列（Submission Queue, SQ）：这是用户态向内核“派发任务”的地方。你只需要将描述 I/O 操作的**提交队列条目（SQE）**放入 SQ 的尾部。
完成队列（Completion Queue, CQ）：这是内核向用户态“返回结果”的地方。内核完成 I/O 操作后，会将包含结果（如返回码）的**完成队列条目（CQE）**放入 CQ 的尾部，供用户态程序读取。

+----------------------------------------------------------+
|  用户态地址空间                  内核态地址空间             |
|                                    |                       |
|  +-----------------+  mmap映射  +---------------------+    |
|  | 提交队列 (SQ)   |<---------->| 内核处理 SQ 中的请求 |    |
|  |  [SQE] [SQE]    |            |                     |    |
|  +-----------------+            +---------------------+    |
|         |                              |                    |
|         | 放置请求                      | 执行结果           |
|         v                              v                    |
|  +-----------------+  mmap映射  +---------------------+    |
|  | 完成队列 (CQ)   |<---------->| 内核将结果写入 CQ    |    |
|  |  [CQE] [CQE]    |            |                     |    |
|  +-----------------+            +---------------------+    |
+----------------------------------------------------------+

3. 零拷贝的硬件基础

io_uring 实现高性能的核心在于其与硬件的协同工作：

音频重采样

Mon, 01 Jan 0001 00:00:00 +0000

一、什么时候需要重采样

你的游戏/桌面采集的音频是 48000Hz，但推流到某个平台要求 44100Hz。
或者来源是 2 声道，平台要求 1 声道（混音）。

这时就需要音频重采样（resample）。

FFmpeg 提供 libswresample：
swr_init(src_rate, src_channels, src_fmt,
         dst_rate, dst_channels, dst_fmt)
→ 一次调用完成采样率转换 + 声道布局转换 + 格式转换

extern "C" {
#include <libswresample/swresample.h>
}

struct AudioResampler {
    SwrContext* swr = nullptr;

    bool init(int src_rate, int dst_rate, int channels) {
        swr = swr_alloc_set_opts(nullptr,
            dst_rate, AV_CH_LAYOUT_STEREO, AV_SAMPLE_FLT_FLTP,   // 输出
            src_rate, AV_CH_LAYOUT_STEREO, AV_SAMPLE_FLT_FLTP,   // 输入
            0, nullptr);
        return swr_init(swr) >= 0;
    }

    // 输入 AVFrame（src_format），输出转换后的 AVFrame
    AVFrame* resample(AVFrame* src) {
        AVFrame* dst = av_frame_alloc();
        dst->format = AV_SAMPLE_FLT_FLTP;
        dst->channel_layout = AV_CH_LAYOUT_STEREO;
        dst->sample_rate = dst_rate;
        dst->nb_samples = src->nb_samples;
        av_frame_get_buffer(dst, 0);

        swr_convert(swr,
                    dst->data, dst->nb_samples,
                    (const uint8_t**)src->data, src->nb_samples);

        return dst;
    }
};

预热、稳态与运行时长

Mon, 01 Jan 0001 00:00:00 +0000

5.2 预热、稳态与运行时长

上一节：5.1 单变量与对照组　|　下一节：5.3 重复、抖动与异常值配套代码：05-experiment-design/02-warmup-and-duration

一句话结论

压测时长不是拍出来的，是由「周期」决定的。 你必须至少覆盖一个完整的最长周期——GC 老年代回收周期、缓存 TTL、定时任务间隔、连接池回收周期。30 秒的压测结论只能当烟雾测试。

一、用「煮饭」理解预热与时长

煮一锅饭：

阶段	状态	对应
前 2 分钟	水还没开，米是硬的	冷启动：JIT 未编译、连接池空、缓存冷
中间 10 分钟	沸腾、米在吸水	过渡态：数据不能代表最终结果
最后 5 分钟	稳定收汁	稳态：可以判断饭好不好

三个关键推论：

「尝一口」不能判断饭好了没——你需要知道现在处于哪个阶段。
时间不够，饭就是生的——再好的米也没用。
不同米需要的时间不同——长粒米和短粒米不一样，就像不同应用需要的预热时间不同。

所以：预热时长要看「是否进入稳态」，运行时长要看「是否覆盖了所有周期性事件」。

二、预热：怎么判断「够了」

❌ 错误做法：固定预热 N 轮或 N 秒

「JMH 默认预热 5 轮，那就够了。」
「压测前先跑 60 秒预热。」

为什么错：不同应用需要的预热量差几十倍。一个启动加载 500 个类的应用，和一个 20 个类的工具，不可能同时进入稳态。

✅ 正确做法：看方差收敛（滚动 CV）

已在第 2 章 2.4 节详述。核心判据：

CV（变异系数）	判断
> 10%	明显没稳，继续预热
5% – 10%	接近稳态，再等等
< 5%	可以开始测量
< 2%	环境很干净，数据可信度高

同时要覆盖的四件事（JVM 之外还有）：

`noexcept` 与移动语义

Mon, 01 Jan 0001 00:00:00 +0000

一、为什么移动构造函数要加 noexcept？

struct Widget {
    Widget(Widget&& other) noexcept { /* 移动资源 */ }
    Widget& operator=(Widget&& other) noexcept { /* ... */ }
};

原因：std::vector 扩容时，如果移动构造是 noexcept，它用移动搬移旧元素到新内存。如果不是 noexcept，它只能用拷贝（因为拷贝抛异常时旧数组还在，移动抛异常时旧数组已被破坏）。

std::vector<Widget> v;
v.push_back(Widget{});  // 可能触发扩容

// 如果 Widget 的移动构造是 noexcept：
//   → 把旧元素 move 到新内存（指针交换，快）
// 如果 Widget 的移动构造不是 noexcept：
//   → 把旧元素 copy 到新内存（深拷贝，慢）

`perf c2c`——检测伪共享

Mon, 01 Jan 0001 00:00:00 +0000

一、什么时候用

你的多线程程序性能不随核心数线性提升，怀疑是伪共享（False Sharing）。

# 记录缓存行冲突
perf c2c record -F 99 ./my_program

# 查看报告
perf c2c report --stdio

# 输出示例：
# =================================================
#     Shared Data Cache Line Table
# =================================================
#  Total records       : 12345
#  Load records        : 8123
#  Store records       : 4222
#
#  Offset    Node    PA           Snoop    Cacheline
#  0x100     0       0x7f1234     HitM     0x7f1234
#  ↑ 这里有大量缓存行在核心间乒乓

对应代码中的伪共享：

struct Data {
    int a;  // 线程 1 频繁写
    int b;  // 线程 2 频繁写
    // a 和 b 在同一缓存行（64 字节），导致 RFO 在核心间乒乓
};

// 修复：用 alignas(64) 分开到不同缓存行
struct alignas(64) Data1 { int a; };
struct alignas(64) Data2 { int b; };

`std::bind` vs Lambda——选哪个？

Mon, 01 Jan 0001 00:00:00 +0000

上面用了 std::bind，其实用 Lambda 也可以：

// bind 写法
auto task = std::make_shared<std::packaged_task<ReturnType()>>(
    std::bind(std::forward<F>(f), std::forward<Args>(args)...)
);

// lambda 写法（C++17 起更推荐）
auto task = std::make_shared<std::packaged_task<ReturnType()>>(
    [f = std::forward<F>(f), ...args = std::forward<Args>(args)]() mutable {
        return std::invoke(std::move(f), std::move(args)...);
    }
);

Lambda 写法更直观，但注意 C++17 才支持 lambda 捕获参数包展开。面试用 std::bind 更不会出错。

`std::index_sequence` —— 破解"tuple 展开"问题

Mon, 01 Jan 0001 00:00:00 +0000

一、解决什么问题？

你有一个 tuple，想调用一个函数，参数就是这个 tuple 里的元素：

auto t = std::make_tuple(1, 2.0, "hello");
// 我想调用：func(1, 2.0, "hello")
// 但怎么写？不能写 func(t[0], t[1], t[2]) 因为 tuple 不能用 [] 下标

index_sequence 的答案：编译期生成 0, 1, 2, ..., N-1 这个序列，然后用包展开去 get tuple 的元素。

二、`std::apply` 的底层实现（搞懂这个就懂了 index_sequence）

// 1. 先生成 index_sequence<0, 1, 2>
// 2. 用 (get<I>(t))... 展开成 get<0>(t), get<1>(t), get<2>(t)

template <typename Func, typename Tuple, size_t... I>
auto apply_impl(Func&& f, Tuple&& t, std::index_sequence<I...>) {
    // I... = 0, 1, 2
    // get<I>(t)... = get<0>(t), get<1>(t), get<2>(t)
    return f(std::get<I>(std::forward<Tuple>(t))...);
}

template <typename Func, typename Tuple>
auto my_apply(Func&& f, Tuple&& t) {
    // tuple_size_v<Tuple> 得到元素个数，比如 3
    // make_index_sequence<3> → index_sequence<0, 1, 2>
    return apply_impl(
        std::forward<Func>(f),
        std::forward<Tuple>(t),
        std::make_index_sequence<std::tuple_size_v<std::decay_t<Tuple>>>{}
    );
}

my_apply([](int a, double b, const char* c) {
    std::cout << a << b << c;
}, t);
// 展开为：apply_impl(lambda, t, index_sequence<0, 1, 2>)
// → lambda(get<0>(t), get<1>(t), get<2>(t))
// → lambda(1, 2.0, "hello")

什么时候你会自己写这个？

`std::string_view` —— 字符串的"借用"视图

Mon, 01 Jan 0001 00:00:00 +0000

解决什么问题？

// ❌ 问题：把字符串切一段出来，就要分配内存
std::string full = "user:warren:logged_in";
std::string name = full.substr(5, 6);  // "warren" → 分配堆内存！

// ✅ string_view：只记录指针和长度，不拷贝
std::string_view full_sv = full;
std::string_view name_sv = full_sv.substr(5, 6);  // "warren" → 不分配！
// name_sv.ptr 指向 full 内部第 6 个字符的位置

什么时候用？

场景	用 string_view
函数参数，只读字符串	`void parse(std::string_view input)`——接受 `string`、`char*`、`string_view` 而不拷贝
子串提取，不需要修改	`sv.substr(pos, len)` 不分配内存
快速比较前缀/后缀	`sv.starts_with("http")` `sv.ends_with(".png")`
日志/消息解析	从大字符串中切出各字段而不拷贝

致命陷阱：生命周期

std::string_view get_name() {
    std::string temp = "temporary";
    return temp;  // ✅ 赋值时 temp 还活着
}  // ❌ temp 析构，sv 悬垂！

auto sv = get_name();
std::cout << sv;  // 💥 Use-After-Free！可能打印出乱码或 crash

规则：string_view 不拥有数据。你必须保证原始字符串活到 string_view 用完。

async-profiler：四类火焰图

Mon, 01 Jan 0001 00:00:00 +0000

4.3 async-profiler：四类火焰图

上一节：4.2 两类现象，两条路径　|　下一节：4.4 JFR 与 jcmd 配套代码：04-toolchain/03-async-profiler

一句话结论

async-profiler 是目前 JVM 上最好用的采样剖析器，它最大的价值是四种事件类型（cpu / alloc / lock / wall）——分别回答「谁在忙、谁在造垃圾、谁在抢锁、谁在干等」。只采 CPU 火焰图，等于只用了一个功能的四分之一。

一、用「X 光造影」理解四种事件

给病人做检查，不同的造影剂能看到不同的东西：

造影剂	看到什么	对应事件
看骨骼结构	硬组织的形态	`cpu`：谁在消耗 CPU
看血流	哪里堵住了	`wall`：谁在等待
看代谢活跃区	哪里在异常增生	`alloc`：谁在制造垃圾
看血管交叉点	哪里互相压迫	`lock`：谁在抢锁

关键：不同的病要用不同的造影剂。用看骨骼的 X 光去查血管堵塞，只会得到「没问题」。

二、四类事件的命令与用途

PID=$(jcmd | grep app.jar | awk '{print $1}')

# ① CPU：谁在消耗 CPU（现象：CPU 高）
asprof -d 60 -e cpu -f cpu.html "$PID"

# ② 墙上时间：时间都花在哪（现象：CPU 不高但慢）⭐ 最容易被忽略
asprof -d 60 -e wall -f wall.html "$PID"

# ③ 分配：谁在制造垃圾（现象：GC 频繁、分配速率高）
asprof -d 60 -e alloc -f alloc.html "$PID"

# ④ 锁：谁在抢锁（现象：吞吐上不去、sys CPU 高）
asprof -d 60 -e lock -f lock.html "$PID"

asprof 是 async-profiler 3.x 的启动器名（旧版本叫 profiler.sh，2.x 也支持 asprof 别名）。如果你的版本较老，把 asprof 换成 ./profiler.sh。

C++11 内存序（Memory Order）的三大流派

Mon, 01 Jan 0001 00:00:00 +0000

这个问题是你打通硬件屏障之后，迈向高性能并发编程的临门一脚！

如果说 std::atomic 是C++发给你的“手枪”，那内存序（Memory Order）就是这把手枪的扳机力度。用对了，精准击杀（高性能）；用错了，走火入魔（Bug丛生）。

我们结合上一阶段讲的Store Buffer和Invalidation Queue，来看看C++11是如何把这三种“硬件武器”抽象成三个编程模型的。

核心认知：为什么要分流派？

底层硬件（ARM/RISC-V）是弱内存序（允许乱序），x86是强内存序（仅允许写-读乱序）。如果C++只提供一种“全围栏”（seq_cst），那在ARM上性能会崩塌。所以，C++11的策略是：“你（程序员）懂硬件，你就用轻量的；你不懂，就用最重的但最安全的。”

流派一：`memory_order_relaxed`（彻底放飞）

口头禅：“只保证原子性，不保证可见性，不保证顺序。”

编译器行为：不插入任何内存屏障（mfence/dmb）。CPU可以随便重排，编译器也可以随便优化。
硬件行为：允许Store Buffer延迟可见，允许Invalidation Queue堆积。

典型应用：纯计数器（比如统计QPS）。线程A加1，线程B加1，我们只关心最终累加结果，不关心A和B谁先看到谁。

std::atomic<int> counter{0};

void worker() {
    // 极度轻量，在x86上直接编译为 lock xadd（无额外屏障）
    // 在ARM上只编译为 LDXR/STXR 循环，不插入 dmb 屏障
    counter.fetch_add(1, std::memory_order_relaxed); 
}

翻车示例（千万不要这样用！）：

std::atomic<bool> ready{false};
int data = 0;

void producer() {
    data = 42;                     // 普通写（可能被重排到后面！）
    ready.store(true, std::memory_order_relaxed); // 彻底放飞
}
void consumer() {
    while(!ready.load(std::memory_order_relaxed)); // 看到true了，但data可能还是0！
    assert(data == 42); // 💥 断言失败！data的写入可能还在Store Buffer里没出来！
}

流派二：`acquire-release` 黄金搭档（精准半边墙）

这是工业界最常用的高性能并发模型！ 它理解硬件的本质：Store Buffer需要冲刷，Invalidation Queue需要清空。

CPU 指令级优化（SIMD / 预取）

Mon, 01 Jan 0001 00:00:00 +0000

这是从**“算法对”到“代码跑得快”的最后一公里。你之前学的都是宏观架构**（缓存、内存、调度），而 SIMD 和预取是微观指令级的优化——让 CPU 的每个流水线周期都塞满有用的工作。

1. SIMD（单指令多数据流）：一条指令干一堆活

什么是 SIMD？

SIMD（Single Instruction, Multiple Data）是 CPU 的并行处理扩展，允许一条指令同时对多个数据执行相同的操作。

标量（Scalar）：一条指令处理一个数据
+--------+     +--------+
| ADD R1 | --> |  A + B  |  (1 次操作)
+--------+     +--------+

SIMD（向量化）：一条指令处理 N 个数据
+--------+     +--------+--------+--------+--------+
| ADD ZMM | --> | A1+B1  | A2+B2  | A3+B3  | A4+B4  |  (4 次操作，1 条指令)
+--------+     +--------+--------+--------+--------+

硬件实现（x86 / ARM 的 SIMD 单元）

架构	指令集	寄存器宽度	同时处理数据量（单精度浮点）
x86 (Intel/AMD)	SSE	128-bit	4 个 float
x86 (Intel/AMD)	AVX2	256-bit	8 个 float
x86 (Intel/AMD)	AVX-512	512-bit	16 个 float
ARM (手机/服务器)	NEON	128-bit	4 个 float
ARM (服务器)	SVE2	可变（最高 2048-bit）	可变

硬件结构：

Helgrind / DRD —— 数据竞争检测

Mon, 01 Jan 0001 00:00:00 +0000

一、Valgrind 的 TSan 替代方案

之前讲过 ThreadSanitizer 能检测数据竞争，但需要重编译。如果你有一个已经编译好的二进制（或者第三方库没源码），可以用 Helgrind 或 DRD 做运行时数据竞争检测。

# Helgrind（更详细，但更慢）
valgrind --tool=helgrind ./my_multithread_program

# DRD（更快一点，但可能漏报）
valgrind --tool=drd ./my_multithread_program

二、输出示例

#include <thread>
#include <iostream>

int counter = 0;  // 没有锁保护

void worker() {
    for (int i = 0; i < 100000; i++) {
        counter++;  // 数据竞争！
    }
}

int main() {
    std::thread t1(worker);
    std::thread t2(worker);
    t1.join();
    t2.join();
    std::cout << counter << std::endl;
    return 0;
}

valgrind --tool=drd ./race

# 输出：
# DRD: data race on address 0x601050 in object 'counter'
#   Conflicting store by thread 1 at 0x400B34: worker() race.cpp:6
#   Conflicting load by thread 2 at 0x400B38: worker() race.cpp:6
#   Allocation context: BSS section of /tmp/race

三、Helgrind vs DRD vs TSan

工具	是否需要重编译	运行速度	精确度
TSan（-fsanitize=thread）	需要	慢 5-10x	高
DRD（valgrind）	不需要	慢 20-30x	中
Helgrind（valgrind）	不需要	慢 20-30x	高

实际选择：
  如果你有源码：用 -fsanitize=thread（最快最准）
  如果你只有二进制：用 DRD 或 Helgrind
  Helgrind 的报错比 DRD 详细，但慢一点

MPMC (多写多读) 与工业级无锁队列（如 LMAX Disruptor）

Mon, 01 Jan 0001 00:00:00 +0000

欢迎来到并发编程的“诸神之战”——MPMC（Multi-Producer Multi-Consumer）。

这是并发领域最难啃的骨头，也是区分“普通程序员”和“系统架构师”的分水岭。你之前的 SPSC 是“单行道”，MPSC 是“多入口单出口”，而 MPMC 是**“多入口多出口的疯狂立交桥”**。

要把 MPMC 写好，靠 CAS 硬刚是不行的，那会让 CPU 缓存行“炸裂”。我们需要引入工业级杀器：LMAX Disruptor（无锁环形缓冲区）。

1. MPMC 的“两头肉搏”到底有多痛？

在 MPMC 中，所有生产者和消费者都盯着同一个头指针（Head）和同一个尾指针（Tail）。

生产者肉搏：N 个生产者疯狂 CAS 抢 Head（分配槽位）。每次 CAS 都是 RFO（Read For Ownership），导致 Head 所在的缓存行在 N 个核心间“乒乓”。
消费者肉搏：M 个消费者疯狂 CAS 抢 Tail（消费进度）。同样导致缓存行在 M 个核心间“乒乓”。
头尾互搏：更恐怖的是，Head 和 Tail 如果在同一个缓存行（False Sharing），生产者抢 Head 还会顺便把 Tail 的缓存行弄脏，直接拖垮消费者。

结果：吞吐量随着核心数增加不升反降，延迟飙升到微秒级。

2. 顶级框架 LMAX Disruptor 的“核心理念”

LMAX 是金融交易系统（每秒处理 600 万笔订单），它解决 MPMC 的思路极其高明，核心就两招：

干掉竞争（CAS）：用顺序分配 + 栅栏（Barrier）代替互斥。生产者不抢同一个指针，而是各自申请一段连续的空间。
干掉伪共享：缓存行填充（Cache Line Padding），让 Head、Tail、Cursor 老死不相往来。

3. 核心机制：申请（Claim）与发布（Publish）

Disruptor 不直接操作指针，而是通过序号（Sequence）：

YUV 在内存中的布局

Mon, 01 Jan 0001 00:00:00 +0000

一、两种主流布局：Planar vs Semi-Planar

这是 C++ 处理视频时最常搞错的地方。FFmpeg、OpenCV、硬件编码器返回的 YUV 数据格式不同。

YUV420P（Planar）— FFmpeg 的默认格式 av_pix_fmt_yuv420p
  内存：YYYYYYYYYYYYYYYY...UUUUUUUU...VVVVVVVV
        [全部 Y 行]  [全部 U 行]  [全部 V 行]

  索引：
  Y 平面：data[0], linesize[0] = width
  U 平面：data[1], linesize[1] = width/2
  V 平面：data[2], linesize[2] = width/2

  获取像素 (x,y) 的 Y/U/V：
  y = data[0][y * linesize[0] + x]
  u = data[1][y/2 * linesize[1] + x/2]
  v = data[2][y/2 * linesize[2] + x/2]

NV12（Semi-Planar）— 硬件编码器的默认格式（Intel QSV、VideoToolbox、MPP）
  内存：YYYYYYYYYYYYYYYY...UVUVUVUVUV
        [全部 Y 行]  [UV 交错排列]

  Y 平面：data[0], linesize[0] = width
  UV 平面：data[1], linesize[1] = width（UV 交替，每个 U/V 各 1 byte）
  注意：linesize[1] 是 width 而不是 width，因为 UV 交织在一起

  获取像素 (x,y) 的 Y/U/V：
  y = data[0][y * linesize[0] + x]
  uv_index = (y/2) * linesize[1] + (x/2) * 2
  u = data[1][uv_index]
  v = data[1][uv_index + 1]

二、手写 YUV420P ↔ NV12 转换

这两个格式之间互相转换是音视频开发者的基本功：

串行 I/P 帧与编码效率模拟

Mon, 01 Jan 0001 00:00:00 +0000

#include <vector>
#include <cstdint>
#include <cstdlib>

// 模拟一个非常简化的视频编码器
// 只编码 I 帧和 P 帧（无 B 帧），观察不同场景下的压缩效率

class SimpleEncoder {
    int width_, height_;
    std::vector<uint8_t> reference_;  // 参考帧
    int keyframe_interval_;           // 每隔几帧插一个 I 帧
    int frame_count_ = 0;

    // "运动估计"：在参考帧中搜索最匹配的 8x8 块
    struct MotionVector { int dx, dy; };
    MotionVector search_block(const uint8_t* cur, const uint8_t* ref,
                               int bx, int by, int search_range = 16) {
        int best_cost = INT_MAX;
        MotionVector best = {0, 0};

        for (int dy = -search_range; dy <= search_range; dy++) {
            for (int dx = -search_range; dx <= search_range; dx++) {
                int cost = 0;
                for (int y = 0; y < 8; y++) {
                    for (int x = 0; x < 8; x++) {
                        int cur_px = cur[(by + y) * width_ + (bx + x)];
                        int ref_px = ref[(by + y + dy) * width_ + (bx + x + dx)];
                        cost += abs(cur_px - ref_px);
                    }
                }
                if (cost < best_cost) {
                    best_cost = cost;
                    best = {dx, dy};
                }
            }
        }
        return best;
    }

public:
    SimpleEncoder(int w, int h, int keyframe_interval)
        : width_(w), height_(h), reference_(w * h), keyframe_interval_(keyframe_interval) {
        std::fill(reference_.begin(), reference_.end(), 128);
    }

    struct EncodedFrame {
        bool is_keyframe;
        size_t data_size;  // 编码后的估计大小
    };

    EncodedFrame encode(const uint8_t* frame) {
        frame_count_++;
        EncodedFrame ef;

        if (frame_count_ % keyframe_interval_ == 1) {
            // I 帧：完整存储（模拟 JPEG 级压缩，约 1/3 原大小）
            ef.is_keyframe = true;
            ef.data_size = width_ * height_;  // 简化：算 1:1
            memcpy(reference_.data(), frame, width_ * height_);
        } else {
            // P 帧：只存运动向量 + 残差
            ef.is_keyframe = false;
            size_t motion_data = 0;
            size_t residual_data = 0;

            for (int y = 0; y < height_; y += 8) {
                for (int x = 0; x < width_; x += 8) {
                    auto mv = search_block(frame, reference_.data(), x, y);
                    // 运动向量：8 位够存 dx, dy
                    motion_data += 2;

                    // 残差：用绝对差和估计
                    for (int by = 0; by < 8; by++) {
                        for (int bx = 0; bx < 8; bx++) {
                            int cur_px = frame[(y + by) * width_ + (x + bx)];
                            int ref_px = reference_[(y + by + mv.dy) * width_ + (x + mv.dx + bx)];
                            residual_data += abs(cur_px - ref_px) < 8 ? 0 : 1;
                        }
                    }
                }
            }
            ef.data_size = motion_data + residual_data;
            memcpy(reference_.data(), frame, width_ * height_);
        }

        return ef;
    }
};

void test_encoder_scenarios() {
    const int W = 64, H = 48;
    SimpleEncoder encoder(W, H, 30);

    // 场景 1：静态画面（摄像头静止）
    std::vector<uint8_t> static_frame(W * H, 128);

    // 场景 2：快速运动（画面整体右移）
    std::vector<uint8_t> motion_frame(W * H);
    for (int y = 0; y < H; y++)
        for (int x = 0; x < W; x++)
            motion_frame[y * W + x] = (x + y * 3) % 256;

    printf("静态场景编码（30 帧）:\n");
    for (int i = 0; i < 30; i++) {
        auto ef = encoder.encode(static_frame.data());
        printf("  帧 %2d: %s, size=%zu\n", i + 1,
               ef.is_keyframe ? "I" : "P", ef.data_size);
    }

    // 重置编码器
    SimpleEncoder motion_enc(W, H, 30);
    printf("\n动态场景编码（30 帧，每帧整体右移 1 像素）:\n");
    for (int i = 0; i < 30; i++) {
        // 模拟画面平移
        for (int y = 0; y < H; y++)
            for (int x = 0; x < W; x++)
                motion_frame[y * W + x] = (x + i + y * 3) % 256;

        auto ef = motion_enc.encode(motion_frame.data());
        printf("  帧 %2d: %s, size=%zu\n", i + 1,
               ef.is_keyframe ? "I" : "P", ef.data_size);
    }
}

测试结果的意义：

你的 SimpleAsyncLogger 可以做这样的 benchmark

Mon, 01 Jan 0001 00:00:00 +0000

#include <benchmark/benchmark.h>
#include "logger.h"  // 你的日志库

static void BM_Logger_Write(benchmark::State& state) {
    logger_init("./bench.log", LOG_LEVEL_INFO);
    const char* msg = "benchmark test message %d";

    for (auto _ : state) {
        logger_write(LOG_LEVEL_INFO, msg, state.iterations());
        benchmark::DoNotOptimize(msg);
    }

    logger_destroy();
}
BENCHMARK(BM_Logger_Write)->Iterations(100000);

// 对比 spdlog
#include <spdlog/spdlog.h>
static void BM_Spdlog_Write(benchmark::State& state) {
    auto logger = spdlog::basic_logger_mt("bench", "./spdlog_bench.log");

    for (auto _ : state) {
        logger->info("benchmark test message {}", state.iterations());
    }
}
BENCHMARK(BM_Spdlog_Write)->Iterations(100000);

BENCHMARK_MAIN();

// 编译：
// g++ -O2 -I./include -L./lib -lsalogger -lspdlog -lbenchmark -o bench bench.cpp

// 预期结果：
// --------------------------------------------------------------------
// Benchmark                        Time    CPU      Iterations
// --------------------------------------------------------------------
// BM_Logger_Write                 52 ns  51 ns      100000   ← 你的日志库
// BM_Spdlog_Write                520 ns 518 ns      100000   ← spdlog
//
// 52ns vs 520ns，你的日志库快 10 倍。
// 这就是"我做了性能对比，我的方案比主流的快 10 倍"——面试时可以拿出来的数字。

全局队列 vs Work-Stealing 对比

Mon, 01 Jan 0001 00:00:00 +0000

对比	全局队列	Work-Stealing
实现复杂度	简单	复杂
每个任务的取队列开销	1 次锁争用	极少争用（自己队列无竞争）
负载均衡	自然均衡（谁抢到谁做）	需要偷取来均衡
缓存局部性	差（任务被随机线程执行）	好（自己入队的任务自己执行）
适用场景	任务执行时间不固定	任务短小、频率高

什么时候用 Work-Stealing？

你的 SimpleAsyncLogger 那种场景——生产者线程写入日志（微任务），刷盘线程消费——是 SPSC，不需要 Work-Stealing。Work-Stealing 真正有用的是计算密集型的、任务大量且短小的并行计算，比如浏览器渲染引擎（Chromium 的 Blink 线程池就是 Work-Stealing）。

全链路性能门禁

Mon, 01 Jan 0001 00:00:00 +0000

8.3 全链路性能门禁

上一节：8.2 CI 微基准门禁　|　下一节：8.4 生产观测：SLI 与错误预算配套代码：08-continuous-performance/03-e2e-perf-gate

一句话结论

全链路门禁成本高、噪声大，所以它不该出现在每个 PR 上。 正确的定位是：发布前的最后一道验收——用专用环境、固定机器、触发式运行。

一、用「飞机试飞」理解全链路门禁

汽车出厂前会做路试，但不会每装一个零件就上路试一次。路试的时机是：

时机	目的
每个零件装好后	台架试验（对应微基准）
整车装配完成	转鼓试验（对应集成基准）
出厂前	路试（对应全链路门禁）
上市后	用户反馈 + 定期检查（对应生产告警）

全链路门禁的定位就是「出厂前路试」——不是每次都做，但发布前必做。

二、什么时候跑全链路门禁

触发时机	是否合适	理由
每个 PR	❌ 不合适	成本太高（几十分钟），噪声大，会拖慢开发
主干合并后	⚠️ 可以	比 PR 好，但仍是高频
发布候选（RC）	✅ 推荐	发布前的最后一道门
每日夜间	✅ 推荐	与发布解耦，能发现趋势
手动触发	✅ 推荐	用于验证重大改动

推荐组合：

① 主干合并后：跑【微基准门禁】（分钟级）
② 每日夜间：跑【全链路回归】（发现趋势退化）
③ 发布候选：跑【全链路门禁 + 容量复测】（发布前验收）
④ 重大架构改动：手动触发

三、全链路门禁的三个必要条件

条件一：专用环境

不能在共享的 CI runner 上跑全链路压测。

写时复制（Copy-on-Write）

Mon, 01 Jan 0001 00:00:00 +0000

一、场景

你有大量对象共享同一份数据。大部分操作只是读数据，偶尔写。如果每次拷贝都深复制一份，浪费内存和 CPU。

COW 的思路：读操作共享同一份数据，写操作才复制。

class SharedBuffer {
    struct Data {
        std::vector<char> buf;
        int ref_count = 1;
    };

    Data* data_;

public:
    SharedBuffer() : data_(new Data()) {}

    // 浅拷贝：共享同一个 Data
    SharedBuffer(const SharedBuffer& other)
        : data_(other.data_) {
        data_->ref_count++;
    }

    ~SharedBuffer() {
        if (--data_->ref_count == 0) {
            delete data_;  // 最后一个引用才释放
        }
    }

    // 读操作：共享，不需要复制
    const char* read() const {
        return data_->buf.data();
    }

    // 写操作：先检查引用计数，如果共享了就要复制
    char* write() {
        if (data_->ref_count > 1) {
            // 有人在共享，先复制一份
            Data* new_data = new Data(*data_);
            new_data->ref_count = 1;
            data_->ref_count--;
            data_ = new_data;
        }
        return data_->buf.data();
    }
};

二、面试追问 Q&A

Q1：std::string 为什么 C++11 后不再用 COW？ A：COW 在多线程下有严重问题。判断"是否共享"需要原子操作，且 operator[] 返回的引用可能被用作写操作，但你无法在返回引用时复制。C++11 起标准要求 operator[] 是 $O(1)$ 且不修改 this，所以 COW 被 SSO（Short String Optimization）替代了。

四、参考代码：亲自手写验证 Demo

Mon, 01 Jan 0001 00:00:00 +0000

请在一个独立的 01_value_types.cpp 中手写并运行以下代码（使用 g++ 01_value_types.cpp -o value_types 编译）。这个 Demo 会用最直观的编译行为，向你展示编译器对这几种值类型的精准判定。

#include <iostream>
#include <string>
#include <utility>

// 重载函数 A：专门接收左值
void GetValueType(int& lref) {
    std::cout << "🧱 编译器判定：这是一个【左值 lvalue】(有固定内存地址)\n";
}

// 重载函数 B：专门接收右值（包括纯右值和将亡值）
void GetValueType(int&& rref) {
    std::cout << "🚀 编译器判定：这是一个【右值】(无地址的纯右值 或 允许被压榨的将亡值)\n";
}

int GetTemporaryInt() {
    return 100; // 返回一个临时值（纯右值）
}

int main() {
    std::cout << "--- 开始 C++11 值类型硬核验证 ---\n\n";

    // 1. 验证左值
    int x = 42; 
    GetValueType(x); // x 是个正经变量，有名字，能取地址 &x ➔ 触发左值重载

    // 2. 验证纯右值 (prvalue)
    GetValueType(42);                // 42 是字面量，没名字没地址 ➔ 触发右值重载
    GetValueType(GetTemporaryInt()); // 函数返回的临时 100，算完就消失 ➔ 触发右值重载

    // 3. 验证将亡值 (xvalue)
    // std::move 并没有移动任何东西，它的本质就是把左值 x，强制类型转换成【将亡值】！
    // 告诉编译器：“这个 x 我以后不用了，它马上要死了，你可以随时移走它的资源！”
    GetValueType(std::move(x)); // 强转出来的将亡值 ➔ 触发右值重载

    // 4. 深度思考：右值引用变量本身，是什么值？
    int&& ref = 100; // ref 是一个右值引用，绑定了右值 100
    
    // 🚨 思考：把 ref 传给 GetValueType，会触发哪个？
    // 答案是左值！因为 ref 这个“名字”本身是一直持久存在的，你能对 &ref 取地址！
    std::cout << "\n【终极陷阱测试】: ";
    GetValueType(ref); // ➔ 触发左值重载！

    return 0;
}

四、四个最常用的标准 Concepts

Mon, 01 Jan 0001 00:00:00 +0000

// 1. std::same_as —— 精确类型匹配
// 用于需要精确匹配的 API
void process(std::same_as<int> auto x);  // 只接受 int，不接受 long

// 2. std::convertible_to —— 可隐式转换
// 用于返回值约束
{ func() } -> std::convertible_to<int>;  // func 的返回值可以被赋给 int

// 3. std::invocable —— 可调用对象
// 用于接受回调的泛型函数
template <std::invocable<int, double> F>
void register_callback(F&& callback);    // F 必须是 f(int, double) 这种签名

// 4. std::range —— 容器/范围
// 替代传统 iterator pair
template <std::range R>
void sort_all(R& r);                     // 接受 vector, list, array, span...

四、惰性求值为什么快？——底层原理

Mon, 01 Jan 0001 00:00:00 +0000

auto pipeline = data
    | std::views::filter([](int x) { return x % 2 == 0; })
    | std::views::transform([](int x) { return x * 10; })
    | std::views::take(3);

for (int x : pipeline) {
    std::cout << x;
}

for 循环中每次迭代发生了什么：

第 1 次迭代：
  take 问 transform："给我下一个值"
  transform 问 filter："给我下一个值"
  filter 问 data："给我下一个值"
  data 给 filter：1 → filter 检查 1%2==0？→ false → "跳过，下一个"
  data 给 filter：2 → filter 检查 2%2==0？→ true → 把 2 给 transform
  transform 计算 2*10=20 → 把 20 给 take
  take 计数 1/3 → 把 20 吐给 for 循环
  cout << 20

第 2 次迭代：
  take 问 transform：再给我一个
  transform 问 filter：再给我一个
  data 给 filter：3 → false → 跳过
  data 给 filter：4 → true → transform → 40 → take(2/3) → cout

第 3 次迭代：
  同样得到 60 → 输出
  take 计数到达 3 → 告诉 for："结束了"

总共遍历了 data 的前 6 个元素（到 6），而非全部 data。

关键：每次只处理一个元素通过整个管道，管道中的每个"站"都是按需工作。最坏情况下只遍历 data 一遍。

四、第八阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

分配器的本质：
    把 "分配内存" 和 "构造对象" 分离
    让 reserve 只分配不构造、pop_back 只析构不释放

Arena（monotonic_buffer_resource）：
    分配：指针加偏移（2ns）
    释放：整块释放（不逐个 delete）
    适用：生命周期整齐、高频分配的场景

PMR 的三种 resource：
    monotonic：纯 Arena，最快
    unsynchronized_pool：可释放单个
    synchronized_pool：线程安全版

价值：高频小对象场景加速 10-50 倍

并发与并行：加资源不等于变快

Mon, 01 Jan 0001 00:00:00 +0000

7.3 并发与并行：加资源不等于变快

上一节：7.2 减少工作　|　下一节：7.4 缓存配套代码：07-optimization-and-validation/03-concurrency-and-parallelism

一句话结论

并行化的收益有上限，而且过了某个点就变成负的。 原因是：并行需要共享资源（CPU、数据库、下游），而共享资源会排队。所以「加线程/协程」不是免费的加速——它常常只是把瓶颈从应用层转移到下游。

一、用「超市收银台」理解并行的上限

超市有 8 个收银台（= CPU 核数）。顾客排队结账。

做法	结果
开 4 个台	队伍较长
开 8 个台	最优（与核数匹配）
开 16 个台	收银员互相挤，通道拥堵 → 反而更慢
开 100 个台	完全没有空间，无法工作

关键洞察：收银员多了，但超市的物理空间、仓库补货能力没变——瓶颈转移了。

后端完全一样：

加了 2 倍线程 → 应用能并发处理 2 倍请求
但数据库只有那么多连接和处理能力
→ 请求全部堵在数据库前面
→ 整体更慢（因为锁竞争 + 上下文切换 + 数据库过载）

二、并行的三种正确用法

❶ 对 IO 密集操作：用协程，但要限制并发

// ❌ 无限制：10 万个协程全打到下游
suspend fun fetchAll(ids: List<Long>) = coroutineScope {
    ids.map { async { httpGet(it) } }.awaitAll()
}

// ✅ 限制并发（保护下游，也保护自己）
private val limiter = Semaphore(64)
suspend fun fetchAll(ids: List<Long>) = coroutineScope {
    ids.map { id -> async { limiter.withPermit { httpGet(id) } } }.awaitAll()
}

// ✅ 或按批次（更可控）
suspend fun fetchAllBatched(ids: List<Long>, batch: Int = 64) =
    ids.chunked(batch).flatMap { chunk ->
        coroutineScope { chunk.map { async { httpGet(it) } }.awaitAll() }
    }

为什么要限制：你是下游的客户端，你的并发就是下游的负载。 无限制的并发 = 对下游的 DDoS。

延迟是分布，不是数字

Mon, 01 Jan 0001 00:00:00 +0000

0.3 延迟是分布，不是数字

上一节：0.2 吞吐、延迟、成本的三方权衡　|　下一节：0.4 用 Little’s Law 估算容量配套代码：00-introduction/03-latency-distribution 动手：建议先跑一遍配套代码，本节的两个现象都能亲眼看到。

一句话结论

「这个接口的平均延迟是 11 ms」这句话，可能同时意味着「99% 的人只等了 1 ms」和「1% 的人等了整整 1 秒」。 后端必须看延迟的分布，尤其是尾部。

一、一个 100 个请求的数字游戏

假设你的接口收到了 100 个请求：

99 个请求很快，各花了 1 ms；
1 个请求很慢，花了 1000 ms（比如遇到了 GC 停顿或数据库锁等待）。

现在计算平均值：

总耗时 = 99 × 1 ms + 1 × 1000 ms = 1099 ms
平均延迟 = 1099 / 100 ≈ 11 ms

报出去的数是 11 ms。听起来很棒，对吧？

但对那 1 个用户来说，他结结实实地等了 1 秒。如果这个接口一天被调用 100 万次，那就是一万个用户每天遇到「卡了一秒」。

微基准四大陷阱

Mon, 01 Jan 0001 00:00:00 +0000

2.3 微基准四大陷阱

上一节：2.2 JIT 的三大优化与去优化　|　下一节：2.4 预热、稳态与冷启动配套代码：02-jvm-performance-basics/03-microbenchmark-traps

一句话结论

你写的基准测试，最大的对手不是机器噪声，而是优化器。 它会把你的计算整个删掉、提前算好、或者把你的分支预测喂得太好。四个陷阱里，任何一个都会让你的数字变成废纸。

一、陷阱一：死代码消除（DCE）—— 算了但没人用，那就不算

现象：测出 0.2 ns/op 这种物理上不可能的数字。

原因：计算的结果没有被使用，JIT 判断「这个计算没有副作用」，于是把整个循环删掉了。你测的是一个空循环。

// ❌ 结果没人用 → 整个计算被删除
repeat(100_000) {
    sumArray(data)          // 返回值丢掉了
}

// ✅ 结果被消费 → 计算保留
var sink = 0L
repeat(100_000) {
    sink += sumArray(data)
}
println(sink)               // 确保 sink 真的被使用，否则它也可能被优化掉

为什么难发现：代码看起来「明明在算」，而且跑得飞快——你会以为是好事。

判断方法：把数据规模改成 10 倍，如果耗时完全不变，说明计算被删了。

二、陷阱二：常量折叠 —— 输入是已知的，那就提前算好

现象：数字看起来合理，但与输入规模无关。

原因：输入在编译期就能确定（比如字面量、const），JIT 直接在编译时把结果算出来。

// ❌ 输入是编译期常量 → 结果被提前算好
val data = IntArray(4096) { it }          // 规律数据，JIT 能推导
repeat(100_000) { sink += sumArray(data) }

// ✅ 输入在运行时才确定
val rnd = Random(System.nanoTime())        // 真正的运行时随机
val data = IntArray(4096) { rnd.nextInt() }

注意：即使数据是「运行时生成的」，如果生成方式是 { it } 或 { it * 2 } 这类规律模式，JIT 仍可能利用这个规律（比如识别出等差数列直接套公式）。

排序算法选择策略

Mon, 01 Jan 0001 00:00:00 +0000

一、`std::sort` 内部实现

std::sort 不是单纯的快排，而是内省排序：

// 伪代码
void sort(iterator first, iterator last) {
    if (last - first < 16) {
        insertion_sort(first, last);  // 小数组用插入排序
        return;
    }

    int depth_limit = 2 * log2(last - first);

    intro_sort_loop(first, last, depth_limit);
    // 如果 depth_limit 达到 0，说明快排退化，切换到堆排序
}

void intro_sort_loop(iterator first, iterator last, int depth) {
    while (last - first > 16) {
        if (depth == 0) {
            make_heap(first, last);      // 切换到堆排序
            sort_heap(first, last);
            return;
        }
        depth--;
        iterator cut = partition(first, last);  // 快排分区
        intro_sort_loop(cut + 1, last, depth);  // 递归大的一边
        last = cut;  // 尾递归处理小的一边
    }
}

组合策略：快排（通用最快）+ 堆排（退化保护）+ 插入排序（小数组最优）。

条件断点

Mon, 01 Jan 0001 00:00:00 +0000

// 一个循环中的 Bug：第 1000 次才出现
void process_data(std::vector<int>& data) {
    for (int i = 0; i < data.size(); i++) {
        // 只有在 i = 1000 时才崩溃
        if (i == 1000) {
            data[i] = data[2000];  // 如果 data 不够大就越界了
        }
    }
}

# ❌ 普通断点：要手动按 1000 次 continue
(gdb) break process_data

# ✅ 条件断点：直接停在崩溃的那次循环
(gdb) break process_data if i == 1000
(gdb) run
Breakpoint 1, process_data at main.cpp:15
(gdb) print data.size()          # 查看是否越界
$1 = 1500                        # size = 1500 < 2000，越界了！

线程条件断点：

步骤二：搭服务与数据

Mon, 01 Jan 0001 00:00:00 +0000

9.3 步骤二：搭服务与数据

上一节：9.2 步骤一：定义目标　|　下一节：9.4 步骤三：建立基线与噪声底线用到：第 3 章（组件基准、真实依赖）、第 5.5 节（数据集设计）配套代码：09-capstone/03-step2-build-service 产出：可运行的服务 + 一键起环境脚本 + 100 万行数据

一句话结论

这一步的目标不是"写出好代码"，而是"写出一个能被测量的系统"——它必须有真实的依赖、固定的数据、可观测的指标，以及故意保留的埋雷。

一、服务的四层结构

HTTP 层（Ktor 路由）
  ↓
Service 层（业务逻辑：生成短码、缓存编排）
  ↓
Repository 层（数据访问：PostgreSQL + Redis）
  ↓
基础设施（HikariCP 连接池、Redis 客户端）

每一层对应的埋雷：

层	埋雷	说明
HTTP 层	⑤ 日志同步 IO	每个请求打 INFO 日志
Service 层	⑥ `synchronized` 生成 code	锁 + 可能在协程里
Repository 层	① 无唯一索引、② 每次 UPDATE、④ Default 上 JDBC	数据访问的三个问题
缓存	③ TTL 无抖动	服务层与缓存层交界处

二、一键起环境

# docker-compose.yml
services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: shortlink
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app
    ports: ["5432:5432"]
    command:
      - postgres
      - -c max_connections=100
      - -c shared_buffers=256MB
      - -c log_min_duration_statement=200ms     # 慢查询日志（辅助定位）
    volumes:
      - pg-data:/var/lib/postgresql/data
      - ./init.sql:/docker-entrypoint-initdb.d/init.sql:ro
      - ./seed.sql:/docker-entrypoint-initdb.d/seed.sql:ro
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d shortlink"]
      interval: 2s
      timeout: 3s
      retries: 30

  redis:
    image: redis:7-alpine
    ports: ["6379:6379"]
    command: redis-server --maxmemory 512mb --maxmemory-policy allkeys-lru
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 2s

  # 观测栈（第 4 章）
  prometheus:
    image: prom/prometheus:v2.54.1
    ports: ["9090:9090"]
    volumes:
      - ./observability/prometheus.yml:/etc/prometheus/prometheus.yml:ro

  grafana:
    image: grafana/grafana:11.2.0
    ports: ["3000:3000"]
    environment:
      GF_SECURITY_ADMIN_PASSWORD: admin

volumes:
  pg-data:

关键配置：

测量点：同一个请求，三个不同的数字

Mon, 01 Jan 0001 00:00:00 +0000

1.3 测量点：同一个请求，三个不同的数字

上一节：1.2 百分位不可平均　|　下一节：1.4 SLO 的四要素写法配套代码：01-metrics-and-slo/03-measurement-points

一句话结论

「这个接口要 200 ms」这句话，缺了最重要的一个信息：在哪测的。 客户端测出 200 ms、网关测出 120 ms、服务端 handler 内部测出 30 ms——三个数字都是对的，但它们回答的是不同的问题。混着用，就会得出错误结论。

二、用快递物流理解「测量点」

你在网上买了一件商品，想知道「多久能到」。可以打卡的地方有很多：

打卡点	记录的时间	用户关心吗
你下单的时刻	起点	✅ 用户从这里开始等
仓库开始打包	分拣耗时	❌ 用户不关心，但仓管关心
打包完成、交给快递	打包耗时	❌ 但能定位「是不是仓库慢」
快递在路上	运输耗时	部分关心
快递到达你所在城市	分拨耗时	❌
快递员按门铃、你签收	终点	✅ 用户等的是这个

「送达需要 3 天」这句话：

从「下单」算：3 天。这是用户体验。
从「出库」算：2.5 天。这是物流公司内部的绩效。
从「到达本市」算：6 小时。这是末端配送的效率。

三个数字都对，但你不能拿「末端配送 6 小时」去论证「用户 3 天能收到」。

后端的测量点完全同理。

三、三个测量点

3.1 客户端（压测工具 / 真实用户浏览器 / App）

延迟 = 收到响应的时刻 − 发出请求的时刻

包含：客户端排队 + 网络往返 + 网关 + 服务排队 + 服务处理 + 响应传输。

火焰图读法

Mon, 01 Jan 0001 00:00:00 +0000

6.3 火焰图读法

上一节：6.2 延迟分解　|　下一节：6.4 线程与协程快照配套代码：06-analysis-and-profiling/03-flamegraph-reading 工具用法见第 4 章 4.3；本节讲怎么读。

一句话结论

火焰图是一张「时间面积图」，不是调用顺序图。 横轴是采样数（≈ 时间占比），纵轴是调用栈深度。看宽度找大头，看叶子找自己耗时的函数，两张图对照找真相。

一、用「地图」理解火焰图

火焰图像一张地图：

地图	火焰图
面积 = 实际占地	宽度 = 时间占比
相邻区域不代表有先后关系	左右相邻不代表调用顺序
放大看细节	点击可折叠/展开
等高线 = 海拔	栈深度 = 调用层级

⚠️ 最容易犯的错误：把横轴当时间轴，以为「左边先发生、右边后发生」。它不是时间轴——左边和右边只是不同的调用栈，可能在同一毫秒内交替出现。

二、三种要认出的形状

形状一：宽而平（热点函数）

┌──────────────────────────────────────────────────┐
│                  handleRequest                    │
├───────┬──────────────────────────────────────────┤
│ 业务   │         serialize (很宽，下方无子帧)        │  ← 热点！
└───────┴──────────────────────────────────────────┘

含义：这个函数自己在消耗时间（不是子调用）。

行动：这就是优化目标。看它的实现——常见的是序列化、正则、加密、字符串处理、集合操作。

形状二：深而窄（深调用链）

handleRequest
 └─ service
     └─ repository
         └─ hibernate
             └─ jdbc
                 └─ socketRead   ← 深而窄

含义：调用链深，但每一层占的时间都不多——时间分散在整条链上。

硬件层面的ABA问题

Mon, 01 Jan 0001 00:00:00 +0000

这个问题触及了无锁编程最隐蔽的陷阱。很多人以为ABA只是理论概念，但在内存复用的场景下，它会导致内存损坏甚至安全漏洞。

我们先从硬件视角看为什么CPU会被骗，再深入实际崩溃场景。

1. 硬件层面的"失忆症"

场景重现（用 `cmpxchg`）

初始状态: 共享指针 ptr 指向 内存块A (地址 0x1000)

[时刻1] 线程1 读取 ptr → 0x1000 (期望值)
[时刻2] 线程2 执行:
          ptr 从 0x1000 → 0x2000 (释放A)
          ptr 从 0x2000 → 0x1000 (重新分配，又指向A)
[时刻3] 线程1 执行 lock cmpxchg:
          比较: 当前 ptr (0x1000) == 期望值 (0x1000) → ✅ 相等!
          硬件认为"没人动过"，允许写入新值 0x3000

硬件视角：地址0x1000确实没变，CAS成功。

现实视角：0x1000指向的内存内容可能已经被完全改写（线程2在复用期间修改了A的内容），但CAS毫不知情。

2. 为什么传统锁不会遇到ABA？

// 使用互斥锁 (Mutex)
std::mutex mtx;
{
    std::lock_guard<std::mutex> lock(mtx);
    // 临界区: 执行过程中，其他线程无法进入
    // 所以不可能出现"A→B→A"的中间态
}

关键差异：锁是排他性阻塞，而CAS是乐观重试。锁期间其他线程根本动不了数据，自然不会有ABA。

第一阶段到第四阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

第一阶段（移动语义）：
    左值/右值 → std::move 是 cast 不是 move
    → 右值引用变量本身是左值（面试陷阱）
    → 完美转发 std::forward 保持值类别

第二阶段（容器内存布局）：
    vector：连续 → 缓存友好 → 扩容因子 1.5/2 → 迭代器失效
    list：节点散落 → 缓存灾难 → 除非频繁中间插入否则别用
    deque：中控+分块 → 两端 O(1) → stack/queue 默认容器
    unordered_map：桶+链表 → O(1)均摊 → rehash 是灾难
    map：红黑树 → O(log N) → 节点散落同样缓存不友好

第三阶段（智能指针）：
    unique_ptr：零开销，就是裸指针
    shared_ptr：16字节，控制块+原子引用计数，make_shared合并分配
    weak_ptr：lock()做原子检查+增加，破循环引用

第四阶段（模板元编程）：
    模板特化：全特化/偏特化（函数不能偏特化）
    Type Traits：编译期布尔值，通过模板偏特化实现
    SFINAE：替换失败不是错误，enable_if 条件启用
    if constexpr：编译期分支，不匹配分支不编译
    constexpr/consteval：编译期计算
    Concepts C++20：约束模板参数，报错清晰

第七阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

PGO 三步骤：
    -fprofile-generate → 跑真实负载 → -fprofile-use

优化效果：
    10-30% 性能提升（主要来自热/冷代码分离 + 分支优化）

关键：
    训练负载必须代表真实使用场景
    测试数据和训练数据不能是同一份（会过拟合）

第三阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

容器格式是"打包工"：
    视频轨（H.264/H.265）+ 音频轨（AAC/MP3）+ 元数据 + 时间戳

MP4 基于 Box 结构：
    moov 在文件头/尾决定是否支持流式播放
    stbl 系列 box 记录每帧的位置、大小、时间戳

FLV 基于 Tag 结构：
    VideoTag/AudioTag/ScriptTag
    RTMP 的底层封装就是 FLV
    flv.js 解析 FLV 在浏览器播放

第三阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

ASan（内存错误）：
    堆/栈越界、Use-After-Free、Double-Free
    编译：-fsanitize=address
    速度：慢 2x，内存多 2-3x

UBSan（未定义行为）：
    整数溢出、移位越界、空指针解引用
    编译：-fsanitize=undefined
    建议：所有项目 Debug 构建都应该开启

TSan（数据竞争）：
    多线程无锁编程的 Bug
    编译：-fsanitize=thread
    限制：不能和 ASan 一起用，要求全量重编

最佳实践：
    Debug 构建：-fsanitize=address,undefined
    CI 测试构建：-fsanitize=thread（单独跑）
    生产构建：不要带 sanitizer（性能影响太大）

第五阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

PCM 音频：
    采样率 × 位深 × 声道数 = 每秒数据量
    48000/16bit/stereo = 187.5 KB/s

AAC 编码：
    128 kbps ≈ 16 KB/s，压缩比约 11:1
    ADTS 头部标识帧的开始和参数

音频处理常用操作：
    混音（两个 PCM 波形相加，防溢出）
    重采样（采样率/声道/格式转换）
    音量调整（PCM 值乘以系数）

第八阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

FFmpeg 命令行：
    ffprobe → 检查文件信息
    ffmpeg -preset ultrafast -tune zerolatency → 直播推流标配

推流问题排查：
    先 ffmpeg 命令行排除代码问题
    telnet 确认端口通

画面花屏：
    GOP 大小 + sps/pps 重复发送

音画不同步：
    time_base 一致性 + PTS 单调递增 + 音频主时钟

延迟优化：
    不要 B 帧 + 小 GOP + CBR 码率 + ultrafast preset

第六阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

Clang-Tidy：
    编译时的代码检查（模式匹配）
    bugprone-* / performance-* / modernize-*
    在 CMake 中用 CMAKE_CXX_CLANG_TIDY 集成

Clang Static Analyzer：
    符号执行（模拟代码路径）
    能发现资源泄漏、死代码、部分空指针

clangd：
    IDE 实时分析
    基于 compile_commands.json 提供语义支持

第四阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

解封装（Demuxing）：
    avformat_open_input → 打开文件
    av_read_frame → 读 packet
    avcodec_send_packet + avcodec_receive_frame → 解码

封装（Muxing）：
    avformat_alloc_output_context2 → 确定容器格式
    avcodec_send_frame + avcodec_receive_packet → 编码
    av_interleaved_write_frame → 写出/推流

色彩转换：
    BGRA → YUV420P：sws_getContext + sws_scale 一步完成
    比手写 RGB→YUV 再下采样快 3-5 倍

直播配置关键：
    gop_size = 30（每 30 帧一个关键帧）
    max_b_frames = 0（不要 B 帧减少延迟）
    AV_CODEC_FLAG_LOW_DELAY（编码器低延迟模式）

结合你已做的

Mon, 01 Jan 0001 00:00:00 +0000

你的 SimpleAsyncLogger 其实已经包含了线程池和定时器的雏形：

AsyncWriter（一个线程）：
  while (running) {
    1. io_uring_poll() → 处理已完成的 I/O
    2. 检查是否该日志轮转（定时器行为）
    3. 检查 TCP 是否该重连（定时器行为）
    4. 检查是否有新数据 → 提交 io_uring write 和 send
    5. 超时或满 4KB → flush
  }

这个就是单线程 Event Loop + 内置定时器的模型。面试时你可以说：“我的日志库的 AsyncWriter 就是一个简化的 Reactor 模型——单线程事件循环，把定时器检查、I/O 完成处理、任务提交合并到一个循环里。”

配套代码：async-profiler 命令全集与火焰图解读

Mon, 01 Jan 0001 00:00:00 +0000

4.3 配套代码：async-profiler 命令全集与火焰图解读

对应小节：4.3 async-profiler 这份文件是命令速查 + 判读手册，建议放在手边。

一、安装与权限（最容易卡住的一步）

# 下载（以 3.x 为例）
curl -L -o async-profiler.tar.gz \
  https://github.com/async-profiler/async-profiler/releases/download/v3.0/async-profiler-3.0-linux-x64.tar.gz
tar xzf async-profiler.tar.gz && cd async-profiler-3.0-linux-x64

# 验证
./asprof --version

# Linux 权限：perf_event_paranoid 必须 <= 1
cat /proc/sys/kernel/perf_event_paranoid
sudo sysctl -w kernel.perf_event_paranoid=1

# 容器内：需要额外 capability 或放宽 seccomp
# docker run --cap-add SYS_ADMIN ...
# 或者（Docker Compose）
#   cap_add: [SYS_ADMIN]
#   security_opt: [seccomp:unconfined]

如果拿不到 perf 权限：async-profiler 会退化到 itimer 模式（精度较低但可用）：

asprof -e itimer -d 60 -f out.html <pid>

「火焰图很空」的头号原因就是权限问题——先检查这一项，再怀疑别的。

配套代码：三个测量点的埋点与延迟分解

Mon, 01 Jan 0001 00:00:00 +0000

1.3 配套代码：三个测量点的埋点与延迟分解

对应小节：1.3 测量点目标：让代码能回答「这个接口的 P99 里，数据库占多少毫秒、排队占多少毫秒、我写的代码占多少毫秒」。

一、依赖级计时器

// src/main/kotlin/metrics/TimedDependency.kt
package metrics

import io.micrometer.core.instrument.MeterRegistry
import io.micrometer.core.instrument.Timer
import java.time.Duration

/**
 * 每个依赖一个 Timer。
 * 注意：这里用 builder 而不是 record()，因为需要为每个依赖单独配置桶边界。
 */
class DependencyTimers(registry: MeterRegistry) {

    private fun timer(name: String, description: String): Timer =
        Timer.builder(name)
            .description(description)
            .publishPercentileHistogram(true)
            .serviceLevelObjectives(*sloBuckets.toTypedArray())
            .minimumExpectedValue(Duration.ofMillis(1))
            .maximumExpectedValue(Duration.ofSeconds(5))
            .register(registry)

    val postgres = timer("dep.postgres", "PostgreSQL 调用耗时（含等待连接）")
    val redis = timer("dep.redis", "Redis 调用耗时")
    val downstream = timer("dep.downstream", "下游 HTTP 调用耗时")

    /**
     * 跨越挂起点的计时是合法的：Timer.Sample 只记录起始时刻。
     * 因此协程调度的时间也会被计入 —— 这正是我们想要的（用户看到的就是这段时间）。
     */
    suspend fun <T> timed(timer: Timer, registry: MeterRegistry, block: suspend () -> T): T {
        val sample = Timer.start(registry)
        return try {
            block()
        } finally {
            sample.stop(timer)
        }
    }
}

一个容易忽略的细节：dep.postgres 的计时包含了「等连接池分配连接」的时间。这其实很有用——如果这个 Timer 的 P99 突然飙升，你要进一步区分「等连接」和「查询慢」，方法是同时看 db_pool_pending 指标（饱和度层）。

配套代码：全链路性能门禁

Mon, 01 Jan 0001 00:00:00 +0000

8.3 配套代码：全链路性能门禁

对应小节：8.3 全链路性能门禁一份完整的门禁脚本，含饱和度检查（最容易被忽略但最有价值的一项）。

一、完整的全链路门禁脚本

#!/usr/bin/env bash
# tools/e2e-perf-gate.sh <VERSION_TAG>
#
# 全链路性能门禁：发布候选阶段运行。
#
# 前置条件（缺一不可，否则结果不可信）：
#   ① 专用环境（固定规格、独占、压测客户端独立）
#   ② 固定的数据集（每次重置到同一状态）
#   ③ 固定的 JVM 参数与容器配置
set -euo pipefail

VERSION="${1:?usage: e2e-perf-gate.sh <version_tag>}"
EXP_ID="gate-${VERSION}"
DIR="docs/experiments/${EXP_ID}"
mkdir -p "$DIR/results"

echo "═══════════════════════════════════════════════════════════════"
echo "全链路性能门禁：$VERSION"
echo "═══════════════════════════════════════════════════════════════"
echo

# ═══ 1/7 环境检查（不通过就终止）═══
echo "【1/7】环境检查"
tools/check-environment.sh "$EXP_ID" > /dev/null 2>&1 || true
if grep -q "❌" "$DIR/results/env-check.txt" 2>/dev/null; then
  echo "❌ 环境检查未通过 —— 本次结果不可信，终止"
  grep "❌" "$DIR/results/env-check.txt" | sed 's/^/   /'
  exit 2
fi
tools/collect-env.sh "$EXP_ID" > /dev/null 2>&1 || true
echo "   ✅ 环境检查通过"
echo

# ═══ 2/7 记录代码版本 ═══
echo "【2/7】记录代码版本"
{
  echo "commit=$(git rev-parse HEAD)"
  echo "tag=$VERSION"
  echo "dirty=$(git status --porcelain | wc -l | tr -d ' ')"
} | tee "$DIR/results/code-state.txt"
echo

# ═══ 3/7 重置数据集并重启 ═══
echo "【3/7】重置数据集"
scripts/reset-dataset.sh
scripts/restart-app.sh "$DIR/results/gc.log"
sleep 10
echo "   ✅ 服务已重启"
echo

# ═══ 4/7 预热（不计入统计）═══
echo "【4/7】预热 60 秒"
BASE_URL="$TARGET_URL" k6 run --quiet --vus 20 --duration 60s \
  loadtest/profile-constant.js > /dev/null 2>&1
echo "   ✅ 预热完成"
echo

# ═══ 5/7 测量 3 轮 ═══
echo "【5/7】测量 3 轮（每轮 3 分钟）"
for i in 1 2 3; do
  echo "   ── 第 $i 轮 ──"
  BASE_URL="$TARGET_URL" RATE="${TARGET_QPS:-500}" DURATION=3m \
  k6 run --summary-export="$DIR/results/round-$i.json" \
         loadtest/profile-constant.js > "$DIR/results/round-$i-stdout.txt" 2>&1

  # ⭐ 关键：同时采集饱和度指标（不只是延迟）
  curl -s --max-time 5 "${TARGET_URL%/}/metrics" > "$DIR/results/metrics-$i.txt" 2>/dev/null || true

  python3 - "$DIR/results/round-$i.json" <<'PY'
import json, sys
m = json.load(open(sys.argv[1]))["metrics"]
d = m["http_req_duration"]
print(f"      QPS={m['http_reqs']['rate']:.1f}  P50={d['med']:.1f}  "
      f"P95={d['p(95)']:.1f}  P99={d['p(99)']:.1f}  错误率={m['http_req_failed']['rate']:.2%}")
PY
done
echo

# ═══ 6/7 检查（四项）═══
echo "【6/7】门禁检查"
python3 tools/e2e_gate_check.py "$DIR/results" perf/e2e-baseline.json
GATE_RESULT=$?
echo

# ═══ 7/7 结论 ═══
echo "【7/7】结论"
if [ $GATE_RESULT -eq 0 ]; then
  echo "✅ 性能门禁通过"
  echo
  echo "后续："
  echo "  ① 把结果归档：cp -r $DIR perf/gate-history/$VERSION"
  echo "  ② 继续发布流程（进入金丝雀阶段）"
  echo "  ③ 发布完成后，把本次结果更新为新的候选基线"
else
  echo "❌ 性能门禁失败"
  echo
  echo "后续："
  echo "  ① 查看 $DIR/results/ 下的详细数据"
  echo "  ② 按第 8.3 节的决策树处理："
  echo "     查环境 → 判幅度 → 定位（第 6 章）→ 决策"
  echo "  ③ ⚠️ 不要直接更新基线"
  exit 1
fi

二、四项检查的实现（含饱和度）

# tools/e2e_gate_check.py <RESULTS_DIR> <BASELINE_JSON>
"""
全链路门禁的检查逻辑。

四项检查：
  ① SLO 达标（延迟 + 错误率）
  ② 拐点未后移（如果有拐点数据）
  ③ 饱和度正常 ⭐（最容易被忽略）
  ④ 资源无异常（内存、连接）
"""
import json
import pathlib
import re
import statistics as st
import sys


def load_rounds(d):
    rounds = []
    for f in sorted(pathlib.Path(d).glob("round-*.json")):
        try:
            m = json.loads(f.read_text())["metrics"]
            dr = m["http_req_duration"]
            rounds.append({
                "qps": m["http_reqs"]["rate"],
                "p50": dr["med"], "p95": dr["p(95)"], "p99": dr["p(99)"],
                "err": m["http_req_failed"]["rate"],
            })
        except Exception:
            pass
    return rounds


def load_metrics_snapshot(d, round_no):
    """从 /metrics 快照里提取饱和度指标"""
    p = pathlib.Path(d) / f"metrics-{round_no}.txt"
    if not p.exists():
        return {}
    text = p.read_text(errors="ignore")
    out = {}
    for key, pattern in [
        ("pool_pending", r"^db_pool_pending\s+([\d.]+)"),
        ("pool_active", r"^db_pool_active\s+([\d.]+)"),
        ("pool_total", r"^db_pool_total\s+([\d.]+)"),
        ("queue_depth", r"^executor_queue_depth\s+([\d.]+)"),
        ("heap_used_mb", r"^jvm_memory_used_bytes\{.*heap.*\}\s+([\d.]+)"),
    ]:
        m = re.search(pattern, text, re.MULTILINE)
        if m:
            v = float(m.group(1))
            out[key] = v / 1048576 if key == "heap_used_mb" else v
    return out


def main(results_dir, baseline_path):
    rounds = load_rounds(results_dir)
    if not rounds:
        print("❌ 没有找到测量数据")
        sys.exit(2)

    baseline = {}
    bp = pathlib.Path(baseline_path)
    if bp.exists():
        baseline = json.loads(bp.read_text())

    problems = []
    warnings = []
    passed = []

    print("═" * 84)
    print("全链路门禁检查（四项）")
    print("═" * 84)
    print()

    # ── ① SLO 达标 ──────────────────────────────────────────
    print("【① SLO 达标】")
    p99 = st.median([r["p99"] for r in rounds])
    err = st.median([r["err"] for r in rounds])
    p99_slo = baseline.get("slo_p99_ms", 200)
    err_slo = baseline.get("slo_error_rate", 0.001)

    print(f"  P99 (中位数): {p99:.1f} ms   （SLO: < {p99_slo} ms）")
    print(f"  错误率       : {err:.2%}   （SLO: < {err_slo:.2%}）")

    if p99 > p99_slo:
        problems.append(f"SLO 违约：P99 {p99:.1f}ms > {p99_slo}ms")
        print("  ❌ SLO 违约")
    elif p99 > p99_slo * 0.9:
        warnings.append(f"P99 接近 SLO（{p99:.1f}/{p99_slo}ms）")
        print("  ⚠️  接近 SLO 上限")
    else:
        passed.append("SLO 达标")
        print("  ✅ 达标")

    if err > err_slo:
        problems.append(f"错误率超标：{err:.2%} > {err_slo:.2%}")
        print("  ❌ 错误率超标")
    print()

    # ── ② 基线对比（延迟与吞吐）──────────────────────────────
    print("【② 与基线对比】")
    if baseline.get("p99"):
        base_p99 = baseline["p99"]
        delta = (p99 - base_p99) / base_p99 * 100
        threshold = baseline.get("p99_threshold_pct", 20)
        print(f"  P99: 基线 {base_p99:.1f}ms → 当前 {p99:.1f}ms （{delta:+.1f}%，阈值 ±{threshold}%）")
        if delta > threshold:
            problems.append(f"P99 退化 {delta:+.1f}%")
            print("  ❌ 退化超阈值")
        else:
            passed.append("P99 无退化")
            print("  ✅")
    else:
        print("  （基线中无 P99 数据，跳过）")
    print()

    # ── ③ 饱和度 ⭐（最容易被忽略）──────────────────────────
    print("【③ 饱和度检查】⭐ 领先指标")
    pending_vals, queue_vals = [], []
    for i in range(1, len(rounds) + 1):
        snap = load_metrics_snapshot(results_dir, i)
        if "pool_pending" in snap:
            pending_vals.append(snap["pool_pending"])
        if "queue_depth" in snap:
            queue_vals.append(snap["queue_depth"])

    if pending_vals:
        max_pending = max(pending_vals)
        print(f"  连接池 pending 最大值: {max_pending:.0f}")
        if max_pending > 0:
            problems.append(f"连接池出现排队（pending 最大 {max_pending:.0f}）")
            print("  ❌ 存在排队 —— 系统余量已被耗尽")
            print("     即使延迟达标，也应拒绝通过（第 8.3 节）")
        else:
            passed.append("连接池无排队")
            print("  ✅ 无排队")
    else:
        print("  （未采集到 pending 指标 —— 建议在 metrics 快照里加上）")

    if queue_vals:
        max_queue = max(queue_vals)
        print(f"  线程池队列最大深度: {max_queue:.0f}")
        if max_queue > 100:
            problems.append(f"线程池队列积压（{max_queue:.0f}）")
            print("  ❌ 队列积压")
        else:
            passed.append("队列无积压")
            print("  ✅ 队列正常")
    print()

    # ── ④ 资源趋势（泄漏检测）──────────────────────────────
    print("【④ 资源趋势】")
    heaps = []
    for i in range(1, len(rounds) + 1):
        snap = load_metrics_snapshot(results_dir, i)
        if "heap_used_mb" in snap:
            heaps.append(snap["heap_used_mb"])
    if len(heaps) >= 3:
        print(f"  堆使用: {[f'{h:.0f}' for h in heaps]} MB")
        if heaps[-1] > heaps[0] * 1.5:
            warnings.append("堆使用有上升趋势（建议做浸泡测试）")
            print("  ⚠️  有上升趋势 —— 建议单独做浸泡测试确认（第 3 章 3.5）")
        else:
            passed.append("资源稳定")
            print("  ✅ 稳定")
    else:
        print("  （轮数不足或未采集，跳过）")
    print()

    # ── 汇总 ────────────────────────────────────────────────
    print("═" * 84)
    if problems:
        print(f"❌ 门禁失败（{len(problems)} 项问题）")
        for p in problems:
            print(f"   - {p}")
        print()
        print("处理方式：")
        print("  ① 检查环境（env-check.txt 有没有 ❌）")
        print("  ② 判断幅度（是噪声还是真退化）")
        print("  ③ 定位（用第 6 章的延迟分解与火焰图）")
        print("  ④ 不要直接更新基线")
        sys.exit(1)
    elif warnings:
        print(f"⚠️  门禁通过，但有 {len(warnings)} 项警告")
        for w in warnings:
            print(f"   - {w}")
        sys.exit(0)
    else:
        print("✅ 门禁通过（四项检查全部通过）")
        sys.exit(0)


if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2] if len(sys.argv) > 2 else "perf/e2e-baseline.json")

三、基线文件格式

{
  "version": "v2.3.0",
  "date": "2025-01-10",
  "environment": {
    "instance": "4C8G",
    "replicas": 3,
    "jvm_args": "-Xms2g -Xmx2g -XX:+UseG1GC",
    "container_cpu_limit": "4",
    "container_mem_limit": "8Gi"
  },
  "slo_p99_ms": 200,
  "slo_error_rate": 0.001,
  "p99": 95.2,
  "p95": 42.1,
  "p50": 12.3,
  "qps": 500,
  "p99_threshold_pct": 20,
  "saturation": {
    "pool_pending_max": 0,
    "queue_depth_max": 0
  },
  "notes": "拐点约 900 RPS（E02 实验）；数据量 100 万行"
}

注意 saturation 这一栏：把基线时的饱和度也记下来——这样当前值不为 0 时就能立刻发现"余量在减少"。

配套代码：均值如何骗人，尾部如何放大

Mon, 01 Jan 0001 00:00:00 +0000

0.3 配套代码：均值如何骗人，尾部如何放大

对应小节：0.3 延迟是分布，不是数字要验证的三个结论：① 均值掩盖长尾 ② 尾延迟跨服务放大 ③ 百分位不能直接平均

一、实验一：均值与百分位的差距

构造一个真实的「重尾」延迟分布：99% 的请求很快（4–7 ms），1% 的请求很慢（800–1200 ms）。这正是后端常见的样子——大部分请求走缓存，少数请求穿透到数据库或遇到 GC。

// src/main/kotlin/lesson00/LatencyDistribution.kt
package lesson00

import kotlin.random.Random

/** 取分位数：输入必须已排序。q=0.99 表示"99% 的样本比它小" */
fun percentile(sorted: LongArray, q: Double): Long {
    val idx = ((sorted.size - 1) * q).toInt().coerceIn(0, sorted.size - 1)
    return sorted[idx]
}

/**
 * 生成一个重尾分布：
 * 99% 的样本落在 [fastMin, fastMax)，1% 落在 [slowMin, slowMax)
 * 单位：毫秒（这里用整数模拟，便于观察）
 */
fun heavyTailed(n: Int, slowRatio: Double = 0.01, seed: Int = 42): LongArray {
    val rnd = Random(seed)
    return LongArray(n) {
        if (rnd.nextDouble() < slowRatio) rnd.nextLong(800, 1200)
        else rnd.nextLong(4, 7)
    }
}

fun main() {
    val samples = heavyTailed(200_000)
    val sorted = samples.sortedArray()
    val mean = samples.average()

    println("=== 实验一：均值 vs 百分位（20 万个请求）===")
    println("平均值      : %8.2f ms   ← 只有这一个数字时，你会以为服务很健康".format(mean))
    println("P50 (中位数): %8d ms   ← 一半用户的实际体验".format(percentile(sorted, 0.50)))
    println("P90         : %8d ms".format(percentile(sorted, 0.90)))
    println("P95         : %8d ms".format(percentile(sorted, 0.95)))
    println("P99         : %8d ms   ← 每 100 个用户就有 1 个这样".format(percentile(sorted, 0.99)))
    println("P999        : %8d ms".format(percentile(sorted, 0.999)))
    println("最大值      : %8d ms".format(sorted.last()))
    println()
    println("差距：P99 是平均值的 %.0f 倍。".format(percentile(sorted, 0.99) / mean))
    println("在 100 万日请求量下，P99 意味着每天有 %,d 个用户体验到这种延迟。"
        .format((1_000_000 * 0.01).toLong()))
    println()

    // ── 实验二：尾延迟跨服务放大 ────────────────────────────────
    demonstrateTailAmplification()

    // ── 实验三：百分位不能直接平均 ──────────────────────────────
    demonstratePercentileAggregationTrap()
}

二、实验二：尾延迟跨服务放大

正文的结论是：10 个下游各 1% 慢 → 整条链路约 10% 慢。

配套代码：并行度调优与隔板

Mon, 01 Jan 0001 00:00:00 +0000

7.3 配套代码：并行度调优与隔板

对应小节：7.3 并发与并行两件事：① 用实验找到最优并行度；② 用隔板实现资源隔离。

一、并行度调优实验

// src/main/kotlin/experiments/ParallelismTuning.kt
package experiments

import kotlinx.coroutines.*
import kotlinx.coroutines.sync.Semaphore
import kotlinx.coroutines.sync.withPermit
import kotlin.system.measureNanoTime

private var sink = 0L

/** 模拟一次"要 5ms 的 IO 操作" */
suspend fun simulatedIo(): Int {
    delay(5)
    return 1
}

/** 模拟一次"要 1ms 的 CPU 操作" */
fun simulatedCpu(): Int {
    var s = 0
    repeat(10_000) { s += it }
    return s
}

/**
 * 测量不同并行度下的吞吐与延迟。
 *
 * @param parallelism 并发上限
 * @param totalOps 总操作数
 * @param ioBound true = IO 密集（delay），false = CPU 密集
 */
suspend fun measure(parallelism: Int, totalOps: Int, ioBound: Boolean): Triple<Double, Double, Double> {
    val limiter = Semaphore(parallelism)
    val latencies = java.util.concurrent.ConcurrentLinkedQueue<Long>()

    val elapsedNs = measureNanoTime {
        coroutineScope {
            val dispatcher = if (ioBound) Dispatchers.IO else Dispatchers.Default
            (0 until totalOps).map { i ->
                async(dispatcher) {
                    limiter.withPermit {
                        val t0 = System.nanoTime()
                        val r = if (ioBound) simulatedIo() else simulatedCpu()
                        latencies.add(System.nanoTime() - t0)
                        sink += r
                    }
                }
            }.awaitAll()
        }
    }

    val lats = latencies.toLongArray().apply { sort() }
    val qps = totalOps / (elapsedNs / 1e9)
    val p50 = lats[lats.size / 2] / 1e6
    val p99 = lats[(lats.size * 99) / 100] / 1e6
    return Triple(qps, p50, p99)
}

fun main() = runBlocking {
    val cores = Runtime.getRuntime().availableProcessors()
    println("CPU 核数 = $cores")
    println()

    for ((label, ioBound) in listOf("IO 密集（每次 5ms）" to true, "CPU 密集（每次 ~1ms）" to false)) {
        println("═══ $label ═══")
        println()
        val header = "%-8s%12s%12s%12s   %s".format("并行度", "QPS", "P50(ms)", "P99(ms)", "判读")
        println(header)
        println("-".repeat(64))

        var bestQps = 0.0
        for (p in listOf(1, 2, 4, 8, 16, 32, 64)) {
            // 跳过对 CPU 密集无意义的过大并行度
            if (!ioBound && p > cores * 4) continue

            val (qps, p50, p99) = measure(p, totalOps = if (ioBound) 2000 else 5000, ioBound = ioBound)

            val verdict = when {
                p == 1 -> "基线"
                qps > bestQps * 1.1 -> "✅ 仍在提升"
                qps > bestQps * 0.95 -> "⚠️  接近拐点"
                else -> "❌ 已过拐点（QPS 下降）"
            }
            if (qps > bestQps) bestQps = qps

            println("%-8d%12.0f%12.2f%12.2f   %s".format(p, qps, p50, p99, verdict))
        }
        println()
        if (ioBound) {
            println("IO 密集的判读：")
            println("  → QPS 随并行度上升，直到下游/调度器成为瓶颈")
            println("  → 注意 P99：并行度提高后 P99 通常上升（排队）")
            println("  → 选在「QPS 不再显著提升」之前，且 P99 可接受的位置")
        } else {
            println("CPU 密集的判读：")
            println("  → 最优值 ≈ CPU 核数（%d）；超过后 QPS 下降".format(cores))
            println("  → 因为上下文切换成本超过并行收益")
        }
        println()
    }

    println("sink = $sink")
    println()
    println("⚠️  这是开发机上的简化实验，绝对值不可信；看【趋势与拐点位置】。")
}

预期输出形态：

配套代码：微基准四大陷阱的现场复现

Mon, 01 Jan 0001 00:00:00 +0000

2.3 配套代码：微基准四大陷阱的现场复现

对应小节：2.3 微基准四大陷阱每个陷阱都写「坏版本」和「好版本」，并排跑，让差异自己说话。

一、完整实验代码

// src/main/kotlin/lesson02/MicrobenchmarkTraps.kt
package lesson02

import kotlin.random.Random

// ── 被测函数 ──────────────────────────────────────────────────
fun sumArray(data: IntArray): Long {
    var s = 0L
    for (v in data) s += v
    return s
}

/** 含分支的函数：用来演示分支预测 */
fun countPositive(data: IntArray): Int {
    var c = 0
    for (v in data) if (v > 0) c++
    return c
}

data class OrderDto(val id: Long, val name: String, val amount: Long)

fun makeDto(i: Int) = OrderDto(i.toLong(), "order-$i", (i * 31).toLong())

// ── 全局 sink：防止整个实验被优化掉 ────────────────────────────
private var sink = 0L

fun bench(iterations: Int, label: String, body: () -> Long): Double {
    // 粗略预热（真实基准要用 JMH）
    repeat(iterations / 4) { sink += body() }
    val t0 = System.nanoTime()
    repeat(iterations) { sink += body() }
    val t1 = System.nanoTime()
    val ns = (t1 - t0).toDouble() / iterations
    println("%-46s %12.3f ns/op".format(label, ns))
    return ns
}

fun main() {
    val rnd = Random(42)
    val randomData = IntArray(4096) { rnd.nextInt() }
    val constLikeData = IntArray(4096) { it }                 // 规律数据
    val mixedSignData = IntArray(4096) { rnd.nextInt(-100, 100) }
    val allPositive = IntArray(4096) { rnd.nextInt(1, 100) }

    println("═".repeat(76))
    println("陷阱一：死代码消除（DCE）")
    println("═".repeat(76))
    bench(200_000, "❌ 坏版本：不消费返回值") {
        sumArray(randomData)                    // 结果丢弃 → 计算可能被整体删除
        0L
    }
    bench(200_000, "✅ 好版本：消费返回值") {
        sumArray(randomData)
    }
    println("→ 坏版本的数字可能低到物理不可能。判断方法：把数组大小改成 10 倍，看耗时是否变化。\n")

    println("═".repeat(76))
    println("陷阱二：常量折叠")
    println("═".repeat(76))
    bench(200_000, "❌ 坏版本：规律数据（{ it }）") {
        sumArray(constLikeData)
    }
    bench(200_000, "✅ 好版本：运行时随机数据") {
        sumArray(randomData)
    }
    println("→ 规律数据可能被识别出模式（甚至直接套公式），数字与真实负载无关。\n")

    println("═".repeat(76))
    println("陷阱三：分支预测被喂得太好")
    println("═".repeat(76))
    bench(200_000, "❌ 坏版本：全部正数（分支永远成立）") {
        countPositive(allPositive).toLong()
    }
    bench(200_000, "✅ 好版本：正负混合（分支随机失败）") {
        countPositive(mixedSignData).toLong()
    }
    println("→ 全正数时分支预测接近 100% 命中，比真实混合流量快得多。\n")

    println("═".repeat(76))
    println("陷阱四：未消费结果（逃逸分析消除分配）")
    println("═".repeat(76))
    // 用分配速率来观察，而不是耗时
    val before1 = allocatedBytes()
    repeat(1_000_000) { makeDto(it) }                          // 对象不逃逸
    val after1 = allocatedBytes()
    println("❌ 坏版本（对象不逃逸）：分配 %,d 字节".format(after1 - before1))

    val list = ArrayList<OrderDto>(1_000_000)
    val before2 = allocatedBytes()
    repeat(1_000_000) { list.add(makeDto(it)) }                // 对象逃逸到集合
    val after2 = allocatedBytes()
    println("✅ 好版本（对象逃逸到集合）：分配 %,d 字节".format(after2 - before2))
    sink += list.size
    println("→ 不逃逸时逃逸分析可能连对象带分配一起消除，你测不到真实的 GC 压力。")

    println()
    println("sink = $sink")
}

/** 用 ThreadMXBean 读取当前线程累计分配的字节数（近似值，仅用于对比） */
fun allocatedBytes(): Long =
    (java.lang.management.ManagementFactory.getThreadMXBean() as? com.sun.management.ThreadMXBean)
        ?.getThreadAllocatedBytes(Thread.currentThread().threadId())
        ?: -1L

关于 allocatedBytes()：它用了 com.sun.management.ThreadMXBean 这个 JDK 内部 API（只用于教学演示）。如果编译报错，可以换成用 -prof gc（JMH）或 async-profiler 的 alloc 事件来观察。

配套代码：搭服务与造数据

Mon, 01 Jan 0001 00:00:00 +0000

9.3 配套代码：搭服务与造数据

对应小节：9.3 步骤二：搭服务与数据

一、docker-compose

# perf/docker-compose.yaml
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: shortlink
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app
    ports: ["5432:5432"]
    volumes:
      - ./sql:/docker-entrypoint-initdb.d:ro
      - pgdata:/var/lib/postgresql/data
    command:
      - postgres
      # ── 关键：明确资源上限，否则本机 PG 会吃掉所有内存，结果无法解释 ──
      - -c
      - shared_buffers=2GB
      - -c
      - effective_cache_size=6GB
      - -c
      - work_mem=64MB
      - -c
      - max_connections=200
      - -c
      - log_min_duration_statement=100     # 慢查询日志（>100ms 都记）
      - -c
      - track_io_timing=on                 # EXPLAIN BUFFERS 才有 I/O 时间
    deploy:
      resources:
        limits: { cpus: "4", memory: "8g" }
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d shortlink"]
      interval: 5s
      retries: 10

  redis:
    image: redis:7
    ports: ["6379:6379"]
    command: ["redis-server", "--maxmemory", "1gb", "--maxmemory-policy", "allkeys-lru"]
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s

volumes:
  pgdata:

注意 deploy.resources.limits：

配套代码：火焰图的分析辅助

Mon, 01 Jan 0001 00:00:00 +0000

6.3 配套代码：火焰图的分析辅助

对应小节：6.3 火焰图读法三件事：① 从 flat 输出快速找热点；② diff 两次火焰图；③ 自动识别形状特征。

一、从 flat 输出找热点（比读图更快）

#!/usr/bin/env bash
# tools/top-hotspots.sh <PID> [EVENT] [DURATION]
#
# 用 async-profiler 的 flat 输出，直接列出"自身耗时最多"的函数。
# 比在火焰图里肉眼找快得多。
set -uo pipefail

PID="${1:?usage: top-hotspots.sh <pid> [event] [duration]}"
EVENT="${2:-cpu}"
DURATION="${3:-30}"

TMP=$(mktemp)
asprof -d "$DURATION" -e "$EVENT" -o flat -f "$TMP" "$PID" > /dev/null 2>&1

echo "═══ $EVENT 事件的热点排名（采样 ${DURATION}s）═══"
echo

# flat 输出格式：通常每行是 "百分比% 栈帧"
head -25 "$TMP" | while IFS= read -r line; do
  echo "$line"
done

echo
echo "─── 按包/模块聚合（Top 10）───"
awk '{
  # 取倒数第一列作为函数名（格式因版本而异，这是容错处理）
  n = split($0, a, " ");
  frame = a[n];
  # 提取包名（前两段）
  split(frame, parts, ".");
  pkg = parts[1];
  if (length(parts) > 1) pkg = pkg "." parts[2];
  # 提取百分比（第一个字段）
  pct = a[1];
  gsub(/[^0-9.]/, "", pct);
  if (pct != "") sum[pkg] += pct;
} END {
  for (p in sum) printf "%8.2f%%  %s\n", sum[p], p;
}' "$TMP" | sort -rn | head -10

rm -f "$TMP"

二、diff 两次火焰图（证明优化有效）

#!/usr/bin/env bash
# tools/flamegraph-diff.sh <PID> <EVENT> <BEFORE_LABEL> <AFTER_LABEL>
#
# 分别在优化前/后采集，生成差量图。
# 差量图能直接显示"哪条链路变短了"。
set -uo pipefail

PID="${1:?usage: flamegraph-diff.sh <pid> <event> <before_label> <after_label>}"
EVENT="${2:-wall}"
BEFORE="${3:?}"
AFTER="${4:?}"
OUT_DIR="${OUT_DIR:-docs/experiments/flamegraph-diff}"
mkdir -p "$OUT_DIR"

echo "采集 $EVENT 火焰图：$BEFORE"
asprof -d 60 -e "$EVENT" -o collapsed -f "$OUT_DIR/$BEFORE.txt" "$PID"

echo
echo "⏸  现在请应用你的优化（或切到优化后的版本），然后按回车继续..."
read -r _

echo "采集 $EVENT 火焰图：$AFTER"
asprof -d 60 -e "$EVENT" -o collapsed -f "$OUT_DIR/$AFTER.txt" "$PID"

echo
echo "生成差量图..."
if [ ! -d FlameGraph ]; then
  echo "⚠️  未找到 FlameGraph 工具集，正在克隆..."
  git clone --depth 1 https://github.com/brendangregg/FlameGraph 2>/dev/null || {
    echo "❌ 克隆失败，请手动克隆 FlameGraph 后重试"
    exit 1
  }
fi

FlameGraph/difffolded.pl "$OUT_DIR/$BEFORE.txt" "$OUT_DIR/$AFTER.txt" \
  | FlameGraph/flamegraph.pl > "$OUT_DIR/diff-${BEFORE}-vs-${AFTER}.svg"

echo "✅ 差量图 → $OUT_DIR/diff-${BEFORE}-vs-${AFTER}.svg"
echo
echo "读法："
echo "  颜色区分「变多」和「变少」的栈 —— 红色变少的部分就是你优化掉的开销"
echo "  （具体配色取决于 flamegraph.pl 的参数，可用 --colors 调整）"

一个更简单的 diff 方法：比较 flat 输出

# tools/compare-hotspots.py <before-flat.txt> <after-flat.txt>
"""
比较两次 flat 输出的热点变化。
比 SVG 差量图更容易量化（能算出"减少了多少个百分点"）。
"""
import re
import sys


def parse_flat(path):
    """解析 flat 输出：返回 {函数名: 百分比}"""
    result = {}
    with open(path, errors="ignore") as f:
        for line in f:
            # 格式容错：找行首/行中的百分比数字
            m = re.match(r"\s*([\d.]+)\s*%?\s+(.*)", line)
            if m:
                try:
                    pct = float(m.group(1))
                    frame = m.group(2).strip()
                    # 取最后一段作为函数名
                    name = frame.split()[-1] if " " in frame else frame
                    result[name] = result.get(name, 0) + pct
                except ValueError:
                    continue
    return result


def main(before_path, after_path):
    before = parse_flat(before_path)
    after = parse_flat(after_path)

    all_keys = set(before) | set(after)

    print("═" * 92)
    print("热点变化对比（按变化幅度排序）")
    print("═" * 92)
    print()
    print(f"{'函数':<52}{'优化前':>10}{'优化后':>10}{'变化':>12}")
    print("-" * 92)

    rows = []
    for k in all_keys:
        b, a = before.get(k, 0), after.get(k, 0)
        rows.append((a - b, k, b, a))

    # 按"减少最多"排序（负数 = 减少了，好事）
    rows.sort()
    for delta, k, b, a in rows[:15]:
        marker = "✅" if delta < -1 else ("❌" if delta > 1 else "  ")
        print(f"{k[:50]:<52}{b:>9.2f}%{a:>9.2f}%{delta:>+11.2f}%  {marker}")

    print()
    print("─" * 92)
    print("增加最多的（可能是新引入的开销）：")
    for delta, k, b, a in rows[-5:][::-1]:
        if delta > 0.5:
            print(f"  ❌ {k[:60]:<62}{b:>7.2f}% → {a:>7.2f}%  ({delta:+.2f}%)")

    print()
    print("═" * 92)
    print("判读：")
    print("  ✅ 表示该函数的耗占比下降了（优化生效）")
    print("  ❌ 表示上升了（可能是新的瓶颈，或优化引入了副作用）")
    print("═" * 92)


if __name__ == "__main__":
    if len(sys.argv) < 3:
        print("usage: compare-hotspots.py <before-flat.txt> <after-flat.txt>")
        sys.exit(1)
    main(sys.argv[1], sys.argv[2])

三、自动识别形状特征

# tools/analyze-flamegraph.py <collapsed.txt>
"""
从 collapsed 格式分析火焰图的形状特征。

collapsed 格式：每个栈一行
  frame1;frame2;frame3 1234
  （分号分隔栈，最后的数字是采样数）
"""
import sys
from collections import Counter, defaultdict


def load(path):
    stacks = []
    with open(path, errors="ignore") as f:
        for line in f:
            line = line.strip()
            if not line:
                continue
            *frames, count = line.rsplit(" ", 1)
            try:
                stacks.append((frames[0].split(";"), int(count)))
            except ValueError:
                continue
    return stacks


def analyze(stacks):
    total = sum(c for _, c in stacks)
    if total == 0:
        print("❌ 没有采样数据")
        return

    print("═" * 76)
    print(f"火焰图形状分析（总采样 {total}，{len(stacks)} 条栈）")
    print("═" * 76)
    print()

    if total < 100:
        print("⚠️  采样数很少 —— 可能是：① 采样时长太短 ② 权限问题 ③ 服务空闲")
        print("    建议延长 -d 时长或确认采样时正在施压\n")

    # ① 自身耗时排名（叶子帧）
    self_time = Counter()
    for frames, count in stacks:
        self_time[frames[-1]] += count

    print("【① 自身耗时 Top 15】（叶子帧 = 真正在消耗时间的函数）")
    for frame, c in self_time.most_common(15):
        pct = c / total * 100
        bar = "█" * int(pct / 2)
        print(f"  {pct:5.1f}%  {bar} {frame[:60]}")
    print()

    # ② 栈深度分布
    depths = [len(frames) for frames, _ in stacks]
    avg_depth = sum(d * c for (f, c), d in zip(stacks, depths)) / total
    print(f"【② 栈深度】平均 {avg_depth:.1f} 层（最深 {max(depths)}）")
    if avg_depth > 60:
        print("  → 栈很深：可能是框架层级多，或递归")
    print()

    # ③ 关键模式检测
    print("【③ 关键模式检测】")
    patterns = {
        "socketRead/socketWrite（等网络）": ("socketRead", "socketWrite", "SocketInputStream"),
        "等数据库（JDBC/PG）": ("jdbc", "postgresql", "QueryExecutor", "PgConnection"),
        "等连接池": ("HikariPool", "getConnection"),
        "锁等待": ("park", "Unsafe.park", "LockSupport", "monitor"),
        "文件 IO（日志）": ("FileOutputStream", "FileDispatcher", "Files.write"),
        "序列化": ("Jackson", "serializ", "writeValue", "Json"),
        "正则": ("Pattern.compile", "Matcher", "Regex"),
        "GC": ("G1", "ZGC", "gc", "Collector"),
        "协程调度": ("kotlinx.coroutines", "DispatchedTask"),
        "字符串处理": ("StringBuilder", "String.format", "String.concat"),
    }
    for label, keywords in patterns.items():
        hits = [(f, c) for f, c in self_time.items() if any(k.lower() in f.lower() for k in keywords)]
        if hits:
            total_pct = sum(c for _, c in hits) / total * 100
            print(f"  {total_pct:5.1f}%  {label}")
    print()

    # ④ 形状判定
    print("【④ 形状判定】")
    top_frame, top_count = self_time.most_common(1)[0]
    top_pct = top_count / total * 100

    if top_pct > 25:
        print(f"  → 存在明显热点：{top_frame[:50]}（{top_pct:.1f}%）")
        print(f"     这是「宽而平」形状，是优化的好目标")
    elif avg_depth > 40:
        print(f"  → 深调用链（平均 {avg_depth:.0f} 层），时间分散")
        print(f"     如果底部是等待类调用（socketRead 等），问题在链的末端")
    else:
        print(f"  → 分布较均匀，无明显单点热点")
        print(f"     可能是多因素共同作用，或瓶颈在进程外（网络/网关/上游）")

    if total < 100:
        print(f"\n  ⚠️  采样太少（{total}），以上判定不可靠")

    print("═" * 76)


if __name__ == "__main__":
    load_path = sys.argv[1] if len(sys.argv) > 1 else "cpu.collapsed"
    analyze(load(load_path))

四、完整工作流

#!/usr/bin/env bash
# tools/flamegraph-workflow.sh <PID> <EXP_ID>
#
# 完整的火焰图分析工作流：采四类 + 分析 + 生成报告
set -uo pipefail

PID="${1:?usage: flamegraph-workflow.sh <pid> <exp_id>}"
EXP_ID="${2:?}"
DIR="docs/experiments/${EXP_ID}/results/flamegraph"
mkdir -p "$DIR"

echo "═══ 1. 采集四类火焰图（各 30 秒）═══"
for E in cpu wall alloc lock; do
  echo "  采集 $E ..."
  asprof -d 30 -e "$E" -f "$DIR/$E.html" "$PID" > /dev/null 2>&1
  asprof -d 30 -e "$E" -o collapsed -f "$DIR/$E.collapsed" "$PID" > /dev/null 2>&1
done

echo
echo "═══ 2. 形状分析 ═══"
for E in cpu wall alloc lock; do
  echo
  echo "───────── $E ─────────"
  python3 tools/analyze-flamegraph.py "$DIR/$E.collapsed" | head -40
done

echo
echo "═══ 3. 快速热点排名 ═══"
for E in cpu wall; do
  echo
  asprof -d 10 -e "$E" -o flat -f "$DIR/$E-flat.txt" "$PID" > /dev/null 2>&1
  echo "── $E Top 10 ──"
  head -12 "$DIR/$E-flat.txt"
done

echo
echo "✅ 完成 → $DIR"
echo
echo "下一步："
echo "  ① 打开 HTML 文件确认形状"
echo "  ② 用 compare-hotspots.py 对比优化前后"
echo "  ③ 填进实验档案的「证据」章节"

五、动手改造

改动	观察什么
对同一个接口采 cpu 和 wall 两份，都跑 `analyze-flamegraph.py`	对比两份的「关键模式检测」结果——这是"两类现象两条路径"的实证
在优化前后各采一份 flat 输出并对比	`compare-hotspots.py` 会显示哪条链路变短了
把 `analyze-flamegraph.py` 的 `patterns` 加上你自己的框架关键词	适配你的技术栈（比如你的 ORM、你的 HTTP 客户端）
用 `-e wall` 采一份，看「等连接池」的占比	印证第 6.5 节的池化瓶颈
故意在采样期间停止施压	`analyze-flamegraph.py` 会提示「采样数很少」——理解采样需要流量

六、这段代码的局限

analyze-flamegraph.py 的关键词匹配是启发式的：可能误报（比如类名里恰好含 “gc”）或漏报（你的框架名字不在列表里）。
collapsed 格式因 async-profiler 版本而异：本脚本用 frame;frame count 的通用格式，如果版本差异大需要调整解析。
flat 输出格式也不统一：不同版本的表头与列顺序可能不同，compare-hotspots.py 用了容错解析但仍可能不准。
形状判定只是辅助：真正的判读还是要看 HTML 图——脚本只能提示"哪里可能值得看"。

配套代码：稳健统计与异常值归因

Mon, 01 Jan 0001 00:00:00 +0000

5.3 配套代码：稳健统计与异常值归因

对应小节：5.3 重复、抖动与异常值核心：报中位数与四分位距，而不是平均值；异常值要归因，不能随手删。

一、稳健统计（纯 Python，无第三方依赖）

# tools/robust_stats.py <results_dir_or_files...>
"""
对多轮实验结果做稳健统计。

为什么不用平均值：
  - 平均值被异常轮拉动
  - 5 轮结果 93/96/94/210/95 的均值是 117.6，而真实"典型值"是 95
  - 中位数 95 + 四分位距能同时表达"典型值"与"波动范围"
"""
import json
import pathlib
import sys


def median(xs):
    s = sorted(xs)
    n = len(s)
    if n == 0:
        return float("nan")
    return s[n // 2] if n % 2 else (s[n // 2 - 1] + s[n // 2]) / 2


def percentile(xs, q):
    s = sorted(xs)
    if not s:
        return float("nan")
    idx = (len(s) - 1) * q
    lo, hi = int(idx), min(int(idx) + 1, len(s) - 1)
    return s[lo] + (s[hi] - s[lo]) * (idx - lo)


def stdev(xs):
    n = len(xs)
    if n < 2:
        return 0.0
    m = sum(xs) / n
    return (sum((x - m) ** 2 for x in xs) / (n - 1)) ** 0.5


def load_rounds(paths):
    """从 k6 summary json 里加载每轮的关键指标"""
    rounds = []
    for p in paths:
        try:
            m = json.loads(pathlib.Path(p).read_text())["metrics"]
            d = m["http_req_duration"]
            rounds.append({
                "file": pathlib.Path(p).name,
                "qps": m["http_reqs"]["rate"],
                "p50": d.get("med", 0),
                "p95": d.get("p(95)", 0),
                "p99": d.get("p(99)", 0),
                "err": m["http_req_failed"]["rate"],
            })
        except Exception as e:
            print(f"⚠️  跳过 {p}: {e}")
    return rounds


def report(rounds):
    if len(rounds) < 2:
        print("❌ 至少需要 2 轮数据")
        return

    print("═" * 78)
    print(f"稳健统计（{len(rounds)} 轮）")
    print("═" * 78)
    print()

    # 逐轮列出
    print("逐轮结果：")
    print(f"{'轮次':<6}{'QPS':>10}{'P50':>10}{'P95':>10}{'P99':>10}{'错误率':>10}")
    for i, r in enumerate(rounds, 1):
        print(f"{i:<6}{r['qps']:>10.1f}{r['p50']:>10.1f}{r['p95']:>10.1f}{r['p99']:>10.1f}{r['err']:>10.2%}")
    print()

    # 各指标的稳健统计
    print(f"{'指标':<8}{'中位数':>10}{'Q1':>10}{'Q3':>10}{'IQR':>10}{'最小':>10}{'最大':>10}{'CV':>8}")
    print("-" * 78)

    stats = {}
    for key, label in [("qps", "QPS"), ("p50", "P50"), ("p95", "P95"), ("p99", "P99")]:
        vals = [r[key] for r in rounds]
        q1, q3 = percentile(vals, 0.25), percentile(vals, 0.75)
        med = median(vals)
        cv = (stdev(vals) / med * 100) if med else 0.0
        stats[key] = {"median": med, "q1": q1, "q3": q3, "iqr": q3 - q1,
                      "min": min(vals), "max": max(vals), "cv": cv, "values": vals}
        print(f"{label:<8}{med:>10.2f}{q1:>10.2f}{q3:>10.2f}{q3-q1:>10.2f}"
              f"{min(vals):>10.2f}{max(vals):>10.2f}{cv:>7.1f}%")
    print()

    # 异常值检测（Tukey 方法：超出 Q1-1.5*IQR 或 Q3+1.5*IQR）
    print("异常值检测（Tukey 方法，1.5 × IQR）：")
    found_any = False
    for key, label in [("qps", "QPS"), ("p50", "P50"), ("p95", "P95"), ("p99", "P99")]:
        s = stats[key]
        lo, hi = s["q1"] - 1.5 * s["iqr"], s["q3"] + 1.5 * s["iqr"]
        outliers = [(i + 1, v) for i, v in enumerate(s["values"]) if v < lo or v > hi]
        if outliers:
            found_any = True
            for idx, v in outliers:
                direction = "偏高" if v > hi else "偏低"
                print(f"  ⚠️  {label}: 第 {idx} 轮 = {v:.1f}（{direction}，正常范围 {lo:.1f}~{hi:.1f}）")
                print(f"      → 必须解释成因：查环境事件时间线（tools/events-*.log）")
                print(f"      → 不能只因为「不好看」就剔除")
    if not found_any:
        print("  ✅ 未发现异常值")
    print()

    # 与噪声底线的对比提示
    print("═" * 78)
    print("下一步：")
    print("  ① 把上面的 CV 与你的噪声底线对比（第 5.7 节）")
    print("  ② 如果有异常值，去查环境事件时间线，给出成因解释")
    print("  ③ 用 Mann-Whitney U 检验判断与基线的差异是否显著（tools/stats_test.py）")
    print("═" * 78)

    return stats


if __name__ == "__main__":
    if len(sys.argv) < 2:
        print("usage: robust_stats.py <round-*.json>... 或 <results_dir>")
        sys.exit(1)

    arg = sys.argv[1]
    if pathlib.Path(arg).is_dir():
        paths = sorted(pathlib.Path(arg).glob("round-*.json")) or sorted(pathlib.Path(arg).glob("*.json"))
    else:
        paths = [pathlib.Path(p) for p in sys.argv[1:]]

    report(load_rounds(paths))

二、异常值归因模板

## 异常值归因记录

### 异常概况
- 轮次：第 4 轮
- 异常指标：P99 = 210 ms（其余 4 轮 93–96 ms）
- 偏离幅度：+120%

### 排查过程
1. **环境事件时间线**（`events-4.log`）
   - T+2:15 检测到 `logrotate` 进程运行
   - T+2:18 磁盘写入速率从 5 MB/s 上升到 80 MB/s
   - T+2:40 logrotate 结束
   - ⚠️ 第 4 轮的压测窗口是 T+2:00 ~ T+3:00 → **时间吻合**

2. **服务端数据**
   - GC 日志：未见异常停顿（与正常轮一致）
   - wall 火焰图：大量栈停在 `FileOutputStream.write`（日志刷盘）
   - 连接池 pending：全程为 0（排除数据库方向）

3. **可复现性验证**
   - 重跑 3 次：异常未再出现
   - 手动触发 `logrotate` 再压测：**异常复现**

### 归因结论
**环境异常**（日志轮转导致的磁盘 IO 争抢）。已通过手动复现验证。

### 处理
- 剔除第 4 轮，用其余 4 轮的中位数（94.5 ms）
- 修正实验流程：实验期间临时调大 logrotate 阈值，或避开轮转时刻
- 记录进假设台账：H7「日志轮转会造成 P99 尖刺」→ **已验证（成立）**

关键：「手动复现」是归因的最强证据——它把「怀疑」变成了「确认」。

配套代码：集成基准与全链路压测

Mon, 01 Jan 0001 00:00:00 +0000

3.3 配套代码：集成基准与全链路压测

对应小节：3.3 集成基准与全链路两层各一份代码：集成基准（单服务完整启动）与全链路 k6（多进程/多机）。

一、集成基准：单服务完整启动

// src/test/kotlin/bench/IntegrationBenchmark.kt
package bench

import io.ktor.client.*
import io.ktor.client.engine.cio.*
import io.ktor.client.request.*
import io.ktor.server.engine.*
import io.ktor.server.netty.*
import kotlinx.coroutines.*
import kotlin.system.measureNanoTime

/**
 * 集成基准：把服务完整启动起来测。
 *
 * 与组件基准的区别：
 *   ✅ 覆盖 拦截器 → 鉴权 → 参数校验 → 事务 → 多 Repository → 序列化 的完整链路
 *   ✅ 能观察连接池在并发下的行为
 *   ❌ 不含网络与网关（那是全链路的事）
 *   ❌ 闭环模型会低估尾延迟（第 0 章 0.6 节）
 */
object IntegrationBenchmark {

    @JvmStatic
    fun main(args: Array<String>) = runBlocking {
        // ① 完整启动服务（真实端口，不用 testApplication —— 后者会略过一些真实开销）
        val server = embeddedServer(Netty, port = 8080) {
            app.module()                       // 你的 Application.module()
        }.start(wait = false)

        val client = HttpClient(CIO) {
            engine { maxConnectionsCount = 256 }
        }

        try {
            // ② 独立预热阶段：JIT + 连接池 + 缓存（数据不计入统计）
            println("预热中（60 秒，不计入统计）...")
            runLoad(client, concurrency = 8, durationMs = 60_000, record = false)

            // ③ 正式测量
            println("\n正式测量：并发 8，持续 30 秒")
            val latencies = runLoad(client, concurrency = 8, durationMs = 30_000, record = true)

            report(latencies)
        } finally {
            client.close()
            server.stop(1_000, 5_000)
        }
    }

    /**
     * 闭环并发压测（VU 模型）。
     * ⚠️ 已知局限：服务端变慢时会自动降压，尾延迟被低估。
     *    这里用它是因为「与组件基准做相对比较」足够，且实现简单。
     *    要测真实尾延迟请用 k6 的开环模型（见下方）。
     */
    private suspend fun runLoad(
        client: HttpClient,
        concurrency: Int,
        durationMs: Long,
        record: Boolean,
    ): LongArray = coroutineScope {
        val collector = if (record) java.util.concurrent.ConcurrentLinkedQueue<Long>() else null

        val jobs = (0 until concurrency).map {
            launch(Dispatchers.IO) {
                val deadline = System.currentTimeMillis() + durationMs
                while (System.currentTimeMillis() < deadline) {
                    val ns = measureNanoTime {
                        client.get("http://127.0.0.1:8080/orders/1")
                    }
                    collector?.add(ns)
                }
            }
        }
        jobs.joinAll()

        (collector?.toLongArray() ?: LongArray(0)).also { it.sort() }
    }

    private fun report(sorted: LongArray) {
        if (sorted.isEmpty()) return
        fun pct(q: Double) = sorted[((sorted.size - 1) * q).toInt()].toDouble() / 1000
        println("样本数: ${sorted.size}")
        println("P50 = %.1f us".format(pct(0.50)))
        println("P95 = %.1f us".format(pct(0.95)))
        println("P99 = %.1f us".format(pct(0.99)))
        println("max = %.1f us".format(sorted.last() / 1000.0))
        println()
        println("⚠️ 这是闭环模型的结果，只用于「与组件基准比较」，不能用于验收 SLO。")
    }
}

集成基准要观察的三件事：

重复、抖动与异常值

Mon, 01 Jan 0001 00:00:00 +0000

5.3 重复、抖动与异常值

上一节：5.2 预热、稳态与运行时长　|　下一节：5.4 环境隔离清单配套代码：05-experiment-design/03-repetition-and-outliers

一句话结论

一次运行的结果不是结论，是一个样本。 你至少需要 3–5 轮重复才能看到分布。而异常值不能"觉得不好看就删"——必须能解释成因，否则它可能正是你需要面对的真实情况。

一、用「投篮命中率」理解重复

判断一个球员的命中率，你不会只看他投一次：

做法	问题
只投 1 次（进了）	可能是运气
只投 1 次（没进）	也可能是运气
投 100 次	开始有意义
投 100 次，但把没进的都算作"手滑了"	自欺

性能实验完全一样：

❌ 「跑了一次，P99 = 95ms，达标」
✅ 「跑了 5 次，P99 = 93, 96, 94, 210, 95 ms，中位数 95ms」
                                  ↑ 这一轮需要解释

二、该跑几轮

轮数	能做什么	局限
1 轮	只能发现「明显的崩溃」	无法区分差异与噪声
3 轮	能看到波动范围，取中位数	推荐的最低要求
5 轮	能做简单的统计检验（非参数检验需要足够样本）	时间成本
10 轮以上	能估算置信区间	只在关键决策时值得

权衡：3–5 轮是性价比最高的区间。如果环境噪声大（CV > 10%），增加轮数的收益不如先改善环境。

集成基准与全链路：什么时候值得

Mon, 01 Jan 0001 00:00:00 +0000

3.3 集成基准与全链路：什么时候值得

上一节：3.2 组件基准　|　下一节：3.4 负载曲线配套代码：03-test-pyramid/03-integration-and-e2e

一句话结论

集成基准补的是「单服务完整启动」这一层；全链路压测补的是「排队与跨服务放大」。 全链路很贵，只该用在验收 SLO、测容量、验证级联行为这三件事上——绝不能用来定位瓶颈。

一、用「转鼓试验」和「真实路试」理解这两层

	转鼓试验（集成基准）	真实路试（全链路）
在哪跑	实验室，整车在转鼓上	真实道路
有什么	真车、真发动机、真轮胎	加上真实天气、交通、坡度、油品
能发现	整车级别的匹配问题（变速箱逻辑、散热）	高速风噪、长上坡过热、堵车时的油耗
成本	中	高
可重复性	高（环境可控）	低（天气、交通不可控）

对应到后端：

	集成基准	全链路负载
范围	单服务完整启动 + 真实依赖	多服务 + 网关 + 真实网络
能发现	连接池、事务边界、AOP/拦截器开销、启动预热、序列化链路	排队、级联超时、限流配置、跨服务放大
成本	分钟级	十分钟到小时级
可重复性	高	中（受环境噪声影响大）

二、集成基准：填补「单服务完整」的空白

组件基准只测一个 Repository 或一个方法。但真实请求还会经过：

HTTP 层 → 拦截器/中间件 → 鉴权 → 参数校验 → 业务逻辑 → 事务 → 多个 Repository → 序列化 → 响应

这些环节的成本（拦截器链、事务开启/提交、日志、指标埋点）只有把服务完整启动起来才能测到。

`explicit` 与 `[[nodiscard]]`

Mon, 01 Jan 0001 00:00:00 +0000

一、`explicit`——防止隐式转换

struct StringWrapper {
    /* explicit */ StringWrapper(const char* s) { ... }
};

void process(StringWrapper sw);

// 如果没有 explicit：
process("hello");  // 隐式构造 StringWrapper → 可能不是你想要的！

// 如果有 explicit：
process("hello");  // ❌ 编译错误，必须显式构造
process(StringWrapper("hello"));  // ✅

规则：所有单参数构造函数都应该加 explicit，除非你真的想让隐式转换发生（极少见）。

二、`[[nodiscard]]`——返回值不要被忽略

struct Error { int code; };

class Config {
public:
    [[nodiscard]] Error load(const std::string& path) {
        // 如果加载失败，返回错误
        return Error{42};
    }
};

Config cfg;
cfg.load("config.ini");  // ⚠️ 编译器警告：返回值被忽略！

// 必须处理：
Error e = cfg.load("config.ini");  // ✅

哪些返回值应该加 [[nodiscard]]？

`std::span` —— 连续内存的"借用"视图

Mon, 01 Jan 0001 00:00:00 +0000

string_view 是"字符的 view"；span 是"任意类型的 view"。

解决什么问题？

// ❌ 传统函数签名：零散的指针+长度
void process(const float* data, size_t count);
// 调用者容易传错：process(arr, 1000) // 如果 arr 只有 500 个元素呢？

// ✅ span：长度自带
void process(std::span<const float> data);
// 调用者：process(arr); // 自动推导长度
// 或者：process(vec);   // vector 也能直接传

span 的内存结构：

span<float> s(vec);
栈上占用 16 字节（64 位）:
+──────────────────+──────────────────+
| ptr (8字节)       | size (8字节)      |
| 指向 vec.data()   | vec.size()        |
+──────────────────+──────────────────+

没有任何堆分配，不拥有数据，只是一个指针 + 长度。

什么时候用？

// 1. 替代 (T* data, size_t len) —— 最常见的场景
void process(std::span<const int> data);

// 2. 需要同时支持 vector / array / C 数组的函数
void sort_all(std::span<int> data) {
    std::sort(data.begin(), data.end());
}

std::vector<int> v = {3, 1, 4, 1, 5};
int arr[] = {2, 7, 1, 8};
sort_all(v);    // ✅ vector
sort_all(arr);  // ✅ C 数组（自动推导长度为 4）

// 3. 子范围操作
auto first_half = s.first(s.size() / 2);  // 取前半，不拷贝
auto second_half = s.last(s.size() / 2);   // 取后半
auto middle = s.subspan(2, 5);             // 取 [2, 7)

和 `string_view` 完全一样的生命周期规则

delete 原始数组后，span 悬垂。

`std::tuple` 的编译期遍历

Mon, 01 Jan 0001 00:00:00 +0000

一、解决什么问题？

std::tuple 的元素类型不同，不能用普通 for 循环遍历。

需求：我想对 tuple 的每个元素调用同一函数。

std::tuple<int, double, std::string> t = {1, 2.0, "hello"};
// 我想实现：
// print(get<0>(t));
// print(get<1>(t));
// print(get<2>(t));
// 但不能写 for (int i = 0; i < 3; i++) print(get<i>(t)); ← 编译 error，i 不是编译期常量

二、`if constexpr` + 递归——编译期循环

template <typename Tuple, typename Func, size_t I = 0>
void tuple_for_each(const Tuple& t, Func&& f) {
    if constexpr (I < std::tuple_size_v<Tuple>) {
        f(std::get<I>(t));                             // 处理第 I 个元素
        tuple_for_each<Tuple, Func, I + 1>(t,           // 递归处理下一个
                                           std::forward<Func>(f));
    }
    // if constexpr 的关键：当 I >= tuple_size 时，
    // 这个递归调用分支的代码直接被编译器丢弃，
    // 不会产生无限递归！
}

编译器展开：

💡 记录到笔记的通关口诀（用于面试一秒作答）

Mon, 01 Jan 0001 00:00:00 +0000

左值 (lvalue)：有名、有固定地址，生命周期长，只能复制，不能偷。
纯右值 (prvalue)：无名、无固定地址（临时工），生命周期极短，可以直接偷。
将亡值 (xvalue)：有名、有固定地址，但被人用 std::move 盖上了“即将死亡”的戳，属于合法允许被偷的左值。

多看一眼上面的第 4 点（终极陷阱测试），这是大厂面试（如腾讯、网易游戏）极度爱考的变态细节：“右值引用变量本身，其实是一个左值”。

Core Dump 分析

Mon, 01 Jan 0001 00:00:00 +0000

一、生成和应用场景

# 设置 core dump 文件大小（不限）
ulimit -c unlimited

# 运行程序，如果崩溃会生成 core 文件
./my_server

# 程序崩了，生成 core 文件
ls -la core.*
# 输出：core.12345   ← pid=12345 的 core dump

# 用 GDB 加载
gdb ./my_server core.12345

(gdb) bt
#0  handle_request() at server.cpp:123
#1  worker_loop() at threadpool.cpp:45
#2  ...
# 看到崩溃在第 123 行

(gdb) print request
# 看到请求数据，分析为什么会导致第 123 行崩溃

二、生产环境最有用的场景

你有一个线上服务，平时不好打断，但偶尔崩一次。

方案：
  1. 在生产环境设置 ulimit -c unlimited。
  2. 程序 crash 后 core 文件保留在磁盘上。
  3. 把 core 拉回开发机分析（注意不要包含用户敏感数据）。

  # 检查 core dump 是否正常生成
  cat /proc/sys/kernel/core_pattern
  # 常见配置：
  # /var/lib/systemd/coredump/core.%p  → systemd 管理的 core
  # core                                → 当前目录生成 core 文件

  # 如果看不到 core 文件，检查：
  ulimit -c              # 是不是 0（需要改成 unlimited）
  df -h /tmp             # 磁盘满了？core 文件写不进去

JFR 与 jcmd：能常开的剖析与无依赖应急

Mon, 01 Jan 0001 00:00:00 +0000

4.4 JFR 与 jcmd：能常开的剖析与无依赖应急

上一节：4.3 async-profiler　|　下一节：4.5 系统级观测配套代码：04-toolchain/04-jfr-and-jcmd

一句话结论

JFR（JDK Flight Recorder）是唯一适合在生产环境长期开着的剖析工具（开销约 1%），它记录的是「系统发生了什么」的完整事件流。jcmd 则是零依赖的应急手段——什么都不用装，出问题时随手可用。

一、用「24 小时动态心电图」理解 JFR

普通心电图只在医院做几分钟。但有些心脏问题只在特定时刻发作——所以医生给病人戴一个24 小时动态心电图记录仪：

动态心电图	JFR
长期佩戴，开销极小	生产环境常开，约 1% 开销
持续记录，出事时回放	滚动录制，事后 dump
记录多种信号（心率、心律、ST 段）	记录几十类事件（GC、锁、IO、异常…）
不能当场看结果，要事后分析	用 JDK Mission Control 分析

关键价值：性能问题往往偶发且不可复现。JFR 让你能在问题发生后回到现场。

二、JFR 的三种用法

用法一：出问题时临时录一段

PID=$(jcmd | grep app.jar | awk '{print $1}')

# 录制 120 秒，输出到文件
jcmd "$PID" JFR.start name=perf settings=profile duration=120s filename=/tmp/perf.jfr

# 结束后自动停止；也可以手动
jcmd "$PID" JFR.stop name=perf

用法二：滚动录制（推荐用于生产）⭐

# 保持最多 256MB / 1 小时的事件，超出后自动丢弃最旧的
jcmd "$PID" JFR.start name=rolling settings=profile maxsize=256m maxage=1h

# 出问题时立刻 dump（不用等录制结束）
jcmd "$PID" JFR.dump name=rolling filename=/tmp/incident-$(date +%s).jfr

# 不再需要时停止
jcmd "$PID" JFR.stop name=rolling

这是最实用的模式：平时默默记录，出事时 dump 出「过去 1 小时」的事件。

SLO 的四要素写法

Mon, 01 Jan 0001 00:00:00 +0000

1.4 SLO 的四要素写法

上一节：1.3 测量点　|　下一节：1.5 延迟预算配套代码：01-metrics-and-slo/04-writing-slo

一句话结论

「P99 < 200 ms」不是一个 SLO，只是一半句话。 完整的 SLO 必须包含四要素：指标 + 阈值、负载与数据前提、测量点、持续时长。少了任何一项，验收时都会吵架（而且通常是上线后才吵）。

一、用「验收合同」理解 SLO

假设你要装修房子，和施工队签合同。你在合同上写：

「装修要好。」

施工队会问你一堆问题：

你的原话	施工队必须追问	对应 SLO 的要素
「装修要好」	「哪方面好？水电？墙面？隔音？」	指标
「墙面要平」	「多平算平？误差几毫米？」	阈值
「要平」	「房子多大？什么结构？现在什么状况？」	负载与数据前提
「要平」	「用谁的尺子量？从哪量到哪？」	测量点
「要平」	「验收时看一次，还是住半年后还得平？」	持续时长

SLO 就是你和系统签的验收合同。 一份只有「装修要好」的合同，结局一定是扯皮。

二、四要素详解

要素 1：指标 + 阈值

必须明确是哪个指标（P99？P95？错误率？吞吐？）和具体数值。

❌ 模糊	✅ 明确
「响应要快」	P99 < 200 ms 且 P999 < 500 ms
「要稳定」	错误率 < 0.1%，超时率 < 0.05%
「能扛住」	稳定支撑 500 RPS

要点：延迟类 SLO 至少写两个分位数（P99 + P999，或 P95 + P99）。只写一个分位数时，你不知道「剩下那 1% 有多糟」。

五、什么时候不该用 Ranges？

Mon, 01 Jan 0001 00:00:00 +0000

// ❌ 场景 1：你需要多次遍历同一结果
auto filtered = data | std::views::filter(...);
for (int x : filtered) { ... }  // 第一次遍历：计算
for (int x : filtered) { ... }  // 第二次遍历：重新计算（性能浪费！）

// ✅ 应该把结果收集到容器中
auto filtered_vec = data
    | std::views::filter(...)
    | std::ranges::to<std::vector>();  // C++23

// ❌ 场景 2：你的操作有副作用，且依赖执行顺序
// filter/transform 的计算顺序不是从左到右严格保证的

// ✅ 什么时候应该无脑用 Ranges？
// 当你只需要遍历一次，且不需要持有结果时——天生适合 Ranges

五、实战：什么时候自定义 Concept？

Mon, 01 Jan 0001 00:00:00 +0000

场景：你有一个序列化框架，需要约束参数类型必须支持 serialize 和 deserialize：

// 定义业务相关的 Concept
template <typename T>
concept Serializable = requires(T obj, std::ostream& os, std::istream& is) {
    { obj.serialize(os) } -> std::same_as<void>;
    { obj.deserialize(is) } -> std::same_as<void>;
};

// 使用——读代码的人一眼就知道 T 需要什么能力
template <Serializable T>
void save_to_file(const T& obj, const std::string& path) {
    std::ofstream os(path);
    obj.serialize(os);
}

template <Serializable T>
T load_from_file(const std::string& path) {
    T obj;
    std::ifstream is(path);
    obj.deserialize(is);
    return obj;
}

如果不自定义 Concept 会怎样？

性能测量方法论

Mon, 01 Jan 0001 00:00:00 +0000

这是把前面所有理论落地到实践的工具箱。没有测量，你的一切优化都是盲人摸象——你以为快了，实际上可能更慢了；你以为瓶颈在 A，实际上在 B。

我们不讲空话，直接上**硬件性能计数器（PMC）和火焰图（Flamegraph）**这两把“屠龙刀”。

1. 性能测量的核心工具：硬件性能计数器（PMC）

PMC（Performance Monitoring Counters） 是 CPU 内部的硬件计数器，可以精确记录各种微架构事件，如：

Cache Miss（L1/L2/L3 未命中次数）
TLB Miss（地址翻译未命中次数）
分支预测失败（Branch Misprediction）
CPU 周期数（Cycles）
指令执行数（Instructions）
内存带宽（Memory Bandwidth）

这些计数器是纯硬件的，不依赖操作系统采样，几乎没有性能开销（<1%）。

硬件实现

[CPU 核心]
    │
    ├── 执行单元（ALU）
    │   └── 计数器：指令执行数、周期数
    │
    ├── 缓存系统（L1/L2/L3）
    │   └── 计数器：Cache Miss、Cache Hit、缓存行传输
    │
    ├── MMU / TLB
    │   └── 计数器：TLB Miss
    │
    └── 分支预测器
        └── 计数器：分支预测成功/失败

2. Linux `perf`：最强大的硬件性能分析工具

perf 是 Linux 内核自带的性能分析工具，封装了 CPU 的 PMC，可以精确测量程序的硬件行为。

步骤三：建立基线与噪声底线

Mon, 01 Jan 0001 00:00:00 +0000

9.4 步骤三：建立基线与噪声底线

上一节：9.3 步骤二：搭服务与数据　|　下一节：9.5 步骤四：容量曲线与拐点用到：第 4 章（观测）、第 5.7 节（噪声底线）配套代码：09-capstone/04-step3-baseline 产出：experiments/E09-baseline/（基线数据 + 噪声底线）

一句话结论

这一步衡量的是「你的测量工具有多准」。 在测出噪声底线之前，任何"优化了 X%“的说法都是没有依据的——因为你不知道 X% 是不是噪声。

一、三件事，按顺序做

① 观测回路验证（10 分钟）
   → 确认指标、日志、火焰图三条链路都通
        ↓
② 基线测量（30 分钟）
   → 在 SLO 目标负载下跑 3 轮，得到基线数据
        ↓
③ 噪声底线测量（1 小时）
   → 代码不变，重复 10 轮，得到"我的尺子有多准"

顺序不能反：如果观测回路没通，基线数据就是不可信的。

二、① 观测回路验证

#!/usr/bin/env bash
# tools/verify-observability.sh
set -uo pipefail

echo "═══ 观测回路验证 ═══"
echo

# ① 四层指标
echo "① 检查四层指标"
M=$(curl -s --max-time 5 localhost:8080/metrics)
check() { echo "$M" | grep -qE "$1" && echo "   ✅ $2" || echo "   ❌ $2（缺这组）"; }
check "^app_requests_total"            "业务层"
check "^app_request_duration.*bucket"  "延迟层（直方图）"
check "^jvm_memory_used_bytes"         "资源层"
check "^db_pool_pending"               "饱和度层 ⭐"
check "^app_cache_hit_rate"            "缓存命中率"

echo
echo "② 检查桶边界（应该在 100ms 附近加密）"
echo "$M" | grep 'app_request_duration_seconds_bucket' | grep -oE 'le="[0-9.]+"' | head -12 | sed 's/^/   /'

echo
echo "③ 检查指标基数（应该是个位数）"
echo "   序列数: $(echo "$M" | grep -c 'app_request_duration_seconds_bucket')"

echo
echo "④ 检查火焰图能采到"
PID=$(jcmd 2>/dev/null | grep app.jar | awk '{print $1}')
if [ -n "$PID" ]; then
  TMP=$(mktemp)
  asprof -d 5 -e cpu -o collapsed -f "$TMP" "$PID" > /dev/null 2>&1
  LINES=$(wc -l < "$TMP")
  [ "$LINES" -gt 10 ] && echo "   ✅ 火焰图有 $LINES 条栈（压测中采集会更多）" \
                       || echo "   ⚠️  只有 $LINES 条栈（可能没在压测，或权限问题）"
  rm -f "$TMP"
else
  echo "   ⚠️  未找到应用进程"
fi

echo
echo "⑤ 检查 Prometheus 抓取"
curl -sf http://localhost:9090/-/ready > /dev/null && echo "   ✅ Prometheus 就绪" \
                                                   || echo "   ⚠️  Prometheus 未就绪"

关键检查：db_pool_pending 与 app_cache_hit_rate——这两个是后面定位的关键指标，如果没有，后面的分析会缺一大块。

环境隔离清单

Mon, 01 Jan 0001 00:00:00 +0000

5.4 环境隔离清单

上一节：5.3 重复、抖动与异常值　|　下一节：5.5 数据集设计配套代码：05-experiment-design/04-environment-isolation

一句话结论

实验环境里任何「你没关掉的东西」，都会变成数据里的噪声。 而与性能测试不同，噪声不会报错——它只会让你的结论变得不可信，而你往往察觉不到。

一、用「化学实验的洁净室」理解环境隔离

化学实验里，一点灰尘就可能让结果完全偏差。所以：

化学实验室	性能实验
无尘环境	独占的测试机器
恒温恒湿	固定的 CPU 频率、无降频
纯净试剂	真实但固定的数据集
空白对照	基线组
记录环境参数	采集环境元数据

关键差异：化学实验的污染通常是可见的（溶液变色），性能实验的污染是不可见的——你只会看到一个稍微高一点的 P99，然后开始怀疑代码。

二、五类污染源与处理方式

❶ 同一台机器上的其他负载

污染源	影响	处理
压测客户端与服务同机	互相抢 CPU，两个方向都失真	必须分离（最低要求：不同容器 + CPU 限制）
IDE / 浏览器 / 本地开发	抢占 CPU 与内存	关掉
其他服务实例	争抢资源	独占环境
监控 agent	持续采集消耗资源	记录其开销，或降频采样

❷ 机器自身的周期性任务

污染源	频率	表现	处理
数据库 autovacuum	不定	磁盘 IO 尖刺	实验前手动 `VACUUM ANALYZE`，期间可临时调整 `autovacuum` 参数
数据库 checkpoint	不定	IO 抖动	观察 checkpoint 配置与日志时间戳
日志轮转	按大小/时间	磁盘写尖刺	避开轮转时刻，或临时调大阈值
备份任务	通常夜间	全盘 IO 与网络	实验前确认已关闭
`cron` / 定时任务	各种	周期性 CPU/IO	`pgrep -a -f cron` 确认
系统更新	不定	突发 CPU/IO	关闭自动更新

❸ CPU 频率与调度

污染源	影响	处理
CPU governor（节能模式）	频率波动 → 延迟抖动	设为 `performance`
Turbo Boost	前后跑的基准频率不同	要么固定频率，要么全程接受 turbo（关键是一致）
未绑核	线程在不同核间迁移，缓存失效	`taskset` 绑定
超线程干扰	同一物理核上的两个逻辑核互相影响	明确是否启用，并保持一致
NUMA 跨节点	内存访问变慢	`numactl` 绑定

❹ 云环境的不可控因素

污染源	表现	处理
邻居抢占（steal）	`st` 指标高，延迟抖动	换独占型实例；或多次实验取可比时段
网络路径变化	跨 AZ 调用延迟变化	固定可用区；记录网络拓扑
存储 IOPS 配额	IO 突发受限	确认卷类型与 IOPS 上限
宿主机维护	突发迁移	记录实验期间的事件

❺ 实验自身的干扰

污染源	影响	处理
高开销剖析（profiler）	占用 CPU，抬高 P99	基线组和实验组必须用同样的观测配置
详细日志（DEBUG）	同步 IO，可能占 10%+	统一日志级别
`/metrics` 高频抓取	序列化开销	统一 scrape interval
压测机自身瓶颈	实际到达率低于设定值	每次压测先验证到达率（第 4 章 4.1）

三、实验前的检查清单（脚本化）

## 环境检查（实验前逐项确认）

### 机器
- [ ] CPU governor = performance
- [ ] 已绑核（或明确不绑核，并保持一致）
- [ ] 关闭了自动更新
- [ ] 无其他无关进程（`ps aux --sort=-%cpu | head`）
- [ ] `st`（steal）< 1%（多次采样确认）

### 容器
- [ ] CPU limit 与生产一致
- [ ] 内存 limit 与生产一致
- [ ] 无 sidecar 干扰（或已计入）
- [ ] 节流比例 < 1%（`/sys/fs/cgroup/cpu.stat`）

### 数据库
- [ ] autovacuum 状态已知（关闭或已记录）
- [ ] 无长事务（`pg_stat_activity`）
- [ ] 统计信息已更新（`ANALYZE`）
- [ ] 连接数无人抢占

### 服务
- [ ] JVM 参数与生产一致
- [ ] 日志级别一致
- [ ] 观测配置一致（JFR/profiler）
- [ ] 服务已重启（避免上一轮热状态污染）

### 压测
- [ ] 客户端独立机器/容器
- [ ] 脚本已冻结快照
- [ ] 已预热（或明确预热阶段）
- [ ] 到达率可验证

### 记录
- [ ] 环境元数据已采集（第 1 章 1.7）
- [ ] 环境事件时间线已开启记录

四、绑核与频率固定的具体命令

# ① 固定 CPU 频率（Linux）
sudo cpupower frequency-set -g performance
# 验证
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# ② 绑定到指定核（服务用 2-5，压测客户端用 6-7，互不干扰）
taskset -c 2-5 java -jar app.jar
taskset -c 6-7 k6 run loadtest.js

# ③ NUMA 绑定
numactl --cpunodebind=0 --membind=0 java -jar app.jar

# ④ 查看 NUMA 拓扑
numactl --hardware

# ⑤ 容器内限制 JVM 看到的核数（避免线程池过大）
java -XX:ActiveProcessorCount=2 -jar app.jar

# ⑥ 关闭 swap（避免内存压力导致的抖动）
sudo swapoff -a

注意：绑核能降低噪声，但也可能降低吞吐（因为无法利用其他核）。如果实验目的是测「最大吞吐」，绑核会让结果偏低。关键是「一致性」而不是「绝对最优」——基线组和实验组用同样的配置即可。

生产观测：SLI 与错误预算

Mon, 01 Jan 0001 00:00:00 +0000

8.4 生产观测：SLI 与错误预算

上一节：8.3 全链路性能门禁　|　下一节：8.5 告警设计：燃烧率与领先指标配套代码：08-continuous-performance/04-production-observability

一句话结论

错误预算（Error Budget）= 性能的「流量套餐」。 如果 SLO 是 99.9%，那么每月有 0.1% 的请求「允许违约」——这个额度用完了，就该停止发布新功能，先修稳定性。

一、用「手机流量套餐」理解错误预算

你每月有 10 GB 流量：

情况	你的行为
用了 3 GB	随便用，不用担心
用了 7 GB	开始留意，但还能用
用了 9.5 GB	关掉视频，只用必要功能
用完了	限速，或者买加量包

错误预算完全一样：

SLO = 99.9%（30 天窗口）
→ 错误预算 = 0.1% 的请求可以违约
→ 按 100 万请求/天算，30 天共 3000 万请求
→ 预算 = 3 万个请求可以失败

用了 1 万（33%）→ 健康，正常发布
用了 2.4 万（80%）→ 警告，谨慎发布
用了 3 万（100%）→ 冻结发布，先修稳定性

关键洞察：错误预算把「性能」变成了一个可以量化管理的资源——而不是一个模糊的「要快、要稳」。

用 Little's Law 估算容量

Mon, 01 Jan 0001 00:00:00 +0000

0.4 用 Little’s Law 估算容量

上一节：0.3 延迟是分布，不是数字　|　下一节：0.5 为什么 90% 利用率已经很危险配套代码：00-introduction/04-littles-law

一句话结论

「店里同时有多少人」= 「每分钟进来多少人」× 「每个人待多久」。 这个小学除法能让你在动手压测之前就算出：连接池要多大、线程要多少、协程并行度设多少。

一、先说人话：小饭馆的例子

你开了一家小饭馆：

平均每分钟进来 5 个客人（到达率 λ）；
每个客人平均坐 20 分钟（停留时间 W）。

那么店里平均同时坐着多少人？

5 人/分钟 × 20 分钟 = 100 人

显然——每分钟进来的人 × 每人待的分钟数 = 店里同时有人数。

这个「显然」的结论，就是 Little’s Law（利特尔法则）。它之所以重要，是因为把「客人」换成「请求」、把「座位」换成「连接」，它就变成了容量估算公式。

二、公式与每个符号的人话含义

L = λ × W

符号	名字	人话	在这个公式里的单位
L	并发数 / 在途请求数	任意时刻系统里「正在被处理、还没结束」的请求个数	个
λ	到达率	每秒有多少个请求进来	req/s
W	驻留时间	一个请求从进来到结束平均花多久	秒

单位换算的直觉：req/s × s = 个——秒被约掉了，剩下的就是「同时有几个」。

第一阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

RGB → YUV：
    把亮度（Y）和颜色（UV）分离
    转换是可逆的（伤害误差 < 1/255）

YUV 省带宽的原理：
    人眼对颜色不敏感 → UV 分辨率可以降低
    4:2:0 比 RGB 省 50% 带宽，视觉效果几乎不变

内存布局（C++ 开发者最常犯错的地方）：
    YUV420P：YYYY...UU...VV...（三个平面）
    NV12：   YYYY...UVUV...（Y 平面 + 交错 UV 平面）
    linesize 可能 ≠ width，永远用 linesize 跳过 padding

第一阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

perf stat → 统计计数：IPC、Cache Miss、分支预测
perf record/report → 采样：哪个函数最占 CPU
perf top → 实时监控：线上救火
perf c2c → 伪共享检测：多线程性能不线性扩展时

核心优化思路：
    IPC < 1 → 看 Cache Miss / 分支预测
    Cache Miss 高 → 改数据结构（连续内存/对齐）
    分支预测差 → 排序/分支消除/[[likely]]

第二阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

编码的本质：
    帧内预测（空间冗余）+ 帧间预测（时间冗余）
    + DCT（频域变换）
    + 量化（丢细节）
    + 熵编码（无损压缩）

I/P/B 帧：
    I 帧：完整编码，可随机访问，体积最大
    P 帧：参考前一帧，只存差异
    B 帧：参考前后帧，压缩率最高，但需要重新排序

DCT 的作用：
    把像素变换为频率系数
    平坦区域 → 只有一个 DC 系数有用
    量化后大部系数为 0 → 可以高效压缩

第八阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

Callgrind（指令级分析）：
    慢 20-30x，但精确到每条指令
    告诉你"哪个函数指令数最多、Cache Miss 最高"
    可视化工具：KCachegrind

Massif（堆内存分析）：
    找到"哪个函数分配了最多内存"
    需要优化内存使用时使用

Helgrind / DRD（数据竞争检测）：
    不需要重编译的 TSan 替代方案
    适合分析第三方库或已编译好的二进制

perf vs Callgrind 怎么选？
  粗略定位热点 → perf record（快，但可能漏掉低频执行的热路径）
  精确优化 → Callgrind（慢，但告诉你完整信息）
  验证优化效果 → perf stat（只需要对比 IPC 和 Cache Miss 就行了）

第四阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

Google Benchmark 的核心用法：
    for (auto _ : state) 包裹被测代码
    DoNotOptimize 防止编译器优化掉测试
    ClobberMemory 防止内存操作被优化

参数化测试：
    Arg(N) → 指定单个参数
    Range(A, B) → 自动生成几何序列的参数

对比报告：
    compare.py before.json after.json
    精准看到优化前后的百分比变化

面试价值：
    "我的日志库 benchmark 显示比 spdlog 快 10 倍，生产路径延迟 52ns"
    有数字支撑的技术决策，比说"我的日志库很快"有说服力得多

线程与协程快照

Mon, 01 Jan 0001 00:00:00 +0000

6.4 线程与协程快照

上一节：6.3 火焰图读法　|　下一节：6.5 瓶颈模式库（一）：池化类配套代码：06-analysis-and-profiling/04-thread-and-coroutine-dumps

一句话结论

一张线程快照没有价值，连续多张才有。 单张快照告诉你「此刻谁在哪」（可能只是路过），多张对比才能看出「谁一直卡在那里」。这就是「瞬时状态」与「持续问题」的区别。

一、用「工厂巡检拍照」理解快照

你去工厂检查为什么产线慢了。拍一张照片：

照片里 3 个工人站着不动。
但这可能只是巧合——他们可能刚好在等下一个零件。

连拍 5 张（每 3 秒一张）：

5 张照片里，同样的 3 个工人站在同一个位置不动。
而其他工人都在移动。
结论：这 3 个工人被卡住了。

线程快照完全一样：单张是「瞬时状态」，多张才能识别「持续阻塞」。

二、线程状态的五种含义

状态	含义	大量出现说明
`RUNNABLE`	正在运行或等待 CPU	CPU 饱和，或在自旋
`BLOCKED (on object monitor)`	等 monitor 锁	锁竞争
`WAITING (parking)`	无限期等待（`LockSupport.park`）	等锁、等队列、等任务
`TIMED_WAITING`	有时限等待（`sleep`、`await(timeout)`）	有超时等待（可能是重试退避）
`WAITING (on object monitor)`	`Object.wait()`	等条件变量

关键栈特征速查

栈里出现	含义
`HikariPool.getConnection`	连接池排队
`socketRead0` / `socketWrite0`	等网络（数据库/下游）
`Unsafe.park` / `LockSupport.park`	等锁或等任务
`LinkedBlockingQueue.take`	线程池空闲（正常）或队列空
`ArrayBlockingQueue.put`	队列满，生产者被阻塞（背压生效）
`Object.wait`	等条件变量
`Thread.sleep`	主动睡眠（重试退避或轮询）
`FileOutputStream.write`	同步日志刷盘
`classloader` 相关	类加载锁（启动期常见）

三、多个快照的对比方法

方法一：统计「持续存在」的栈

PID=$(jcmd | grep app.jar | awk '{print $1}')

# 连续取 5 份，间隔 3 秒
for i in $(seq 1 5); do
  jcmd "$PID" Thread.print > "threads-$i.txt"
  sleep 3
done

# 统计哪些栈在【所有快照】里都出现
comm -12 <(grep -E '^\s+at ' threads-1.txt | sort -u) \
         <(grep -E '^\s+at ' threads-2.txt | sort -u) | \
comm -12 - <(grep -E '^\s+at ' threads-3.txt | sort -u) | \
comm -12 - <(grep -E '^\s+at ' threads-4.txt | sort -u) | \
comm -12 - <(grep -E '^\s+at ' threads-5.txt | sort -u) | \
sort | uniq -c | sort -rn | head -20

输出示例：

缓存：三重防护与三重代价

Mon, 01 Jan 0001 00:00:00 +0000

7.4 缓存：三重防护与三重代价

上一节：7.3 并发与并行　|　下一节：7.5 背压与韧性配套代码：07-optimization-and-validation/04-caching

一句话结论

缓存是"用一致性和复杂度换延迟"的交易，不是免费的加速。而且它有个反直觉的性质：能改善 P50，却可能让 P99 变差（因为未命中的那部分请求变慢了）。所以缓存必须有防护、有指标、有代价评估。

一、用「把工具放手边」理解缓存

你在修车，工具都在 20 米外的工具间。两种做法：

做法	好处	代价
每次去工具间拿	永远是"最新最全"的	慢
把常用工具放手边	快	工具会占地方；可能不是最新的；要找地方放

缓存完全一样：快，但要占内存、可能过期（数据不一致）、需要管理（失效逻辑）。

二、三个收益

收益	说明	典型量级
降低延迟	内存读取（纳秒）vs 数据库查询（毫秒）	10–1000 倍（单次）
提高吞吐	同样硬件能扛更多请求	取决于命中率
保护下游	减少打到数据库的请求	按命中率折算

注意第一项：单次缓存的收益是巨大的（纳秒 vs 毫秒），但整体收益取决于命中率：

命中率 90% → 90% 的请求快 100 倍，10% 的请求慢一点（缓存开销）
命中率 50% → 一半快，一半慢——P99 可能变差
命中率 10% → 几乎没有收益，但引入了全部复杂度

三、三个代价（必须评估）

❶ 一致性风险 🔴 最危险

场景	后果
缓存更新失败但数据库成功	用户看到旧数据，且不知道会持续多久
多实例缓存不一致	用户刷新两次看到不同结果
缓存过期与写入竞争	旧值覆盖新值（经典的缓存并发问题）

必须回答的问题：

负载曲线：阶梯、恒定、尖峰

Mon, 01 Jan 0001 00:00:00 +0000

3.4 负载曲线：阶梯、恒定、尖峰

上一节：3.3 集成基准与全链路　|　下一节：3.5 浸泡测试配套代码：03-test-pyramid/04-load-profiles

一句话结论

三种负载曲线用来发现三种不同的问题：阶梯加压找拐点，恒定压测验证稳态 SLO，尖峰测试验证弹性与恢复。用错曲线，就会测不出你关心的问题。

一、用汽车测试理解三种路况

路况	负载曲线	测什么
匀速巡航	恒定到达率	稳定工况下的油耗与舒适度
逐步加速到极限	阶梯加压	最高能跑多快、什么时候开始抖动
急加速 + 急刹车	尖峰测试	刹车性能、恢复能力、热衰减

汽车厂商三种都测，因为它们暴露的问题完全不同。后端也一样。

二、阶梯加压（Ramping）：找拐点

长什么样

到达率
  ↑
2000 ┤                                    ╭──── 崩溃点
1000 ┤                        ╭───────────╯
 700 ┤              ╭─────────╯  ← 拐点
 400 ┤      ╭───────╯
 100 ┤──────╯
     └──────────────────────────────────────→ 时间
       每级：爬升 30s + 稳态 2~5min

关键参数（每一项都有理由）

参数	建议值	为什么
起始负载	目标容量的 10%~20%	先建立低位基线
每级增幅	1.5–2 倍	太大跳过了拐点，太小耗时太久
爬升时长	30 秒	让系统有时间升到该级（不要瞬间跳变）
稳态时长	2–5 分钟	⚠️ 最关键：队列要建立、缓存要进入混合状态、GC 周期要走过至少一轮
终止条件	崩溃线（第 1 章 1.4 节）	避免把服务压死

最容易犯的错：每级只跑 30 秒

为什么不行：

配套代码：JFR 三种用法与 jcmd 应急手册

Mon, 01 Jan 0001 00:00:00 +0000

4.4 配套代码：JFR 三种用法与 jcmd 应急手册

对应小节：4.4 JFR 与 jcmd 这份文件是可以直接贴进生产配置的 JFR 参数，以及 jcmd 的实战用法。

一、JFR：生产推荐的启动配置

java \
  -XX:StartFlightRecording=name=rolling,settings=profile,maxsize=256m,maxage=1h,dumponexit=true,filename=/var/log/app/recording.jfr \
  -XX:FlightRecorderOptions=stackdepth=128 \
  -jar app.jar

每个参数的理由：

参数	理由
`name=rolling`	给录制起名，便于后续 `JFR.dump name=rolling`
`settings=profile`	记录更多事件（约 1–2% 开销），适合排障；长期生产可用 `default`
`maxsize=256m`	滚动上限，超出丢弃最旧事件（防止磁盘写满）
`maxage=1h`	只保留最近 1 小时（按你的业务周期调整）
`dumponexit=true`	⭐ 进程退出（含崩溃）时自动落盘——排查 OOM 的关键
`stackdepth=128`	栈深度，太浅会丢上下文，太深占空间
`filename=...`	落盘位置；放到独立分区避免写满根分区

验证是否生效：

jcmd <pid> JFR.check
# 应该看到类似：Recording: name=rolling, ... running

二、运行中控制（不用重启）

PID=$(jcmd | grep app.jar | awk '{print $1}')

# ── 出问题时：立刻保存过去 1 小时的事件 ──────────────────
jcmd "$PID" JFR.dump name=rolling filename=/tmp/incident-$(date +%Y%m%d-%H%M%S).jfr

# ── 临时录一段（不依赖启动参数）─────────────────────────
jcmd "$PID" JFR.start name=adhoc settings=profile duration=120s filename=/tmp/adhoc.jfr

# ── 查看正在运行的录制 ──────────────────────────────────
jcmd "$PID" JFR.check

# ── 停止某个录制 ────────────────────────────────────────
jcmd "$PID" JFR.stop name=adhoc

⭐ 最重要的一条：问题发生时立刻 dump。偶发问题的证据只存在于"过去"，等重启后再查就没了。

配套代码：Little's Law 容量计算器

Mon, 01 Jan 0001 00:00:00 +0000

0.4 配套代码：Little’s Law 容量计算器

对应小节：0.4 用 Little’s Law 估算容量要验证的结论：用平均值配置资源是危险的；峰值 QPS × 尾部延迟才是资源需求的上界。

一、公式回顾

L = λ × W
L：在途请求数（个）
λ：到达率（req/s）
W：驻留时间（秒）

二、代码：三个用法 + 一个危险演示

// src/main/kotlin/lesson00/LittlesLaw.kt
package lesson00

import kotlin.math.ceil

/**
 * 计算在途请求数（并发需求）。
 * @param qps 到达率，单位 req/s
 * @param latencyMs 驻留时间，单位毫秒
 */
fun inFlight(qps: Double, latencyMs: Double): Double = qps * (latencyMs / 1000.0)

/**
 * 反推：给定并发上限与单次处理时间，理论最大吞吐。
 * 注意这是"理论值"——它假设资源 100% 忙碌且没有排队。
 */
fun maxThroughput(concurrency: Int, latencyMs: Double): Double =
    concurrency / (latencyMs / 1000.0)

fun main() {
    // ═══════════════════════════════════════════════════════════
    // 用法一：算出需要多少连接/线程/协程
    // ═══════════════════════════════════════════════════════════
    println("=== 用法一：订单查询接口需要多少连接？===")
    val qps = 200.0
    val avgLatency = 30.0
    println("峰值 QPS = %.0f, 平均延迟 = %.1f ms".format(qps, avgLatency))
    println("→ 平均需要 %.1f 个连接".format(inFlight(qps, avgLatency)))
    println("→ 如果连接池设成 100，有 %.0f 个连接平时是闲置的（白占数据库内存）"
        .format(100 - inFlight(qps, avgLatency)))
    println()

    // ═══════════════════════════════════════════════════════════
    // 用法二：从资源上限反推吞吐天花板
    // ═══════════════════════════════════════════════════════════
    println("=== 用法二：数据库最多 50 个连接，单查询 20 ms，理论最大吞吐？===")
    val theoretical = maxThroughput(50, 20.0)
    println("→ 理论上限 %.0f req/s".format(theoretical))
    println("→ 但这是「50 个连接永远 100% 忙碌且零排队」的理想情况")
    println("→ 考虑排队效应（利用率不该超过 70%%），实际可稳定支撑约 %.0f req/s"
        .format(theoretical * 0.7))
    println()

    // ═══════════════════════════════════════════════════════════
    // 用法三：从"活跃请求数"反推实际延迟
    // ═══════════════════════════════════════════════════════════
    println("=== 用法三：观测到 100 个活跃请求，QPS 是 500，平均延迟是多少？===")
    val observedConcurrency = 100.0
    val observedQps = 500.0
    println("→ W = L / λ = %.0f / %.0f = %.3f s = %.0f ms"
        .format(observedConcurrency, observedQps, observedConcurrency / observedQps,
                observedConcurrency / observedQps * 1000))
    println("→ 如果这个数字远大于「服务端处理时间」，多出来的部分就是排队")
    println()

    // ═══════════════════════════════════════════════════════════
    // 危险演示：按平均值配置 vs 按尾部配置
    // ═══════════════════════════════════════════════════════════
    demonstrateTheDanger()

    // ═══════════════════════════════════════════════════════════
    // 敏感性分析：延迟变化对资源需求的影响
    // ═══════════════════════════════════════════════════════════
    sensitivityTable()
}

/**
 * 核心危险：同一份流量，按 P50 配置资源和按 P99 配置资源，需求差 7 倍以上。
 * 而系统恰恰在 P99 那个时刻最需要资源。
 */
fun demonstrateTheDanger() {
    val peakQps = 1000.0
    val p50 = 8.0
    val p99 = 60.0

    println("=== 危险演示：同一个接口，两种算法差多少？===")
    println("峰值 QPS = %.0f".format(peakQps))
    println("按 P50 计算：L = %.0f × %.3f = %5.1f 个".format(peakQps, p50 / 1000, inFlight(peakQps, p50)))
    println("按 P99 计算：L = %.0f × %.3f = %5.1f 个".format(peakQps, p99 / 1000, inFlight(peakQps, p99)))
    println()
    println("两个数字差 %.1f 倍。".format(inFlight(peakQps, p99) / inFlight(peakQps, p50)))
    println()
    println("如果把连接池按 P50 配置（8 个）：")
    println("  → 平时刚好够用（CPU 看着很健康）")
    println("  → 一旦进入那 1% 的慢时刻，60 个请求抢 8 个连接")
    println("  → 排队让延迟进一步上升 → 更多请求堆积 → 雪崩")
    println()
    println("如果把连接池按 P99 配置（%d 个）：".format(ceil(inFlight(peakQps, p99)).toInt()))
    println("  → 最坏时刻够用，但平时有 %.0f 个连接闲置（浪费数据库内存）"
        .format(inFlight(peakQps, p99) - inFlight(peakQps, p50)))
    println("  → 实践做法：取 P95 左右的值 + 排队上限（有界池）+ 快速失败")
    println()
}

/** 敏感性分析：延迟涨一点，资源需求涨多少 */
fun sensitivityTable() {
    val qps = 1000.0
    println("=== 敏感性分析（QPS = %.0f）：延迟 → 需要的并发数 ===".format(qps))
    println("平均延迟(ms) | 需要并发数 | 相对 10ms 的倍数")
    val baseline = inFlight(qps, 10.0)
    for (ms in listOf(10, 15, 20, 30, 50, 100, 200)) {
        val l = inFlight(qps, ms.toDouble())
        println("%11d | %10.1f | %14.1fx".format(ms, l, l / baseline))
    }
    println()
    println("注意：延迟从 10ms 涨到 100ms（10 倍），所需并发也涨 10 倍。")
    println("     但你的连接池是按 10ms 配的 → 延迟一涨，连接池立刻成为瓶颈。")
    println("     这就是「延迟恶化 → 资源耗尽 → 延迟更恶化」的正反馈。")
}

/**
 * 一个真实的容量规划表格生成器：
 * 给定 QPS 与目标延迟，输出每种资源该配多少。
 */
fun capacityPlan(peakQps: Double, p50Ms: Double, p95Ms: Double, p99Ms: Double) {
    println("=== 容量规划建议（峰值 QPS = %.0f）===".format(peakQps))
    println("场景        | 延迟   | 并发需求 | 建议配置（含 30% 余量）")
    println("乐观 (P50)  | %5.1fms | %7.1f  | %d".format(p50Ms, inFlight(peakQps, p50Ms),
        ceil(inFlight(peakQps, p50Ms) * 1.3).toInt()))
    println("典型 (P95)  | %5.1fms | %7.1f  | %d".format(p95Ms, inFlight(peakQps, p95Ms),
        ceil(inFlight(peakQps, p95Ms) * 1.3).toInt()))
    println("悲观 (P99)  | %5.1fms | %7.1f  | %d".format(p99Ms, inFlight(peakQps, p99Ms),
        ceil(inFlight(peakQps, p99Ms) * 1.3).toInt()))
    println()
    println("建议：以 P95 那一行为基准配置，用有界队列 + 限流保护住 P99 的极端情况。")
}

三、预期输出（关键部分）

=== 危险演示：同一个接口，两种算法差多少？===
峰值 QPS = 1000
按 P50 计算：L = 1000 × 0.008 =   8.0 个
按 P99 计算：L = 1000 × 0.060 =  60.0 个

两个数字差 7.5 倍。

四、四个必须记住的点

λ 和 W 必须来自同一段业务。 用「全站平均 QPS」乘「全站平均延迟」得到的数字没有意义——要么按接口算，要么按资源维度（都走数据库的算一组）算。
用峰值 QPS，不用平均 QPS。 系统是在峰值时刻垮掉的，不是平均时刻。
同时算 P50 版和 P99 版。 P50 版告诉你「平时需要多少」，P99 版告诉你「最坏时刻需要多少」。两者的差距就是你的风险敞口。
Little’s Law 只描述稳态平均，不含排队。 所以算出来的数字是下界，实际配置要考虑排队余量（第 5 节解释了为什么）。

五、动手改造

改动	观察什么
把 `peakQps` 从 1000 改成 10000	资源需求线性增长——但你的数据库连接上限是固定的，什么时候会撞墙？
把 P99 从 60ms 改成 300ms	需要的并发变成多少？这解释了为什么「一次 GC 停顿」能让连接池瞬间打满
在 `capacityPlan` 里把余量从 30% 改成 50%	成本增加多少？（把它换算成机器台数，就明白 headroom 是有代价的）
自己加一个「重试」参数：假设 5% 的请求会重试一次	λ 实际变成多少？资源需求涨多少？（这就是重试风暴的数学模型）

六、这段代码的局限

它假设到达率是恒定的，真实流量有波峰波谷，瞬时并发会远高于平均值。
它不包含排队模型，所以「需要 8 个连接」不代表「8 个连接就够了」。
它假设请求之间相互独立，而真实系统中慢请求会占用资源影响后续请求。

配套代码：SLI 采集与错误预算

Mon, 01 Jan 0001 00:00:00 +0000

8.4 配套代码：SLI 采集与错误预算

对应小节：8.4 生产观测：SLI 与错误预算三部分：① SLO 定义（可执行）；② 错误预算 PromQL；③ 看板与告警的数据源。

一、可执行的 SLO 定义

# slo/slos.yaml —— 机器可读的 SLO 定义
# 用于生成：Prometheus 记录规则、Grafana 看板、错误预算告警
slos:
  # ═══ 可用性 ═══
  - name: orders-availability
    title: "订单查询可用性"
    description: "订单查询接口的非 5xx 比例"
    sli:
      type: ratio
      good: 'sum(rate(http_requests_total{uri="/orders/{id}", status!~"5.."}[5m]))'
      total: 'sum(rate(http_requests_total{uri="/orders/{id}"}[5m]))'
    objective: 0.999
    window: 30d
    error_budget: 0.001

  # ═══ 延迟 ═══
  - name: orders-latency
    title: "订单查询延迟"
    description: "订单查询 P99 低于 200ms 的比例"
    sli:
      type: threshold
      metric: 'http_request_duration_seconds_bucket{uri="/orders/{id}"}'
      threshold: 0.2
      # good = 落在 200ms 桶内的请求数
      good: 'sum(rate(http_request_duration_seconds_bucket{uri="/orders/{id}", le="0.2"}[5m]))'
      total: 'sum(rate(http_request_duration_seconds_count{uri="/orders/{id}"}[5m]))'
    objective: 0.999
    window: 30d
    error_budget: 0.001
    # ⚠️ 负载前提：低流量时 P99 不稳定
    precondition: 'sum(rate(http_requests_total{uri="/orders/{id}"}[5m])) > 100'

  # ═══ 业务 SLI（比技术 SLI 更接近真实价值）═══
  - name: order-creation-success
    title: "下单成功率"
    description: "下单请求中业务成功的比例"
    sli:
      type: ratio
      good: 'sum(rate(business_orders_success_total[5m]))'
      total: 'sum(rate(business_orders_total[5m]))'
    objective: 0.995
    window: 30d
    error_budget: 0.005

注意三项的设计差异：

配套代码：三种负载曲线的 k6 脚本

Mon, 01 Jan 0001 00:00:00 +0000

3.4 配套代码：三种负载曲线的 k6 脚本

对应小节：3.4 负载曲线三份可直接运行的脚本：阶梯加压、恒定到达率、尖峰测试。

一、阶梯加压：找拐点

// loadtest/profile-staircase.js
import http from 'k6/http';
import { check } from 'k6';

const LEVELS = [100, 200, 400, 700, 1000, 1500, 2000];

const stages = [];
for (const target of LEVELS) {
  stages.push({ target, duration: '30s' });   // 爬升：让系统升到该级
  stages.push({ target, duration: '2m' });    // ⚠️ 稳态：采数据必须在这里，至少 2 分钟
}

export const options = {
  scenarios: {
    staircase: {
      executor: 'ramping-arrival-rate',
      startRate: 50,
      timeUnit: '1s',
      preAllocatedVUs: 500,
      maxVUs: 5000,
      stages,
    },
  },
  // 故意不设 thresholds：容量测试的目的是找拐点，不是判定通过/失败
  discardResponseBodies: true,
};

function zipf(max) {
  return Math.max(1, Math.floor(max * Math.pow(Math.random(), 3)) + 1);
}

export default function () {
  const res = http.get(`${__ENV.BASE_URL}/orders/${zipf(1_000_000)}`, {
    tags: { name: 'GET /orders/{id}' },
  });
  check(res, { ok: (r) => r.status === 200 });
}

关键检查：每级的稳态窗口（那 2 分钟）才是采数据的区间。如果只跑 30 秒的爬升段，你会得到一条平坦且偏低的曲线（见 3.4 节的解释）。

配套代码：基线与噪声底线

Mon, 01 Jan 0001 00:00:00 +0000

9.4 配套代码：基线与噪声底线

对应小节：9.4 步骤三：建立基线与噪声底线

一、先验证观测回路（不测性能，只验证"仪表能读数"）

#!/usr/bin/env bash
# tools/step3a-verify-observability.sh
#
# ═══ 为什么先做这一步 ═══
# 如果仪表本身不准，后面所有数字都是错的。
# 这一步【不关心性能好坏】，只关心「数字能不能对上」。
set -euo pipefail

BASE="${BASE_URL:-http://localhost:8080}"
PG="${PG_CONN:-postgresql://app:app@localhost:5432/shortlink}"

pass=0; fail=0
ok()   { echo "   ✅ $1"; pass=$((pass+1)); }
bad()  { echo "   ❌ $1"; fail=$((fail+1)); }

echo "═══ 观测回路验证 ═══"
echo

# ── ① 指标端点可用 ──
echo "① Prometheus 端点"
if curl -sf "$BASE/metrics" -o /tmp/m.txt; then
  ok "可访问，共 $(wc -l < /tmp/m.txt) 行指标"
else
  bad "无法访问 $BASE/metrics"
fi

# ── ② 四层指标都在 ──
echo
echo "② 四层指标覆盖"
check_metric() {
  if grep -q "^$1" /tmp/m.txt 2>/dev/null; then ok "$1"; else bad "$1 缺失"; fi
}
check_metric "http_server_requests_seconds"
check_metric "app_request_duration"
check_metric "jvm_memory_used_bytes"
check_metric "jvm_gc_pause_seconds"
check_metric "hikaricp_connections_active"
check_metric "db_pool_pending"
check_metric "app_cache_hit_rate"

# ── ③ 计数守恒：客户端请求数 ≈ 服务端请求数 ──
echo
echo "③ 计数守恒（测 100 次请求）"
before=$(grep '^http_server_requests_seconds_count' /tmp/m.txt | awk '{s+=$NF} END{print s+0}')
for i in $(seq 1 100); do
  curl -sf -o /dev/null "$BASE/health" || true
done
sleep 1
after=$(curl -sf "$BASE/metrics" | grep '^http_server_requests_seconds_count' | awk '{s+=$NF} END{print s+0}')
delta=$((after - before))
if [ "$delta" -ge 100 ]; then
  ok "客户端 100 次 / 服务端计数 +$delta（对得上）"
else
  bad "客户端 100 次 / 服务端只 +$delta（有丢失 —— 指标采样或中间件问题）"
fi

# ── ④ 延迟直方图有分布（不是全落在 +Inf）──
echo
echo "④ 延迟直方图分布"
buckets=$(curl -sf "$BASE/metrics" | grep -c 'app_request_duration_bucket' || true)
if [ "$buckets" -ge 5 ]; then
  ok "有 $buckets 个桶（分布可算分位数）"
else
  bad "只有 $buckets 个桶 —— 直方图配置有问题"
fi

# ── ⑤ 依赖计时与端到端能对上 ──
echo
echo "⑤ 依赖级 vs 端到端"
cat > /tmp/probe.js <<'JS'
import http from 'k6/http';
export const options = { vus: 2, duration: '15s', thresholds: {} };
const codes = open('../data/hot-codes.txt').split('\n').filter(Boolean);
export default function () {
  http.get(`http://localhost:8080/${codes[Math.floor(Math.random()*codes.length)]}`,
    { redirects: 0 });
}
JS
(cd perf/k6 && k6 run --quiet --no-summary /tmp/probe.js >/dev/null 2>&1) || true
sleep 2
e2e=$(curl -sf "$BASE/metrics" | grep '^app_request_duration_seconds_sum' | awk '{s+=$NF} END{print s+0}')
dep=$(curl -sf "$BASE/metrics" | grep '^app_db_query_seconds_sum' | awk '{s+=$NF} END{print s+0}')
if [ -n "$e2e" ] && [ -n "$dep" ]; then
  ratio=$(python3 -c "print(f'{$dep/$e2e*100:.0f}' if $e2e>0 else 'n/a')")
  ok "依赖总耗时占端到端 ${ratio}%（埋雷 ① 生效时应 > 80%）"
else
  bad "缺少 app_db_query_seconds 指标 —— 依赖级计时未埋"
fi

echo
echo "═════════════════════════════════════"
echo "通过 $pass 项 / 失败 $fail 项"
if [ "$fail" -gt 0 ]; then
  echo
  echo "❌ 观测回路不可信 —— 【不要】开始测性能"
  echo "   先修仪表：数字对不上的压测结果没有讨论价值"
  exit 1
fi
echo "✅ 观测回路可信，可以开始基线"

预期输出：

配套代码：把 SLO 写成代码

Mon, 01 Jan 0001 00:00:00 +0000

1.4 配套代码：把 SLO 写成代码

对应小节：1.4 SLO 的四要素写法核心思路：让「SLO 写得不完整」这件事在编译期或测试期就失败，而不是等到验收时才发现。

一、为什么要把 SLO 变成代码

写在文档里的 SLO 会腐烂：改代码的人不看文档，看文档的人不知道代码。

把四要素变成必填字段，就能得到两个好处：

无法遗漏：缺字段直接编译不过 / 测试失败。
可派生：从 SLO 自动生成直方图桶边界、告警表达式、验收脚本参数。

二、SLO 的数据结构

// src/main/kotlin/slo/Slo.kt
package slo

import java.time.Duration

/** 测量点：必须显式指定，不能默认 */
enum class MeasurementPoint(val label: String) {
    CLIENT("压测客户端 / 真实用户"),
    GATEWAY("网关 / 负载均衡"),
    IN_APP("应用内埋点（仅用于定位，不能用于验收）"),
}

/** 数据分布：必须写明，因为它会显著影响缓存命中率与锁竞争 */
enum class DataDistribution(val label: String) {
    UNIFORM("均匀分布"),
    ZIPF("幂律（齐夫）分布"),
    REAL_REPLAY("真实流量回放"),
}

data class Slo(
    // ① 指标 + 阈值
    val endpoint: String,
    val latencyP99Ms: Long,
    val latencyP999Ms: Long,          // 至少两个分位数
    val errorRateMax: Double,

    // ② 负载与数据前提
    val targetQps: Int,
    val dataRows: Long,
    val distribution: DataDistribution,
    val cacheState: String,           // "预热 5 分钟" / "冷缓存"

    // ③ 测量点
    val measurementPoint: MeasurementPoint,

    // ④ 持续时长与验收方式
    val warmup: Duration,
    val steadyState: Duration,
    val rounds: Int,                  // 跑几轮、取中位数

    // 附加：环境与崩溃线
    val environment: String,
    val crashLine: String,
)

三、校验：把「不完整」变成错误

// src/main/kotlin/slo/SloValidation.kt
package slo

fun Slo.validate(): List<String> {
    val problems = mutableListOf<String>()

    // ① 指标 + 阈值
    if (latencyP99Ms <= 0) problems += "P99 阈值必须为正数"
    if (latencyP999Ms <= latencyP99Ms) {
        problems += "P999 阈值(${latencyP999Ms}ms)必须大于 P99(${latencyP99Ms}ms)——否则不是长尾指标"
    }
    if (errorRateMax < 0 || errorRateMax > 1) problems += "错误率阈值必须在 0~1 之间"

    // ② 负载与数据前提
    if (targetQps <= 0) problems += "目标 QPS 必须为正数（不要留空或写 0）"
    if (dataRows <= 0) problems += "数据量必须明确（1 万行和 1 亿行的执行计划不同）"
    if (cacheState.isBlank()) problems += "缓存状态必须写明（冷缓存和热缓存的 P99 可以差几十倍）"

    // ③ 测量点
    if (measurementPoint == MeasurementPoint.IN_APP) {
        problems += "测量点不能是「应用内埋点」：它不含网络与排队，无法代表用户体验，只能用于定位"
    }

    // ④ 持续时长
    if (warmup.isZero) problems += "必须声明预热时长，且预热数据不计入统计"
    if (steadyState < Duration.ofMinutes(3)) {
        problems += "稳态时长 ${steadyState.toMinutes()} 分钟偏短：至少 3 分钟才能覆盖一个 GC/缓存周期"
    }
    if (rounds < 3) problems += "至少跑 3 轮，否则无法区分真实差异与噪声"

    // 附加
    if (environment.isBlank()) problems += "必须写明环境（实例规格、副本数、容器 CPU limit）"
    if (crashLine.isBlank()) problems += "必须定义崩溃线（压力测试的终止条件）"

    return problems
}

用法：写成单元测试，SLO 定义有问题时 CI 直接红。

配套代码：环境检查与事件时间线

Mon, 01 Jan 0001 00:00:00 +0000

5.4 配套代码：环境检查与事件时间线

对应小节：5.4 环境隔离清单两件事：① 实验前逐项检查环境；② 实验期间记录事件时间线（用于解释异常）。

一、环境检查脚本

#!/usr/bin/env bash
# tools/check-environment.sh <EXP_ID>
#
# 实验前运行，逐项检查环境是否"干净"。
set -uo pipefail

EXP_ID="${1:?usage: check-environment.sh <EXP_ID>}"
OUT="docs/experiments/${EXP_ID}/results/env-check.txt"
mkdir -p "$(dirname "$OUT")"

PASS=0; WARN=0; FAIL=0

ok()   { echo "  ✅ $1"; PASS=$((PASS+1)); }
warn() { echo "  ⚠️  $1"; WARN=$((WARN+1)); }
bad()  { echo "  ❌ $1"; FAIL=$((FAIL+1)); }

{
echo "═══ 环境检查 $(date -Iseconds) ═══"
echo

# ── ① CPU 状态 ──────────────────────────────────────────
echo "① CPU 状态"
GOV=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 2>/dev/null || echo "n/a")
if [ "$GOV" = "performance" ]; then ok "governor = performance"
elif [ "$GOV" = "n/a" ]; then warn "governor 不可读（非 Linux 或权限不足）"
else warn "governor = $GOV（非 performance，可能降频）：sudo cpupower frequency-set -g performance"; fi

echo "  可见核数: $(nproc)"
echo

# ── ② steal 时间（云主机邻居抢占）──────────────────────
echo "② steal 时间（连续采样 5 次）"
ST_VALUES=()
for i in $(seq 1 5); do
  ST=$(vmstat 1 2 2>/dev/null | tail -1 | awk '{print $17}')
  [ -n "$ST" ] && ST_VALUES+=("$ST")
  sleep 1
done
if [ ${#ST_VALUES[@]} -gt 0 ]; then
  MAX_ST=$(printf '%s\n' "${ST_VALUES[@]}" | sort -rn | head -1)
  echo "   采样值: ${ST_VALUES[*]}"
  if [ "$MAX_ST" -gt 3 ] 2>/dev/null; then
    bad "st 最高 $MAX_ST% > 3% —— 被邻居抢占 CPU，环境不可控"
  elif [ "$MAX_ST" -gt 1 ] 2>/dev/null; then
    warn "st 最高 $MAX_ST% —— 轻微抢占，记录下来"
  else
    ok "st 最高 $MAX_ST% —— 环境干净"
  fi
else
  warn "无法读取 st（非 Linux）"
fi
echo

# ── ③ 容器限制与节流 ────────────────────────────────────
echo "③ 容器资源限制"
if [ -f /sys/fs/cgroup/cpu.max ]; then
  read -r QUOTA PERIOD < /sys/fs/cgroup/cpu.max
  if [ "$QUOTA" = "max" ]; then
    bad "未设置 CPU limit —— 与生产不一致时，数据不可迁移（第 4.8 节）"
  else
    awk -v q="$QUOTA" -v p="$PERIOD" 'BEGIN{printf "  CPU limit = %.2f 核\n", q/p}'
  fi
  NR_P=$(awk '/nr_periods/{print $2}' /sys/fs/cgroup/cpu.stat 2>/dev/null || echo 0)
  NR_T=$(awk '/nr_throttled/{print $2}' /sys/fs/cgroup/cpu.stat 2>/dev/null || echo 0)
  if [ "$NR_P" -gt 0 ] 2>/dev/null; then
    RATIO=$(awk -v p="$NR_P" -v t="$NR_T" 'BEGIN{printf "%.2f", 100*t/p}')
    if awk -v r="$RATIO" 'BEGIN{exit !(r>25)}'; then bad "累计节流比例 ${RATIO}% > 25%"
    elif awk -v r="$RATIO" 'BEGIN{exit !(r>1)}'; then warn "累计节流比例 ${RATIO}%"
    else ok "累计节流比例 ${RATIO}%"; fi
  fi
else
  warn "未检测到 cgroup CPU 限制（非容器环境）"
fi
echo

# ── ④ 后台任务 ──────────────────────────────────────────
echo "④ 后台任务检查"
FOUND=0
for pat in "backup" "pg_dump" "logrotate" "updatedb" "apt" "yum" "dnf" "unattended"; do
  if pgrep -a -f "$pat" > /dev/null 2>&1; then
    bad "检测到进程: $pat"; pgrep -a -f "$pat" | head -2 | sed 's/^/      /'
    FOUND=1
  fi
done
[ "$FOUND" -eq 0 ] && ok "未检测到常见后台任务"
echo

# ── ⑤ 高 CPU 进程（可能有其他负载）─────────────────────
echo "⑤ 当前 CPU 占用 Top 5"
ps aux --sort=-%cpu 2>/dev/null | head -6 | tail -5 | awk '{printf "   %-20s %5s%% CPU  %5s%% MEM\n", substr($11,1,20), $3, $4}' || echo "   （ps 格式不同，跳过）"
echo

# ── ⑥ 数据库状态 ────────────────────────────────────────
echo "⑥ 数据库状态"
if command -v psql > /dev/null 2>&1 && [ -n "${PG_CONN:-}" ]; then
  echo "   长事务（> 30 秒）："
  psql "$PG_CONN" -tAc "
    SELECT count(*) FROM pg_stat_activity
    WHERE state <> 'idle' AND now() - query_start > interval '30 seconds';" 2>/dev/null | \
    sed 's/^/      数量: /' || warn "无法查询数据库"
  echo "   连接使用率："
  psql "$PG_CONN" -tAc "
    SELECT round(100.0*count(*)/current_setting('max_connections')::int, 1)
    FROM pg_stat_activity;" 2>/dev/null | sed 's/^/      /' || true
else
  warn "未设置 PG_CONN 或 psql 不可用，跳过数据库检查"
fi
echo

# ── ⑦ 压测客户端位置 ────────────────────────────────────
echo "⑦ 压测客户端位置"
echo "   ⚠️  需要人工确认：压测客户端必须【独立于】被测服务"
echo "      同机会互相抢 CPU，两个方向都失真（第 4 章 4.1）"
echo

# ── ⑧ 观测配置 ──────────────────────────────────────────
echo "⑧ 观测配置（必须与基线组一致）"
echo "   JFR: ${JFR_SETTINGS:-未设置}"
echo "   profiler: ${PROFILER:-未启用}"
echo "   日志级别: ${LOG_LEVEL:-未设置}"
echo "   ⚠️  基线组与实验组必须用【同样的观测配置】，否则差异可能来自观测开销"
echo

# ── 汇总 ────────────────────────────────────────────────
echo "═══════════════════════════════════════"
echo "通过 $PASS 项，警告 $WARN 项，失败 $FAIL 项"
if [ "$FAIL" -gt 0 ]; then
  echo "❌ 存在失败项 —— 请先修复环境，否则数据不可信"
  echo "   （仍可继续实验，但必须在报告里声明环境问题）"
elif [ "$WARN" -gt 0 ]; then
  echo "⚠️  存在警告项 —— 建议记录并评估影响"
else
  echo "✅ 环境检查通过"
fi
} | tee "$OUT"

echo
echo "结果已保存 → $OUT"

二、环境事件时间线记录

#!/usr/bin/env bash
# tools/record-events.sh <EXP_ID> [INTERVAL_SEC]
#
# 在实验期间后台运行，记录环境事件。
# 事后用它解释异常轮（第 5.3 节）。
set -uo pipefail

EXP_ID="${1:?usage: record-events.sh <EXP_ID> [interval]}"
INTERVAL="${2:-10}"
OUT="docs/experiments/${EXP_ID}/results/events.csv"
mkdir -p "$(dirname "$OUT")"

echo "开始记录环境事件（每 ${INTERVAL}s）→ $OUT"
echo "按 Ctrl-C 停止"

# CSV 表头
echo "timestamp,loadavg,steal_pct,ctx_switch,run_queue,throttled,top_proc,pg_active,pg_long_tx" > "$OUT"

cleanup() {
  echo
  echo "✅ 事件记录已保存 → $OUT"
  echo "   用它来解释异常轮："
  echo "     grep -E 'logrotate|backup' $OUT"
  exit 0
}
trap cleanup INT TERM

while true; do
  TS=$(date +%s)

  # 系统负载
  LOADAVG=$(cut -d' ' -f1 /proc/loadavg 2>/dev/null || echo "0")
  STEAL=$(vmstat 1 2 2>/dev/null | tail -1 | awk '{print $17}' || echo "0")
  CTX=$(vmstat 1 2 2>/dev/null | tail -1 | awk '{print $12}' || echo "0")
  RUNQ=$(vmstat 1 2 2>/dev/null | tail -1 | awk '{print $1}' || echo "0")

  # 节流计数
  THROTTLED=$(awk '/nr_throttled/{print $2}' /sys/fs/cgroup/cpu.stat 2>/dev/null || echo "0")

  # 占用最高的非 Java 进程（排除自己）
  TOPPROC=$(ps aux --sort=-%cpu 2>/dev/null | awk 'NR>1 && $11 !~ /java|ps|awk/ {print $11; exit}' || echo "none")

  # 数据库
  PG_ACTIVE="n/a"; PG_LONG="n/a"
  if command -v psql > /dev/null 2>&1 && [ -n "${PG_CONN:-}" ]; then
    PG_ACTIVE=$(psql "$PG_CONN" -tAc "SELECT count(*) FROM pg_stat_activity WHERE state='active';" 2>/dev/null || echo "n/a")
    PG_LONG=$(psql "$PG_CONN" -tAc "SELECT count(*) FROM pg_stat_activity WHERE state<>'idle' AND now()-query_start > interval '10 seconds';" 2>/dev/null || echo "n/a")
  fi

  echo "$TS,$LOADAVG,$STEAL,$CTX,$RUNQ,$THROTTLED,$TOPPROC,$PG_ACTIVE,$PG_LONG" >> "$OUT"

  sleep "$INTERVAL"
done

用法：

配套代码：用数据判定稳态 + 冷启动测量

Mon, 01 Jan 0001 00:00:00 +0000

2.4 配套代码：用数据判定稳态 + 冷启动测量

对应小节：2.4 预热、稳态与冷启动两个工具：① 滚动变异系数（CV）自动判定稳态；② 冷启动分段计时。

一、工具一：滚动 CV 判定稳态

// src/main/kotlin/lesson02/SteadyStateDetector.kt
package lesson02

import kotlin.math.sqrt
import kotlin.random.Random

private var sink = 0L

fun work(data: IntArray): Long {
    var s = 0L
    for (v in data) s += v
    return s
}

/**
 * 滚动统计窗口：记录最近 N 个采样点，计算均值与变异系数 CV = 标准差/均值。
 * CV 收敛到小值以下 → 认为进入稳态。
 */
class RollingStats(private val window: Int) {
    private val values = ArrayDeque<Double>()

    fun add(v: Double): Pair<Double, Double> {
        values.addLast(v)
        if (values.size > window) values.removeFirst()
        val mean = values.average()
        if (values.size < 2) return mean to Double.NaN
        val variance = values.sumOf { (it - mean) * (it - mean) } / (values.size - 1)
        val cv = sqrt(variance) / mean
        return mean to cv
    }

    val size: Int get() = values.size
}

/**
 * 每 `blockSize` 次调用采样一次，直到 CV 连续 `stableBlocks` 次低于阈值。
 *
 * @return 进入稳态所需的调用次数；若始终未达到则返回 -1
 */
fun findSteadyState(
    blockSize: Int = 2_000,
    maxBlocks: Int = 200,
    cvThreshold: Double = 0.05,
    stableBlocks: Int = 3,
    window: Int = 5,
): Pair<Int, List<Triple<Int, Double, Double>>> {
    val rnd = Random(42)
    val data = IntArray(4096) { rnd.nextInt() }
    val stats = RollingStats(window)
    val trace = mutableListOf<Triple<Int, Double, Double>>()
    var consecutiveStable = 0
    var totalCalls = 0

    repeat(maxBlocks) { block ->
        val t0 = System.nanoTime()
        repeat(blockSize) { sink += work(data) }
        val nsPerOp = (System.nanoTime() - t0).toDouble() / blockSize
        totalCalls += blockSize

        val (mean, cv) = stats.add(nsPerOp)
        trace += Triple(totalCalls, nsPerOp, cv)

        if (!cv.isNaN() && cv < cvThreshold) {
            consecutiveStable++
            if (consecutiveStable >= stableBlocks) {
                return totalCalls to trace
            }
        } else {
            consecutiveStable = 0
        }
    }
    return -1 to trace
}

fun main() {
    println("=== 用滚动 CV 判定稳态 ===")
    println("判据：连续 3 个采样窗口的 CV < 5%\n")
    println("累计调用次数      单次耗时(ns/op)     滚动CV     状态")
    println("-".repeat(64))

    val (steadyAt, trace) = findSteadyState()
    trace.take(20).forEachIndexed { i, (calls, ns, cv) ->
        val status = when {
            cv.isNaN() -> "采样中"
            cv > 0.10 -> "未稳"
            cv > 0.05 -> "接近"
            else -> "✅ 稳定"
        }
        println("%,14d   %12.1f   %10s   %s".format(
            calls, ns, if (cv.isNaN()) "—" else "%.1f%%".format(cv * 100), status))
    }

    println()
    if (steadyAt > 0) {
        println("✅ 在累计 %,d 次调用后进入稳态".format(steadyAt))
        println("   即使用固定预热策略，也应该至少预热这么多")
    } else {
        println("❌ 未能在 %d 个窗口内进入稳态".format(trace.size))
        println("   说明环境噪声过大——这本身就是重要发现（见第 5 章的噪声底线）")
    }
    println()
    println("sink = $sink")
}

二、预期输出形态

累计调用次数      单次耗时(ns/op)     滚动CV     状态
----------------------------------------------------------------
         2,000         1180.4         —       采样中
         4,000          612.1       45.2%     未稳
         6,000          391.7       52.8%     未稳
         8,000          310.2       41.3%     未稳
        10,000          265.4       26.7%     未稳
        12,000          248.9       14.2%     未稳
        14,000          239.1        7.8%     接近
        16,000          234.6        4.1%     ✅ 稳定
        18,000          232.8        2.9%     ✅ 稳定
        20,000          231.9        2.4%     ✅ 稳定

✅ 在累计 16,000 次调用后进入稳态

注意 CV 曲线是「从大到小收敛」，而不是突然达标。这就是为什么「固定预热 5 轮」不可靠——你不知道自己的程序需要几轮。

配套代码：线程与协程快照分析

Mon, 01 Jan 0001 00:00:00 +0000

6.4 配套代码：线程与协程快照分析

对应小节：6.4 线程与协程快照两件事：① 多份快照的对比分析；② 协程快照与协程泄漏检测。

一、多份快照的对比分析器

# tools/analyze-threads.py <threads-*.txt>...
"""
从多份线程快照里找出"持续存在"的问题。

核心思路：
  单张快照是瞬时状态，多张对比才能区分"路过"与"堵住"。
"""
import re
import sys
from collections import Counter, defaultdict


def parse_dump(path):
    """解析 jstack/jcmd Thread.print 输出"""
    threads = []
    current = None
    with open(path, errors="ignore") as f:
        for line in f:
            # 线程头："name" #id prio=... tid=... nid=...
            m = re.match(r'^"([^"]+)"\s+#(\d+)\s+.*nid=(\S+)', line)
            if m:
                if current:
                    threads.append(current)
                current = {"name": m.group(1), "id": m.group(2),
                           "nid": m.group(3), "state": None, "stack": []}
                continue
            if current is not None:
                ms = re.search(r"java\.lang\.Thread\.State:\s*([A-Z_]+)", line)
                if ms:
                    current["state"] = ms.group(1)
                    continue
                mt = re.match(r"^\s+at\s+(\S+)", line)
                if mt:
                    current["stack"].append(mt.group(1))
    if current:
        threads.append(current)
    return threads


def main(paths):
    dumps = [parse_dump(p) for p in paths]
    if not dumps:
        print("❌ 没有读到快照")
        return

    print("═" * 84)
    print(f"线程快照对比分析（{len(dumps)} 份）")
    print("═" * 84)
    print()

    # ① 每份的状态分布
    print("【① 状态分布（每份快照）】")
    for path, threads in zip(paths, dumps):
        states = Counter(t["state"] for t in threads if t["state"])
        total = sum(states.values())
        print(f"  {path}  线程数={len(threads)}")
        for st, c in states.most_common():
            pct = c / total * 100 if total else 0
            bar = "█" * int(pct / 3)
            print(f"     {st:<20}{c:>4}  {pct:5.1f}%  {bar}")
    print()

    # ② 持续存在的栈帧（在所有快照里都出现的）
    print("【② 持续存在的栈帧 Top 20】")
    print("    （在所有快照里都出现 → 不是「路过」，是「堵住」）")
    stack_sets = []
    for threads in dumps:
        frames = set()
        for t in threads:
            frames.update(t["stack"])
        stack_sets.append(frames)

    persistent = set.intersection(*stack_sets) if stack_sets else set()
    # 统计每个持续帧在多少线程里出现（取最后一份快照的数量）
    last_counts = Counter()
    for t in dumps[-1]:
        for f in t["stack"]:
            if f in persistent:
                last_counts[f] += 1

    for frame, _ in last_counts.most_common(20):
        # 在所有快照里的出现次数
        occurrences = sum(1 for ss in stack_sets if frame in ss)
        print(f"  [{occurrences}/{len(dumps)} 份]  {frame[:70]}")
    print()

    # ③ 关键模式检测
    print("【③ 关键模式检测】")
    patterns = {
        "连接池排队": ["HikariPool.getConnection", "getConnection"],
        "等网络 IO": ["socketRead0", "socketRead", "SocketInputStream"],
        "等锁（park）": ["Unsafe.park", "LockSupport.park"],
        "等队列/任务": ["LinkedBlockingQueue.take", "ArrayBlockingQueue"],
        "队列满（生产者阻塞）": ["ArrayBlockingQueue.put", "LinkedBlockingQueue.put"],
        "同步日志刷盘": ["FileOutputStream.write", "FileDispatcherImpl.write"],
        "主动 sleep": ["Thread.sleep"],
        "类加载锁": ["ClassLoader.loadClass", "defineClass"],
        "协程调度": ["DispatchedTask", "CoroutineScheduler"],
    }
    for label, keywords in patterns.items():
        count_by_dump = []
        for threads in dumps:
            c = sum(1 for t in threads
                    if any(any(k in f for k in keywords) for f in t["stack"]))
            count_by_dump.append(c)
        if any(count_by_dump):
            trend = "→".join(str(c) for c in count_by_dump)
            flag = " ⚠️ 持续" if all(c > 0 for c in count_by_dump) else ""
            print(f"  {label:<22}线程数: {trend}{flag}")
    print()

    # ④ BLOCKED 的详细信息
    blocked_in_last = [t for t in dumps[-1] if t["state"] == "BLOCKED"]
    if blocked_in_last:
        print(f"【④ BLOCKED 线程详情（{len(blocked_in_last)} 个）】")
        for t in blocked_in_last[:5]:
            print(f"  {t['name']} (nid={t['nid']})")
            for f in t["stack"][:5]:
                print(f"      at {f}")
            print()
    else:
        print("【④ 无 BLOCKED 线程】→ 排除锁竞争")
    print()

    # ⑤ 线程数趋势（是否泄漏）
    counts = [len(d) for d in dumps]
    print(f"【⑤ 线程数趋势】{' → '.join(map(str, counts))}")
    if len(counts) >= 3 and counts[-1] > counts[0] * 1.5:
        print("  ❌ 线程数持续增长 → 疑似线程泄漏")
    else:
        print("  ✅ 线程数稳定")
    print()

    print("═" * 84)
    print("判读要点：")
    print("  ① 大量 BLOCKED → 锁竞争")
    print("  ② 大量 RUNNABLE 且 CPU 高 → 真的在算")
    print("  ③ 「持续存在」的栈才是真问题（单份快照里的可能只是路过）")
    print("  ④ 栈特征比状态更有指示性（HikariPool → 池排队；socketRead → 等下游）")
    print("  ⑤ RUNNABLE 线程数 == CPU 核数 且 CPU 低 → 疑似调度器被占满")
    print("═" * 84)


if __name__ == "__main__":
    if len(sys.argv) < 2:
        print("usage: analyze-threads.py <threads-1.txt> [threads-2.txt ...]")
        sys.exit(1)
    main(sys.argv[1:])

二、自动采集多份快照并分析

#!/usr/bin/env bash
# tools/capture-threads.sh <EXP_ID> [COUNT] [INTERVAL]
set -uo pipefail

EXP_ID="${1:?usage: capture-threads.sh <exp_id> [count] [interval]}"
COUNT="${2:-5}"
INTERVAL="${3:-3}"
DIR="docs/experiments/${EXP_ID}/results/threads"
mkdir -p "$DIR"

PID=$(jcmd 2>/dev/null | grep app.jar | awk '{print $1}')
[ -z "$PID" ] && { echo "❌ 找不到应用进程"; exit 1; }

echo "采集 $COUNT 份线程快照（间隔 ${INTERVAL}s，PID=$PID）"
for i in $(seq 1 "$COUNT"); do
  jcmd "$PID" Thread.print > "$DIR/threads-$i.txt" 2>/dev/null
  echo "  threads-$i.txt"
  [ "$i" -lt "$COUNT" ] && sleep "$INTERVAL"
done

echo
python3 tools/analyze-threads.py "$DIR"/threads-*.txt | tee "$DIR/analysis.txt"

三、协程快照与泄漏检测

3.1 协程 dump（排障用）

// src/main/kotlin/debug/CoroutineDebug.kt
package debug

import kotlinx.coroutines.debug.DebugProbes

/**
 * 协程调试工具。
 *
 * ⚠️ 开销很大（10%~30%），只能在排障时临时启用。
 *    生产环境请用下面的 CoroutineMonitor（开销低）。
 */
object CoroutineDebug {

    fun install() {
        DebugProbes.install()
    }

    /** dump 所有活跃协程及挂起点 */
    fun dump() {
        DebugProbes.dumpCoroutines()
    }

    /**
     * 只打印摘要（协程数量 + 挂起点分布），比 dumpCoroutines 开销小。
     */
    fun summary() {
        val coroutines = DebugProbes.dumpCoroutinesInfo()
        println("活跃协程数: ${coroutines.size}")

        // 按挂起点分组统计
        val byLocation = coroutines
            .mapNotNull { it.lastObservedStackTrace().firstOrNull() }
            .groupingBy { it.toString().substringBefore("(") }
            .eachCount()
            .entries
            .sortedByDescending { it.value }
            .take(10)

        println("挂起点分布（Top 10）：")
        byLocation.forEach { (loc, count) ->
            val pct = count * 100.0 / coroutines.size
            println("  %6.1f%%  %4d 个  %s".format(pct, count, loc))
        }

        // 关键模式检测
        val stackTraces = coroutines.flatMap { it.lastObservedStackTrace() }.map { it.toString() }
        listOf(
            "连接池排队" to listOf("HikariPool", "getConnection"),
            "JDBC 阻塞" to listOf("jdbc", "QueryExecutor", "PgConnection"),
            "网络阻塞" to listOf("socketRead", "SocketInputStream"),
            "锁等待" to listOf("Mutex", "lock"),
            "队列等待" to listOf("Channel", "receive", "send"),
        ).forEach { (label, keywords) ->
            val c = stackTraces.count { st -> keywords.any { it in st } }
            if (c > 0) {
                println("  ⚠️  $label: $c 个协程（%.1f%%）".format(c * 100.0 / coroutines.size))
            }
        }
    }

    fun uninstall() {
        DebugProbes.uninstall()
    }
}

// build.gradle.kts
dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-debug:1.9.0")
}

3.2 低开销的协程监控（生产可用）

// src/main/kotlin/metrics/CoroutineMonitor.kt
package metrics

import io.micrometer.core.instrument.Gauge
import io.micrometer.core.instrument.MeterRegistry
import kotlinx.coroutines.Job
import kotlinx.coroutines.launch
import kotlinx.coroutines.CoroutineScope
import java.util.concurrent.atomic.AtomicInteger

/**
 * 低开销的协程监控：只统计数量，不采集栈。
 * 可以长期开启（生产环境可用）。
 */
class CoroutineMonitor(registry: MeterRegistry) {

    private val active = AtomicInteger(0)
    private val maxObserved = AtomicInteger(0)

    init {
        Gauge.builder("app.coroutines.active") { active.get().toDouble() }
            .description("当前活跃协程数")
            .register(registry)

        Gauge.builder("app.coroutines.max_observed") { maxObserved.get().toDouble() }
            .description("观测到的最大活跃协程数（用于判断是否堆积）")
            .register(registry)
    }

    /** 包装一个协程，统计它的活跃状态 */
    fun CoroutineScope.tracked(block: suspend () -> Unit): Job = launch {
        val n = active.incrementAndGet()
        maxObserved.updateAndGet { maxOf(it, n) }
        try {
            block()
        } finally {
            active.decrementAndGet()
        }
    }

    val activeCount: Int get() = active.get()
}

判读规则：

Dorkytiger 的知识分享 on Dorkytiger 的小屋

`perf stat` —— 统计模式

一、基本用法

二、关键指标解读

三、C++ 代码与 perf 计数器的对应

`std::unique_ptr` —— 零开销的独占所有权

一、物理大小：和裸指针一样大

二、为什么只能 std::move 不能拷贝？

`std::variant` —— 类型安全联合体

解决什么问题？

什么时候用？

三种访问方式（选哪种？）

`std::vector` 动态数组的内存黑幕

一、物理内存：绝对连续

AddressSanitizer（ASan）

一、它能抓到什么

二、用法

三、和你的两个项目相关的例子

四、性能影响

Callgrind —— 指令级精确分析

一、和 perf 的区别

二、基本用法

三、可视化分析

Clang-Tidy

一、Clang-Tidy 能做什么

二、它能抓到的问题

三、在 CMake 中集成

四、用 .clang-tidy 配置项目规则

CPU 缓存行（Cache Line）与 MESI 协议

1. 缓存行（Cache Line）：CPU缓存的最小传输单位

什么是缓存行？

为什么用缓存行？（空间局部性）

2. MESI协议：缓存一致性的"交通规则"

CRTP 基础模式

一、为什么需要 CRTP？

二、CRTP 长什么样？

三、CRTP 和虚函数的性能差距

CRTP（奇异递归模板模式）

一、解决什么问题？

二、底层原理：编译期 this 转换

三、虚函数 vs CRTP——性能差距有多大？

FFmpeg 命令行

一、日常必会命令

二、直播延迟优化

PCM 裸音频

一、音频怎么变成数据

二、三个关键参数

三、音频在内存中的布局

PGO 的原理

一、PGO 解决什么问题

二、三步流程

三、PGO 的实际效果

PIMPL 惯用法（Pointer to Implementation）

一、解决什么问题？

PTS / DTS

一、为什么需要两个时间戳

二、在 FFmpeg 中拿正确的 PTS

Reactor 模式

RGB 色彩空间

一、RGB 的物理含义

二、RGB 为什么不适合视频编码？

RTMP 协议

一、RTMP 握手

二、RTMP Chunk 分片

SPSC (单写单读) 的极致优化

1. SPSC 为什么可以零 CAS？

2. 环形缓冲区（Ring Buffer）—— SPSC的经典实现

数据结构

内存布局图示

3. 性能核武器：批量处理（Batch Processing）

Type Erasure 要解决什么问题

一、问题场景

二、Type Erasure 的核心模式

一、 核心原理解释：物理视角的分类法

1. 左值 (lvalue) —— 有身份，不可移动

2. 纯右值 (prvalue) —— 无身份，可移动

3. 将亡值 (xvalue) —— 有身份，可移动（现代 C++ 零拷贝的精髓 ✨）

一、Concepts 到底解决了什么问题？

一、Ranges 解决了一个什么痛？

一、容器为什么不直接 new/delete？

二、为什么只能 `std::move` 不能拷贝？

四、用 `.clang-tidy` 配置项目规则

二、底层原理：编译期 `this` 转换

一、核心原理解释：物理视角的分类法

1. 问题：`malloc` 是个"全局锁"

三、`for (auto _ : state)` 的作用

总线锁（Lock Asserted）与缓存锁（Cache Locking）

悲观锁（Mutex）与乐观锁（CAS 自旋）的底层成本对比