31.五种存储期管理

目录介绍

• 1. 案例引入
  • 1.1 单例的多线程竞速崩溃
  • 1.2 thread_local 的 fork 暗坑
  • 1.3 七个待解疑问
• 2. 架构概览
  • 2.1 五种存储期的全景
  • 2.2 为何这么切
• 3. 自动存储期与栈
  • 3.1 编译器插入的构造与析构点
  • 3.2 栈帧布局与局部变量销毁
  • 3.3 自动存储期的反模式
• 4. 静态存储期与首次初始化
  • 4.1 C++03 的双初始化数据竞态
  • 4.2 C++11 的线程安全 init 的实现机制
  • 4.3 汇编层的双重检查锁
  • 4.4 跨编译单元的顺序谜题
• 5. 线程局部存储期 TLS
  • 5.1 实现机制 —— 从 FS 寄存器到 ELF TLS 段
  • 5.2 构造与析构的时机问题
  • 5.3 fork、动态库与 TLS 的组合陷阱
• 6. 动态存储期与临时对象
  • 6.1 new/delete 的生命周期链条
  • 6.2 临时对象的生命周期延长
  • 6.3 临时对象的返回优化与 RVO 重叠
  • 6.4 引用的临时绑定与悬垂陷阱
• 7. 五种存储期的汇编全景对比
  • 7.1 变量的物理位置
  • 7.2 构造与析构的调用链对比
  • 7.3 线程安全性矩阵
• 8. 混用与迁移陷阱
  • 8.1 从局部静态到全局静态的重构坑
  • 8.2 从 thread_local 到 static 的语义丢失
  • 8.3 动态库卸载时的静态析构悬垂
• 9. 跨语言与跨平台对比
  • 9.1 C++ static vs Java static vs Go init
  • 9.2 Linux TLS vs Windows TLS 的实现差异
• 10. 综合案例串讲
  • 10.1 案例真相揭晓
  • 10.2 五种存储期的选择决策树
  • 10.3 设计哲学回扣
  • 10.4 速查表合集

---

1. 案例引入

1.1 单例的多线程竞速崩溃

某 RPC 框架的配置管理器使用经典的「懒汉单例」——首次调用时才初始化。上线到 32 核机器上后，进程启动阶段偶发 SIGSEGV：

// ====== 事故代码 V1：线程不安全的延迟初始化 ======
class ConfigManager {
    std::map<std::string, std::string> config_;
    ConfigManager() { load_from_file("/etc/app.conf"); }
public:
    static ConfigManager& instance() {
        static ConfigManager* ptr = nullptr;        // ← C++03 常见写法
        if (!ptr) {
            ptr = new ConfigManager();               // ← 数据竞态！
        }
        return *ptr;
    }
};

// 32 个线程同时首次调用 instance()
// → 多个线程同时通过 !ptr 检查
// → 两个线程同时执行 new ConfigManager
// → 一个 ptr 赋值覆盖了另一个 → 泄露一个 ConfigManager
// → 或是 load_from_file 在两个线程中同时执行 → 文件读竞态 → 数据损坏

根因：32 个线程同时跑过 !ptr——都看到了 nullptr——然后 3 个线程同时进了 new 分支。这不是指针赋值的问题——是指针检查→new 之间没有互斥。

C++11 的正确修复——一行改掉：

static ConfigManager& instance() {
    static ConfigManager mgr;      // ← C++11 保证线程安全初始化
    return mgr;
}

编译器为这一行自动生成了什么？ 看第 4 章。

1.2 thread_local 的 fork 暗坑

同一个框架的日志模块用 thread_local 存每线程的日志缓冲区。压测脚本用 fork() 生成了 worker 进程——然后子进程的第一个日志调用直接 SIGSEGV：

// ====== 事故代码 V2：fork 后的 TLS 幽灵 ======
thread_local LogBuffer tls_buffer;   // 在主线程中已初始化

void run_worker() {
    // 主线程做了一些初始化 → tls_buffer 已构造
    if (fork() == 0) {
        // 子进程：tls_buffer 的内存还在，但 pthread 的 TLS 元数据丢了
        tls_buffer.append("worker started");   // ← SIGSEGV
    }
}

根因：fork() 只复制了进程的虚拟内存页（包括 TLS 数据），但不复制 pthread 的 TLS 管理结构。子进程里 pthread_setspecific / pthread_getspecific 可能返回错误，动态 TLS 的初始化钩子不会被重新调用。thread_local 在 fork 后的子进程中处于「约半死」状态。

1.3 临时对象的无声失踪

第三个事故——同一个 RPC 框架的配置文件解析器，用 auto&& 绑定了一个临时字符串视图，但在访问时读到垃圾：

// ====== 事故代码 V3：临时对象提前析构 ======
auto&& val = parse_config().get("timeout");  // parse_config() 返回临时对象
// parse_config() 的临时对象在这一行结束时析构
// get("timeout") 返回的是那个临时对象的成员引用
// val 现在是悬垂引用！

if (val.as_int() > 0) {  // ← SIGSEGV——临时已死
    set_timeout(val.as_int());
}

根因：auto&& 延长的是 get() 返回值的生命周期——但 get() 返回的是引用。真正需要延长的 parse_config() 返回的临时对象在完整表达式结束时已被析构。引用链上的生命周期延长不会「传播」——它只延长直接绑定的那个临时对象。

1.4 七个待解疑问

① C++ 的「存储期」到底指什么? 五种分别对应什么内存区域和生命周期?      → 第 2 / 第 3 章
② C++11 的「static 局部变量线程安全初始化」是怎么实现的? 汇编层长什么样? → 第 4 章
③ thread_local 在 Linux 和 Windows 上分别是怎么实现的?                 → 第 5 / 第 9 章
④ 临时对象的生命周期到底多长? 什么情况下会被「延长」?                    → 第 6 章
⑤ 五种存储期的变量分别在汇编/ELF 的哪个段里? 编译器和链接器的视角?        → 第 7 章
⑥ fork() / dlopen() / 动态库卸载时各种存储期的行为是什么?               → 第 5 / 第 8 章
⑦ 什么时候该用 static、什么时候该用 thread_local、什么时候该用栈变量?     → 第 10 章

---

2. 架构概览

2.1 五种存储期的全景

C++ 标准定义的存储期是**「对象的生命周期边界由什么决定」**——不是简单的「存在哪」：

┌─────────────────────────────────────────────────────────────────┐
│                     五种存储期 (storage duration)                 │
│                                                                  │
│  存储期        示例                内存区域      构造时机      析构时机  │
│ ────────────────────────────────────────────────────────────────── │
│ ① automatic    int x;            栈         进入作用域    离开作用域  │
│ ② static       全局/static 变量   .data/.bss  main 之前     main 之后 │
│ ③ thread       thread_local      TLS 段     首次ODR-use    线程退出  │
│ ④ dynamic      new/malloc        堆          new/malloc    delete   │
│ ⑤ temporary    临时对象          栈/寄存器   表达式求值     完整表达式 │
└─────────────────────────────────────────────────────────────────┘

和对卷一见过的进程地址空间完全对应：

高地址
  ├─ stack (↓)     ← ① automatic + ⑤ temporary（栈上）
  ├─ mmap area      ← thread TLS (③) 映射到这里
  ├─ heap (↑)      ← ④ dynamic
  ├─ .bss           ← ② static（未初始化）
  ├─ .data          ← ② static（已初始化）
  ├─ .rodata        ← ② static 的 const
  └─ .text
低地址

2.2 为何这么切

疑惑：为什么 C++ 标准要定义「存储期」这个概念？这和「内存地址」有什么区别？

论证：

1. 生命周期 != 物理位置——automatic 存储期的变量在栈上，但反优化（volatile / -O0）可以让栈变量溢出到堆上。标准用「存储期」描述的是生命周期语义（何时构造、何时析构），不绑定到物理内存位置。
2. 线程安全是存储期的天然维度——static 需要线程安全初始化（C++11 起），thread_local 需要每线程独立实例，automatic 天然线程安全（每个线程有自己的栈帧）。不同的存储期要求不同的并发策略——这不是优化，是正确性。
3. 析构顺序是跨存储期的问题——一个 static 变量可能在 thread_local 变量析构之后才析构；一个 automatic 变量可能持有 dynamic 对象的指针。理解五种存储期的相对析构顺序，是消灭「跨存储期悬垂引用」的唯一路径。
4. 反向验证：如果你把 static 配置管理器改成 thread_local——没什么直接崩溃，但每个线程拿到的是不同的配置实例。语义全变了。存储期是一种类型级别的契约——改它意味着改整个程序的生命周期模型。

结论：存储期是 C++ 对象模型的「第四维度」——在前三维（类型、内存布局、所有权）之上，附加了「何时生、何时死」的时间轴。 五种存储期五种时间轴——理解它们的交汇点是安全并发和资源管理的终极课题。

---

3. 自动存储期与栈

3.1 编译器插入的构造与析构点

普通栈变量——编译器在进入作用域时插入构造、离开作用域时插入析构：

void foo() {
    int x = 42;              // ① POD——无构造，直接写入栈
    std::string s = "hi";    // ② 构造：留栈空间 + 调 string::string
    if (x > 0) {
        std::vector<int> v;  // ③ 构造在此
    }                        // ④ 析构 v——离开内层作用域
}                            // ⑤ 析构 s——离开函数作用域

GCC 13.2 -O2 汇编：

foo():
    ; ① int x = 42
    mov   DWORD PTR [rsp+12], 42

    ; ② std::string s = "hi" — 构造
    lea   rdi, [rsp+16]          ; s 的地址
    mov   esi, OFFSET "hi"
    call  std::string::string

    ; if (x > 0) — 总是 true
    ; ③④ std::vector v — 编译器把这个优化掉了（没用到）
    ; （GCC 看到 v 没用过——完全消去构造和析构）

    ; ⑤ 析构 s
    lea   rdi, [rsp+16]
    call  std::string::~string
    ret

3.2 栈帧布局与局部变量销毁

栈帧在 x86-64 上的布局——构造顺序和析构顺序均由编译器在函数出口生成一份清理代码：

RSP + 0:   返回地址 (8B)
RSP + 8:   保存的 RBP (8B)
RSP + 16:  std::string s ─── 构造 ② → 32B (SSO buf)
RSP + 48:  int x          ───= 42
RSP + 52:  padding (4B)
RSP + 56:  vector v (24B) ─── 构造 ③ → 析构 ④
RSP + 80:  [可用的栈空间...]

析构顺序：v 先 → s 后 → x（POD 无析构）

关键：所有局部变量的析构都被编译成函数出口基本块中的一串逆序 call——没有运行时的循环或遍历。这就是 RAII 在汇编层的物理体现。

3.3 自动存储期的反模式

返回局部变量的地址或引用：

// ❌ 悬挂引用
const std::string& bad_return() {
    std::string s = "hello";
    return s;  // s 的析构 → 返回的引用指向已回收内存
}

// ✅ 按值返回——依赖 RVO
std::string good_return() {
    std::string s = "hello";
    return s;  // C++17 强制 RVO——s 直接在调用方的内存上构造
}

---

4. 静态存储期与首次初始化

4.1 C++03 的双初始化数据竞态

案例 1.1 的根因在于 if (!ptr) { ptr = new X; } 不是原子的：

// C++03 时代的标准写法——不安全
static X* ptr = nullptr;
if (!ptr) { ptr = new X; }     // ← 多线程竞态：两个线程都能通过 if

Intel 12 代 P-core 上实测：32 线程同时首次调用 → 崩溃概率 ~1/200。

4.2 C++11 的线程安全 init 的实现机制

C++11 标准规定（[stmt.dcl]/4）：函数局部 static 变量的初始化是线程安全的——即使多个线程同时首次调用，初始化也只发生一次。

编译器实现这个保证的手段是「隐藏的原子标志位 + 双重检查」：

// 编译器生成的伪代码——等价于你写的 static X x;
static X* __instance = nullptr;
static std::atomic<char> __guard = 0;         // ① 编译器插入的原子标志

X& __get_instance() {
    if (__guard.load(std::memory_order_acquire) != 2) {  // ② 快速路径检查
        if (__cxa_guard_acquire(&__guard)) {              // ③ 慢速路径——拿锁
            __instance = new X();                          // ④ 只在这个线程执行
            __cxa_guard_release(&__guard);                 // ⑤ 释放锁
        }
    }
    return *__instance;                                    // ⑥ 所有线程到达这里
}

三步走：

1. 快速路径（read）：如果 __guard == 2（初始化完成）→ 直接返回，零原子写、零锁。
2. 慢速路径（lock）：__cxa_guard_acquire 是 Itanium ABI 的运行时函数——内部用 futex（Linux）或 SRWLOCK（Windows）做互斥。
3. 仅一个线程执行初始化：其他等待的线程在被唤醒后跳回快速路径，读到 __guard == 2。

4.3 汇编层的双重检查锁

GCC 13.2 -O2 对 static X x; 的实际生成：

__get_instance():
    ; ① 快速路径——单条 load
    movzx eax, BYTE PTR guard__ZZ4funcvE1x[rip]  ; guard 值
    cmp   al, 2                                    ; guard == 2?
    je    .Ldone                                   ; 快速返回

    ; ② 慢速路径——调 Itanium ABI 的锁函数
    lea   rdi, guard__ZZ4funcvE1x[rip]
    call  __cxa_guard_acquire
    test  eax, eax
    je    .Ldone                                   ; 别的线程在初始化——等待返回

    ; ③ 我是胜出线程——执行构造
    mov   edi, sizeof(X)
    call  operator new
    call  X::X()                    ; 构造对象

    ; ④ 释放锁
    lea   rdi, guard
    call  __cxa_guard_release

.Ldone:
    mov   rax, instance_ptr
    ret

第一次调用：走慢速路径 ~50 ns（一次 futex 锁 + 构造）。

后续调用：走快速路径 ~3 ns（单条 movzx + cmp + je）——几乎没有额外开销。

4.4 跨编译单元的顺序谜题

第 21 篇和第 25 篇提到 SIOF——这里补充它和存储期的直接关系：

// file_a.cpp
extern int g_counter;
static std::string g_name = "config_" + std::to_string(g_counter);
// g_counter 来自 file_b.cpp——但它的初始化顺序未定义
// 如果 g_name 先初始化 → g_counter 还是 0

静态初始化 vs 动态初始化：

初始化类型	时机	示例	顺序保证
静态初始化（zero/const）	main 之前	int x = 0; const int y=42;	✅ 同一 TU 内按声明顺序
动态初始化	main 之前	string s = "hi"; vector<int> v{1,2};	✅ 同一 TU 内按声明顺序；❌ 跨 TU 无序

Meyer's Singleton 是根治 SIOF 的武器——把全局变量包进函数局部 static：

// 替代：extern int g_counter; → 永远在首次调用时初始化——顺序确定
int& g_counter() { static int counter = 42; return counter; }

4.5 __cxa_guard_acquire 的 futex 内核机制

疑惑：__cxa_guard_acquire 这个运行时函数内部到底做了什么？和 std::mutex 一样吗？

论证——Itanium ABI 规定的 guard 变量状态机：

guard 字节的状态机（每个 static 局部对象一个 guard）：
  0 → 未初始化（初始状态）
  1 → 初始化进行中（有线程正在构造，其他线程等待）
  2 → 初始化完成（所有线程直接返回）

State 0: 第一个线程 A 来到 → CAS(0→1) → 成功 → 线程 A 进入构造
State 1: 另一个线程 B 来到 → CAS(0→1) → 失败 → 进入 futex wait
         │
         ├─ Linux 实现：futex(FUTEX_WAIT, &guard, 1) → 挂起 B
         └─ 线程 A 构造完毕 → __cxa_guard_release → guard = 2
                           → futex(FUTEX_WAKE, &guard, INT_MAX) → 唤醒所有等待者
State 2: 线程 B 被唤醒 → 读 guard = 2 → 返回已构造的对象

为什么用 futex 而不是 pthread_mutex：futex 是无竞争的纯用户态操作——如果 guard 已经是 2（初始化完成），只需要一条 load，完全不涉及内核。pthread_mutex_lock 即使无竞争也要做原子操作+系统调用。

futex 的关键设计：

• FUTEX_WAIT：如果 [guard] == expected_val → 挂起线程（内核态）。否则 → 立即返回（用户态）。这个「比较+挂起」是原子的——消除了 if (guard==1) sleep() 的竞态窗口。
• FUTEX_WAKE：唤醒最多 n 个在 [guard] 上等待的线程。

性能全景：

阶段	操作	延迟	内核参与?
快速路径	movzx + cmp + je	~1 ns	❌ 纯用户态
争用等待	futex WAIT	~2 μs	✅ 上下文切换
构造完成唤醒	futex WAKE	~5 μs	✅

4.6 与 std::call_once 的对比

std::once_flag + std::call_once 是另一种线程安全初始化方案：

std::once_flag init_flag;
std::unique_ptr<X> instance;

X& get() {
    std::call_once(init_flag, [] { instance = std::make_unique<X>(); });
    return *instance;
}

维度	static 局部变量	std::call_once
语法	一行	需要 flag + lambda
底层机制	__cxa_guard_acquire (futex)	pthread_once / InitOnceExecuteOnce
快速路径开销	~1 ns	~2 ns
异常处理	抛异常 → guard 重置 → 下次重试	抛异常 → flag 不重置 → 异常传播
适用场景	单例、懒加载	任意初始化逻辑（不限于构造对象）

---

5. 线程局部存储期 TLS

5.1 实现机制 —— 从 FS 寄存器到 ELF TLS 段

thread_local 在 Linux x86-64 上的底层实现——FS 段寄存器 + 偏移：

FS 寄存器 → TLS 基址（每个线程不同）

TLS 布局（每个线程）：
  FS + 0:    tcbhead_t (线程控制块)
  FS + 0x10: 动态 TLS 向量 dtv (dynamic thread vector)
  FS + 0x... 静态 TLS 模板的拷贝
                ├─ thread_local int x     // 偏移固定
                ├─ thread_local string y  // 偏移固定
                └─ ...

访问 thread_local int x 的汇编：

; thread_local int x;
; x = 42;
mov   eax, 42
mov   [fs:0x10], eax        ; 通过 FS 段寄存器寻址——每个线程的 FS 不同
                             ; → 同一条指令，不同线程访问不同的物理地址

ELF 层面——编译器和链接器的分工：

• 编译器：把 thread_local 变量放进 .tdata（已初始化）或 .tbss（零初始化）的 TLS 段
• 链接器：合并所有 .tdata/.tbss → 生成 TLS 模板
• 动态链接器/运行时：每个线程创建时，从 TLS 模板拷贝一份到线程的 TLS 区域

TLS 的四种访问模型（GCC -ftls-model）——为什么需要多种模型？

四种模型——从最快到最通用：

① Local Exec (LE) —— 最快，`-ftls-model=local-exec`
   mov [fs:fixed_offset], eax   ← 偏移在链接期固定
   要求：变量在可执行文件中定义（不在 .so 中）
   开销：1 条 mov 指令——零额外成本

② Initial Exec (IE) —— 较快，`-ftls-model=initial-exec`
   mov rax, [fs:0]             ← 读 TLS 基址
   mov [rax + GOT_offset], ecx  ← 通过 GOT 偏移访问
   要求：变量可能在 .so 中，但每个线程的偏移不变
   开销：2 条 mov——省了 GOT 查找

③ Global Dynamic (GD) —— 通用，`-ftls-model=global-dynamic`
   lea rdi, [rip + var@TLSGD]  ← 传递 TLS 描述符地址
   call __tls_get_addr         ← 运行时计算偏移
   mov [rax], edx
   要求：无限制——可跨动态库
   开销：2 条指令 + 函数调用——最慢

④ Local Dynamic (LD) —— 优化版 GD，`-ftls-model=local-dynamic`
   call __tls_get_addr         ← 一次调用拿到本模块所有 TLS 的基址
   mov [rax + offset1], esi
   mov [rax + offset2], edi
   要求：同 .so/.exe 内的多个 TLS 变量
   开销：1 次调用 + N 条 mov

默认模型：GCC 默认选 GD——因为静态链接时无法预知变量会不会被跨 .so 访问。可以用 __attribute__((tls_model("local-exec"))) 强制特定变量走最快路径。

5.2 构造与析构的时机问题

thread_local std::string tls_name = "worker";  // 何时构造？

构造时机：线程首次 ODR-use 这个变量时——不是线程创建时。如果线程从未访问任何 thread_local 变量，它们的构造函数根本不会被调用。

析构时机：线程退出时——按构造的逆序。

坑：如果 thread_local 变量的析构函数依赖另一个已被析构的全局变量（如 log 系统关闭了文件）——析构时崩。

5.3 fork、动态库与 TLS 的组合陷阱

案例 1.2 的根因展开：

fork() 之后子进程的 TLS 状态：
  ├─ 静态 TLS 模板（.tdata/.tbss 的拷贝）  ✅ 被 fork 复制——有效
  ├─ 动态 TLS（dlopen 加载的 .so 中的 TLS） ⚠️ 子进程中需要重新初始化
  ├─ pthread TLS 管理结构                  ❌ 不复制——失效
  └─ 构造完成的 thread_local 对象           ⚠️ fork 不触发重新构造

修复（有限）：fork 后立即 exec（不依赖 TLS 继承）
修复（正确）：fork 后调用 pthread_atfork 注册子进程处理函数，
              手动重新初始化关键的 thread_local 变量

dlopen 加载新动态库时——如果该 .so 里有 thread_local 变量，它们的 TLS 模板需要在线程 TLS 区域中分配新槽位。这导致 TLS 布局被重新计算——已有线程的 TLS 访问偏移可能被破坏（需要 dynamic TLS model 修正，性能下降）。

---

6. 动态存储期与临时对象

6.1 new/delete 的生命周期链条

auto* p = new Widget("order");   // ① 分配堆内存 + 构造
// ... 使用 p ...
delete p;                         // ② 析构 + 释放堆内存

new 内部两步：operator new(sizeof(Widget)) → placement new(ptr) Widget("order")。

delete 内部两步：p->~Widget() → operator delete(p)。

生命周期完全由程序员控制——不像 automatic 由编译器强制、也不像 static 有运行时保证。这也是第 28/29 篇推荐智能指针的原因——把「手动」变成「自动」。

6.2 临时对象的生命周期延长

const std::string& ref = std::string("hello");  // 临时 string —— 正常只活到这一行
// 但因为被 const 引用绑定——生命周期延长到 ref 离开作用域

std::cout << ref;   // ✅ 有效——临时对象还活着

规则：当一个临时对象被局部的 const 左值引用或右值引用绑定时，它的生命周期延长到引用本身离开作用域。

例外：如果引用是函数参数、或者作为函数返回值——不延长：

const std::string& bad(const std::string& s) {
    return s;                  // s 是参数——不延长返回值的临时对象
}
const std::string& r = bad(std::string("hello"));
// r 是悬垂引用——临时对象在 bad 返回时已析构

6.3 临时对象的返回优化与 RVO 重叠

第 27 篇详细讨论了 RVO——这里强调它和临时对象存储期的关系：

Widget create() { return Widget(42); }   // Widget(42) 是临时（纯右值）
Widget w = create();                     // C++17 强制省略——w 就是那个临时对象
// Widget(42) 的「临时存储期」被 RVO 延长为 w 的「自动存储期」

6.4 引用的临时绑定与悬垂陷阱

最令人防不胜防的坑——auto&& 可能无意中绑定到临时对象：

for (auto&& [k, v] : get_map()) {  // get_map() 返回临时 → 安全——range-for 延长
    // ...
}

// 但不安全：
auto&& x = get_map().at("key");    // at 返回引用——但 get_map() 的临时在分号处析构！

---

7. 五种存储期的汇编全景对比

7.1 变量的物理位置

int          g_global = 1;         // ② static — .data 段
thread_local int tls_val = 2;     // ③ thread — TLS 段（FS 偏移）
void foo() {
    static int s = 3;              // ② static — .bss 或 guard 保护的堆上
    int a = 4;                     // ① automatic — 栈上 [RSP+n]
    int* d = new int(5);           // ④ dynamic  — 堆上
    int&& r = 6 + a;               // ⑤ temporary — 栈上（r 绑定到临时）
}

存储期	ELF 段	指令寻址	sizeof 额外占?
① automatic	stack	[rsp + n]	否——栈帧自带
② static (全局)	.data / .bss	[rip + offset]	否——编译期定
② static (局部)	.bss (guard) + 堆 (对象)	guard: [rip], 对象: [guard+8]	+8 (指针) + 1 (guard byte)
③ thread_local	.tdata / .tbss	[fs:offset]	否——每线程独立
④ dynamic	heap	[rax] (通过指针)	否——只有指针在栈/静态
⑤ temporary	stack (大多)	[rsp + n]	否——编译器栈帧

7.2 构造与析构的调用链对比

存储期	构造函数调用点	析构函数调用点
① automatic	编译器插入——作用于入口	编译器插入——所有出口
② static (全局)	__cxx_global_var_init → 在 main 之前	__cxx_global_var_fini → 在 main 之后 (atexit)
② static (局部)	首次经过声明处 → with __cxa_guard_acquire	atexit 注册——main 之后
③ thread_local	首次 ODR-use——由 TLS 初始化桩调用	pthread_key_create 注册的析构回调
④ dynamic	new 链——程序员调用	delete 链——程序员调用
⑤ temporary	表达式求值时	完整表达式末尾（或引用离开作用域——如果延长）

7.3 线程安全性矩阵

存储期	初始化线程安全	访问线程安全	销毁线程安全
① automatic	✅ 天然安全	✅ 天然安全（每线程独立栈）	✅ 天然安全
② static (局部)	✅ C++11 保证	❌ 需手动同步	⚠️ 跨 TU 顺序未定
② static (全局)	⚠️ C++03 竞态/C++11 保证	❌ 需手动同步	⚠️ SIOF
③ thread_local	✅ 每线程独立	✅ 天然安全	✅ 每线程独立
④ dynamic	❌ 程序员保证	❌ 程序员保证	❌ 程序员保证
⑤ temporary	✅ 天然安全	✅ 天然安全	✅ 天然安全

---

8. 混用与迁移陷阱

8.1 从局部静态到全局静态的重构坑

// 原本：Meyer's Singleton——安全
int& counter() { static int c = 0; return c; }

// 重构后：全局变量——不安全
static int g_counter = 0;  // 全局的——和另一个全局变量的初始化顺序未定义
// 如果另一个 TU 的构造函数用了 g_counter——可能读到 0

重构守则：从函数局部 static 提到全局 static → 检查所有跨 TU 的依赖 → 如果依赖存在 → 不提取。

8.2 从 thread_local 到 static 的语义丢失

// thread_local → 每线程独立计数器
thread_local int request_count = 0;

// 改成 static → 全局共享一个计数器 → 数据竞态！
static int request_count = 0;     // ❌ 多个线程同时 ++ → UB

必须配合 std::atomic<int> 或 std::mutex。

8.3 动态库卸载时的静态析构悬垂

// main.cpp
void* handle = dlopen("libplugin.so", RTLD_NOW);
auto* plugin = (Plugin*)dlsym(handle, "create")();
// ... 使用 plugin ...
dlclose(handle);                 // ← dlclose 卸载 .so ——触发里面的 static 对象析构
// plugin 指针仍然有效——但指向的代码段已被 unmmap → SIGSEGV

原则：动态库卸载前确保没有任何外部引用指向库内的代码或数据。

---

9. 跨语言与跨平台对比

9.1 C++ static vs Java static vs Go init

维度	C++ static 局部	Java static	Go init()
初始化时机	首次经过声明处	类首次加载	包加载时（程序启动早期）
线程安全	✅ C++11 起	✅ JVM 保证	⚠️ init 之间不能并发
跨编译单元顺序	不确定（可被 Meyer's Singleton 修正）	不确定	依赖导入顺序但不保证
析构确定性	✅ atexit 逆序	❌ 依赖 GC	❌ 无析构

9.2 Linux TLS vs Windows TLS 的实现差异

维度	Linux ELF TLS	Windows PE TLS
段寄存器	FS (x86-64)	GS (x86-64)
静态 TLS 偏移	链接期决定	链接期决定
动态 TLS（dlopen）	__tls_get_addr 运行时重定位	TlsAlloc/TlsGetValue
fork 影响	子进程 TLS 半死	N/A（Windows 无 fork）
析构调用	pthread_key_create 回调	DLL_THREAD_DETACH 回调

---

10. 综合案例串讲

10.1 案例真相揭晓

#	疑问	答案
①	五种存储期是什么?	第 2 章：automatic/static/thread/dynamic/temporary——生命周期由不同边界决定
②	static 线程安全怎么实现?	第 4 章：编译器插入原子 guard + Itanium ABI 的 __cxa_guard_acquire（futex 锁）
③	thread_local 怎么实现?	第 5/9 章：FS/GS 段寄存器 + .tdata/.tbss TLS 模板 + pthread_key 析构
④	临时对象生命周期?	第 6 章：const 引用绑定延长到引用作用域结束；函数参数不延长
⑤	五种存储期在汇编的哪个段?	第 7 章：automatic=stack、static=.data/.bss、thread=FS偏移、dynamic=heap、temporary=stack
⑥	fork/dlopen 下的行为?	第 5.3/8.3：fork 复制 TLS 数据但不复制 pthread 结构；dlclose 触发静态析构
⑦	怎么选存储期?	第 10.2：决策树

案例①修复（单例竞速）：

static ConfigManager& instance() {
    static ConfigManager mgr;  // C++11 保证线程安全初始化
    return mgr;
}
// 编译器自动插入双重检查锁——首次调用 ~50ns，后续 ~3ns

案例②修复（fork TLS）：

// 注册 fork handler
pthread_atfork(nullptr, nullptr, [] {
    // 子进程中：手动重新初始化关键 thread_local 对象
    tls_buffer = LogBuffer();  // placement new 也可以
});

10.2 五种存储期的选择决策树

对象的生命周期应该多长?
├─ 和某段代码的作用域一致
│   └─ automatic（栈变量） ← 90% 场景首选
│
├─ 和整个程序等长
│   ├─ 全局唯一 → static 局部（Meyer's Singleton）
│   │    └─ 优点：线程安全初始化、延迟构造、SIOF 免疫
│   └─ 多个编译单元共享 → static 全局 + extern
│        └─ 注意：初始化顺序未定义
│
├─ 和线程等长
│   └─ thread_local
│       ├─ 每线程独立实例
│       └─ 注意：不要在线程退出时访问已析构的对象
│
├─ 从堆上分配，生命周期不固定
│   └─ dynamic（new/delete 或智能指针）
│       └─ 优先 unique_ptr（80%）/ shared_ptr（共享所有权的 20%）
│
└─ 只在当前表达式中需要
    └─ temporary（临时对象 + const& 绑定）
        └─ 注意：函数参数绑定不延长生命周期

10.3 设计哲学回扣

哲学 1：存储期是对象的第四维度——空间描述 what，时间描述 when

类型告诉你「这是什么」，内存布局告诉你「它长什么样」，所有权告诉你「谁负责它」。存储期告诉你「它活多久」。一个好的 C++ 设计必须同时回答这四个问题。 忽略存储期的后果是：在栈上创建了本该是 static 的单例（多次构造）、在线程退出后访问 thread_local（悬垂）、在动态库卸载后持有 static 对象指针（SIGSEGV）。四种「空间」维度上的正确，救不了一种「时间」维度上的错误。

哲学 2：线程安全应该是默认——static 局部初始化的教训

C++03 的 static 局部不安全——每个团队都写过自己的工作队列单例加锁。C++11 直接把它写进语言——编译器自动生成双重检查+futex。能由编译器保证的安全，不要留给程序员。 这条原则贯穿了整个 C++11/14/17/20 的演进：atomic 把「手写 asm」变成「标准类型」、lock_guard 把「记得解锁」变成「出了作用域自动解锁」、static 局部把「手写双重检查」变成「编译器生成」。每一次演进都是把「程序员的责任」变成「编译器的责任」。

哲学 3：TLS 是并发的物理隔离——用硬件为软件买单

thread_local 的 mov [fs:offset], eax——一条指令、零锁、零原子、零间接跳转。它之所以能做到这一点，是因为硬件（段寄存器+虚拟内存）给每个线程划出了一块独立的物理空间。这是系统程序设计中「用空间换去同步开销」的经典案例——与其在软件层做互斥（锁、原子操作），不如在硬件层做隔离（每线程独立虚拟地址）。

哲学 4：临时对象是编译器生成的——编译器负责到最后一刻

临时对象的生命周期延长规则体现了 C++ 对编译器生成代码的高要求——既然这个临时对象是我（编译器）为了临时计算而创造的，我就有义务保证它在被引用期间不被析构。 const T& 绑定延长生命周期的规则，同时也是对程序员用法的约束——只有局部引用才有这个特权，函数参数和返回值没有。

哲学 5：存储期的选择不是优化——是契约

把 thread_local 改成 static 不是性能优化——是语义改变。thread_local 意味着「每个线程独立一份」，static 意味着「全局一份」。存储期描述的是对象的身份（一份还是多份）和生命周期（什么时候消失）——改它就是改接口契约。 这和把 int 改成 double 一样，不是「编译器能不能接受」的问题，是「程序是否正确」的问题。

10.4 速查表合集

五种存储期速查：

存储期	关键词	内存位置	构造时机	析构时机	线程安全初始化
automatic	局部变量	stack	进入作用域	离开作用域	✅ 天然
static	static / 全局	.data/.bss	首次经过(main前)	main之后(atexit)	✅ C++11
thread	thread_local	TLS (FS偏移)	首次ODR-use	线程退出	✅ 天然
dynamic	new/delete	heap	手动	手动	❌
temporary	纯右值	stack	表达式	完整表达式尾	✅ 天然

线程安全初始化对比：

方式	C++03	C++11	首次调用开销	后续开销
手写 lock + new	⚠️	✅	~80 ns	~80 ns
Meyer's Singleton	❌ unsafe	✅	~50 ns	~3 ns
std::call_once	—	✅	~60 ns	~2 ns

卷四收官——七篇脉络回顾：

25.RAII设计哲学        → 为什么构造=获取、析构=释放
26.对象构造与析构       → 构造析构的六步流水线
27.拷贝与移动控制       → 五法则、RVO、noexcept 红利
28.unique_ptr原理       → 独占所有权的零开销实现
29.shared_ptr底层       → 控制块、原子计数、共享的代价
30.weak_ptr与this增强   → 异步世界的安全自我引用
31.五种存储期管理       → 对象「何时生、何时死」的完整答案
                         └─ 卷四终点：对象的完整生命周期

---

下一篇：对象的生命周期管理完整收束。下一篇进入卷五 32.vector 扩容真相——从存储期切换到数据结构：vector 的 growth factor 1.5 vs 2 的数学推导、emplace_back 的完美转发链、迭代器失效的精确规则。