CppCon 2016 学习:Lifetime Safety By Default

发布于：2025-06-20 ⋅ 阅读:(17) ⋅ 点赞:(0)

这段内容是关于 “C++ 中如何避免资源泄漏（leak freedom）” 的策略总结，来源于某份演讲或海报（poster）。下面我来逐条解释：

主旨：“Leak Freedom” = 不手动 delete，不让资源泄漏

总体口号：

不要用裸指针（raw *）拥有对象

不要手动 delete

避免跨模块的“向上”拥有（即低层拥有高层对象）

三步策略：资源管理的推荐顺序

这三步表示从最安全到最复杂的管理方式，应该优先使用前面的方式，后面的是 fallback 选项。

### 策略 1：使用自动作用域管理的对象

T x;                // 局部变量
class C { T m; };   // 成员变量
  • 生命周期 由作用域控制（stack、RAII）
  • 无需手动释放
  • 最推荐方式
    使用场景：构造体成员、局部变量等
    频率：~80% 的对象都可以用这种方式管理
    示例：类的成员变量，局部变量等

### 策略 2：std::unique_ptr（唯一拥有）

auto p = std::make_unique<T>();
  • 当对象需要在堆上分配，但可以保证唯一拥有
  • 自动管理生命周期，出了作用域自动析构
  • 可以传递、移动，但不能复制
    使用场景：
  • 节点型数据结构（链表、树等）
  • 所有权清晰，没有共享
    大约覆盖 ~20% 的用例
    示例：std::unique_ptr<Node> 实现二叉树等

### 策略 3：std::shared_ptr（共享拥有）

auto p = std::make_shared<T>();
  • 适用于需要多个对象共享同一个资源的场景
  • 基于引用计数（RC），引用数为 0 时自动释放
  • 适用于 DAG（有向无环图）结构，但不适合有循环引用
    使用场景：
  • 多方共享资源、事件系统、观察者模式
  • 适合库中的通用资源管理
    示例：图结构中某个节点有多个父节点指向它

注意：如何避免循环引用

std::shared_ptr<A> a;
std::shared_ptr<B> b;
a->b = b;
b->a = a; //  循环引用，永不释放！

解决方法：

struct B;
struct A { std::shared_ptr<B> b; };
struct B { std::weak_ptr<A> a; };  //  break the cycle

用 std::weak_ptr 打破共享拥有中的所有权环

设计建议

不推荐做法 原因
使用 new/delete 容易内存泄漏或 double-delete
拥有“向上”对象 打破模块层次，容易形成循环或错误析构顺序
裸指针拥有对象 不清楚所有权，容易泄漏或 dangling

总结：三步防泄漏法则

步骤 类型 使用场景 常用函数
1⃣ 局部变量 / 成员变量 自动生命周期 无（直接定义）
2⃣ unique_ptr 独占堆对象 std::make_unique
3⃣ shared_ptr + weak_ptr 共享堆对象 std::make_shared

“HAS-A”关系的自然所有权抽象，我们逐行解释：

问题：HAS-A（拥有关系）

Q: What’s the natural ownership abstraction for containing another object?

A: Part of my class’s representation.

理解

当一个类“拥有”另一个对象（即 HAS-A 关系），最自然的方式就是将它作为该类的非静态数据成员（non-static data member）。
例如：

class MyClass {
    Data data; //  data 是 MyClass 的一部分
};

这意味着：

  • data 会随着 MyClass 的构造而构造
  • data 会随着 MyClass 的析构而析构
  • 生命周期自动关联，无需手动释放
    所以是强拥有权（strong ownership）

结论：不要想太复杂，默认使用成员变量即可！

这是最简单、最安全、最推荐的方式。

所以，“Surprise! (not really)” 的意思是：

大家可能期待有多复杂的管理方法，其实答案就这么简单直白——用成员变量。

如果你想更进一步了解什么时候用指针、引用、unique_ptr 等替代成员对象，也可以问我，比如：

  • 如果 Data 太大，是否用 unique_ptr<Data>？
  • 如果不拥有 Data，是否用 Data& 或裸指针？

如何在 C++ 中默认实现无资源泄漏（leak freedom）的设计。下面我帮你分段解析和总结：

核心设计理念

“通过构造声明生命周期”（Key: Declares lifetime by construction）

如果资源的拥有关系能通过构造函数直接确定，就可以避免：

  • 在函数体中进行繁杂的动态资源分配；
  • 手动 delete；
  • 忘记释放资源等问题。

好的资源管理特性总结：

特性 含义
Key 生命周期通过构造声明，设计上明确
Correct 不需要看函数体就能知道不会泄漏
Efficient 与手动 new/delete 一样快，一样省内存
Robust 严格嵌套的生命周期，出错只能是你手动犯错，不会是语言层疏漏

各种“成员资源”的自然拥有抽象

1. 紧耦合成员：直接定义为成员变量

class MyClass {
  Data data;  // 直接拥有
};

最自然的拥有方式，强绑定生命周期，推荐使用。

2. 解耦合成员（Optional / Changeable） ➜ unique_ptr

Q: 需要可选地存在、懒加载、或者是可变类型的成员，该怎么办？

A: std::unique_ptr

class MyClass {
  std::unique_ptr<Data> pdata;
};

适合：

  • 惰性初始化（lazy initialization）
  • 可选成员（optional）
  • 需要替换为不同实现（多态等）
    注意：如果你不希望为空（not null），需要：
  • 手动实现拷贝/移动构造/赋值
  • 避免移动后为 null 的对象被继续使用（null-after-move）

3. Pimpl（编译防火墙） ➜ const unique_ptr

Q: 怎样表达 Pimpl idiom（编译防火墙）中的所有权？

A: const unique_ptr<T>

template<class T>
using Pimpl = const std::unique_ptr<T>;
class MyClass {
  class Impl;         // 仅在 cpp 中定义
  Pimpl<Impl> pimpl;  // 不可更换的指针
};

特点：

  • const unique_ptr 表示它在构造后不可更换，更安全
  • 防止默认的移动操作搞乱 pimpl 的行为
  • 析构需要在 cpp 中实现（因为 Impl 不完全）

4. 固定大小但运行时决定的数组 ➜ const unique_ptr<T[]>

Q: 想表达“固定大小但动态构造”的数组成员？

A: const unique_ptr<T[]>

class MyClass {
  const std::unique_ptr<Data[]> array;
  int array_size;
  MyClass(size_t num_data)
    : array(std::make_unique<Data[]>(num_data)),
      array_size(num_data) {}
};

适合：

  • 数组大小在构造时确定
  • 不希望数组在对象生命周期中变化
  • 不希望写析构函数来手动释放
    如果你想支持“整体数组移动”，或需要处理“为空”的可能，可以移除 const。

总结：三类成员资源的推荐管理方式

成员类型 拥有方式 使用工具
强耦合成员 值成员 Data data;
解耦合成员 独占动态资源 std::unique_ptr<T>
编译防火墙 独占不可修改资源 const std::unique_ptr<T>
动态数组 固定大小动态数组 const std::unique_ptr<T[]>

如何使用现代 C++ 的 unique_ptr 让树结构天然无内存泄漏，并指出其中唯一需要手动管理的部分：父指针更新。

下面帮你详细分段解释：

问题：树结构的自然所有权抽象是？

Q: What’s the natural ownership abstraction for a tree?

A: std::unique_ptr

class Tree {
  struct Node {
    std::vector<std::unique_ptr<Node>> children;
    /*... data ...*/
  };
  std::unique_ptr<Node> root;
};

原因：

  • 每个节点通过 unique_ptr 拥有它的子节点；
  • 每个节点只有一个拥有者（其父节点）；
  • 递归析构自动释放整棵树，无内存泄漏风险；
  • 无需手动 delete；
  • 生命周期关系一目了然。

如果我们需要从子节点访问父节点？

struct Node {
  std::vector<std::unique_ptr<Node>> children;
  Node* parent;  // 非拥有指针，只是观察父节点
};

注意点：

  • parent 不能是 unique_ptr（否则会形成拥有循环，导致泄漏）；
  • 这是一个 裸指针，仅仅是观察用（non-owning observer）；
  • 需要手动维护：在插入/更换子节点时，记得更新 parent 指针。

关键设计原则复习

属性 描述
Key 生命周期通过构造表达
Correct 不用看函数体就能知道没泄漏
Efficient 和手写 new/delete 一样快
Robust 如果出错，只能是你主动犯错（比如忘了设 parent）

小练习：实现 reparent() 函数

你可以写一个 Node::reparent(Node* new_parent) 函数，来：

  1. 从旧父节点中删除当前节点；
  2. 把自己插入 new_parent->children；
  3. 更新 parent = new_parent；
  4. 确保异常安全（如用 unique_ptr 移动）；
    大致思路如下：
void reparent(Node* old_parent, Node* self, Node* new_parent) {
    // Step 1: Remove from old parent’s children
    auto& siblings = old_parent->children;
    auto it = std::find_if(siblings.begin(), siblings.end(),
                           [self](const std::unique_ptr<Node>& child) {
                               return child.get() == self;
                           });
    if (it == siblings.end()) throw std::runtime_error("not a child!");
    // Step 2: Move self from old to new
    std::unique_ptr<Node> moved_node = std::move(*it);
    siblings.erase(it);
    // Step 3: Insert into new parent's children
    moved_node->parent = new_parent;
    new_parent->children.push_back(std::move(moved_node));
}

总结：树的无泄漏设计

点 说明
所有权结构 unique_ptr<Node> 形成树形结构
生命周期自动管理 根析构 -> 所有子节点析构
parent 指针 非拥有，仅观察，需要手动更新
唯一手动部分 parent 的更新（如 reparent()）
不允许循环引用 所有权只能自上而下

树节点的析构过程，特别是 unique_ptr 管理的树形结构的析构方式，比较了递归析构和手动迭代析构两种方法的优劣，具体如下：

递归析构（默认行为）

void release_subtree(std::unique_ptr<Node> n) {
  // 当 release_subtree 结束时，n 被销毁
  // 自动调用 n->~Node()
  // 进而调用 n->children[0]->~Node()
  // 然后递归调用子节点的析构，直到叶子节点
}
// calls n->~Node()
// n->children[0]->~Node();
// n->children[0]->children[0]->~Node();
// n->children[0]->children[0]->children[0]->~Node();
// n->children[0]->children[0]->children[0]->children[0]->~Node();
// n->children[0]->children[0]->children[0]->children[0]->children[0]->~Node();
// n->children[0]->children[0]->children[0]->children[0]->children[0]->children[0]->~Node();
// n->children[0]->children[0]->children[0]->children[0]->children[0]->children[0]->children[0]->children[0]~Node();
  • 工作原理：析构函数自动递归调用所有子节点的析构函数，实现树形结构的完整销毁。
  • 优点：
    • 自动且正确，代码非常简洁。
  • 缺点：
    • 栈深度可能无界（树的深度过大时会导致栈溢出）。
    • 不适合极深的树结构。

迭代析构（手动管理）

void release_subtree(std::unique_ptr<Node> n) {
  while (n->children.size() > 0) {
    auto leaf = &n->children;
    while (leaf[0]->children.size() > 0)
      leaf = &leaf[0]->children;
    leaf.pop_front();  // 找到一个叶子节点并删除
  }
  // 最后销毁 *n 本身
}
  • 工作原理：
    • 通过手动遍历，先删除叶子节点，再逐层删除。
    • 避免了递归调用。
  • 优点：
    • 栈深度受限，避免栈溢出。
  • 缺点：
    • 代码复杂，手动优化工作。
    • 时间复杂度是 O(N log N)，不够高效。
    • 实现比较繁琐。

其他信息

  • 递归析构是默认方式，简单高效但存在栈溢出风险。
  • 迭代析构是手动优化方式，需要额外实现，但避免递归深度问题。
  • 有一种 O(N) 的迭代析构算法存在，但未展示，可能更复杂。

总结

方式 优点 缺点 适用场景
递归析构 简单，自动，正确 栈深度无限制，深树可能栈溢出 树深度适中
迭代析构 栈深度有界 实现复杂，性能稍差 超深树结构或嵌入式

你这段话总结了不同释放（析构）N节点子树时，除了执行每个节点的析构函数（O(N)）之外，额外成本的差异，包括时间复杂度、栈空间和堆空间开销：

释放 N 节点子树的额外成本

方法 时间复杂度 栈空间开销 堆空间开销 备注
默认递归析构 最小（_） O(N) 最小（_） 简单直接，递归调用析构函数
迭代就地析构 O(N log N) 低（_） 最小（_） 手动遍历子树，逐层析构，栈空间少
迭代复制析构 O(N) O(N) O(N) 将指针复制到局部堆上，迭代析构
迭代延迟析构 O(N) O(N) O(N) 将指针复制到辅助堆上，稍后迭代析构

解释和分析

  • 默认递归析构：
    • 时间是 O(N)，每个节点析构一次。
    • 栈空间和堆空间开销极低（递归调用栈深度与树深度相关，通常不额外分配堆空间）。
    • 最简单直接。
  • 迭代就地析构：
    • 通过手动遍历子树（如寻找叶节点逐个删除），时间复杂度变成了 O(N log N)。
    • 通过循环避免深递归，减少栈空间开销。
    • 几乎不使用额外堆空间。
  • 迭代复制析构：
    • 先把所有节点指针复制（移动）到一个局部容器（如 std::vector）中，然后迭代销毁。
    • 时间复杂度是 O(N)，但需要额外的堆空间存储节点指针。
    • 栈空间占用较少，但内存占用多。
  • 迭代延迟析构：
    • 将节点指针移动到辅助的堆数据结构里，延迟析构（先收集，后统一销毁）。
    • 时间和空间复杂度同上。
    • 适合更复杂的析构策略或异步处理。

总结

  • 默认递归析构适合大部分场景，代码简洁，性能良好。
  • **迭代析构（就地/复制/延迟）**适合：
    • 避免栈溢出（树过深）。
    • 需要控制析构时机。
    • 对空间和时间开销有特殊要求。

这部分讲得非常清晰，关于双向链表和树结构带强引用共享的所有权设计总结：

双向链表的自然所有权抽象

  • 核心设计： 用 unique_ptr<Node> next 表示对后继节点的唯一所有权，指针成员 Node* prev 非拥有指针，指向前驱节点。
  • 手动维护不变式： 每次修改链表（插入、删除、移动节点）时，要确保
    next->prev == this;
  • 类示例：
class LinkedList {
  struct Node {
    std::unique_ptr<Node> next;
    Node* prev;
    // ... 数据成员 ...
  };
  std::unique_ptr<Node> root;
  // ... 链表操作 ...
};
  • 优点：
    • 生命周期通过构造和析构自动管理，无需显式 delete。
    • 不用担心内存泄漏，除非指针维护出错。
    • 性能和空间与手动管理 new/delete 相当。
  • 注意点：
    • 递归析构问题：链表节点析构是递归的，长链表容易造成栈溢出。
    • 解决方案：建议改用迭代析构（手动断开 next，逐个释放），避免深递归。

树结构中带强引用共享的所有权抽象

  • 当数据共享且多个节点持有同一数据时：
    使用 shared_ptr<Node> 来实现节点共享所有权。
  • 类示例：
class Tree {
  struct Node {
    std::vector<std::shared_ptr<Node>> children;
    Data data;
  };
  std::shared_ptr<Node> root;
  std::shared_ptr<Data> find(/* ... */) {
    // 返回节点数据的共享指针（使用 aliasing 构造函数）
    // 例如：
    // return std::shared_ptr<Data>(spn, &(spn->data));
  }
};
  • 原因：
    • 节点和外部代码共享对数据的所有权，生命周期需要自动延长。
    • shared_ptr 允许多个所有者安全管理生命周期。

总结

结构类型 推荐所有权模型 需手动维护的部分 额外注意
双向链表 unique_ptr<Node> next, Node* prev 保持 next->prev == this 不变式 递归析构可能栈溢出，建议迭代析构
树（共享所有权） shared_ptr<Node> 和 shared_ptr<Data> 无，生命周期自动管理 使用 aliasing 构造函数返回数据共享指针

有向无环图（DAG）结构的“自然所有权抽象”及其在 C++ 中如何用智能指针来管理节点生命周期，重点如下：

1. 节点所有权使用 shared_ptr

  • 为什么用 shared_ptr？
    DAG 中节点可能有多个父节点（多重所有者），而不像树中每个节点只有一个所有者。
    所以用 shared_ptr 来管理共享所有权，避免节点提前销毁。
class DAG {
    struct Node {
        std::vector<std::shared_ptr<Node>> children;  // 子节点，拥有所有权
        std::vector<Node*> parents;                    // 父节点，非拥有指针（裸指针）
        /*… 其它数据 …*/
    };
    std::vector<std::shared_ptr<Node>> roots;          // 根节点集合，拥有所有权
    /*… 其它成员 …*/
};
  • 父指针是裸指针（Node*）：
    父节点用裸指针，不拥有所有权，只做导航和引用，避免循环引用。
    手动维护“父指针”指向正确是唯一手动部分（“Only manual part”）。

2. 保持不变式（Invariant）

  • 在修改结构（比如重新连接父子关系）时，确保指针正确更新：

    left->parent == this && right->parent == this

    类似树结构，这里是维护父子关系一致性。

3. 生命周期声明由智能指针完成

  • 用 shared_ptr 明确声明节点的生命周期，由所有者共同决定，程序员无需手动管理内存（“声明生命周期”）。
  • 这样设计可以看代码就能推断无内存泄漏，提高正确性和健壮性。

4. 类似场景扩展

  • 没有环的相互引用对象：
    依然用 shared_ptr 来管理所有权，逻辑和 DAG 类似。
  • 不同类型或不同模块的对象互相引用：
    只要没有循环，shared_ptr 依然是合适的所有权抽象。

5. 示例中还有 shared_ptr 的别名构造函数用法

shared_ptr<Data> find(/*...*/) {
    // spn 是 shared_ptr<Node>
    // 返回 shared_ptr<Data>，别名构造，只共享 spn 的所有权，但指向内部数据成员
    return {spn, &(spn->data)};
}

这是个方便的技巧，让你共享节点所有权，但访问节点内部的 data 成员。

总结

  • 树 用 unique_ptr 管理单一所有权。
  • DAG 用 shared_ptr 管理共享所有权。
  • 父指针用裸指针，避免循环引用。
  • 必须手动维护父子关系一致性。
  • 这样设计既安全又高效，能自动避免内存泄漏。

工厂函数 和 缓存（cache） 场景下的自然所有权选择，核心要点总结如下：

1. 工厂返回堆对象时的所有权

自然选择：

  • 返回 unique_ptr：
    当工厂返回的对象不需要被共享（只有调用方独占所有权），用 unique_ptr 最合适。
    这样清晰表达所有权唯一性，防止误用。
  • 返回 shared_ptr + make_shared：
    如果工厂创建的对象会被多个地方共享（多个所有者），则用 shared_ptr 配合 make_shared，方便管理共享生命周期。

示例代码：

std::unique_ptr<widget> make_widget(int id) {
    return std::make_unique<widget>(id);
}
std::shared_ptr<widget> make_widget(int id) {
    return std::make_shared<widget>(id);
}

总结就是：

  • unique_ptr 用于非共享场景
  • shared_ptr 用于共享场景

2. 缓存对象的所有权管理

需求：

  • 缓存中不强制保持对象存活，对象生命周期只由缓存外的用户决定（缓存不拥有对象的生命周期，只做辅助）。

解决方案：

  • 缓存用 weak_ptr 弱引用对象
  • 用户用 shared_ptr 持有对象所有权
  • 缓存查找时尝试用 weak_ptr::lock() 获取强引用 shared_ptr
  • 如果弱引用失效（对象已被销毁），重新加载对象并存入缓存（用 shared_ptr 更新缓存的弱引用）

示例代码：

std::shared_ptr<widget> make_widget(int id) {
    static std::map<int, std::weak_ptr<widget>> cache;
    static std::mutex mut_cache;
    std::lock_guard<std::mutex> hold(mut_cache);
    auto sp = cache[id].lock();  // 尝试升级为 shared_ptr
    if (!sp) {
        sp = load_widget(id);     // 加载新对象，返回 shared_ptr
        cache[id] = sp;           // 更新缓存的弱引用
    }
    return sp;
}

总结

情境 推荐所有权类型 说明
工厂返回不共享的对象 unique_ptr 明确单一所有权
工厂返回共享的对象 shared_ptr + make_shared 方便管理共享生命周期
缓存不控制对象生命周期 weak_ptr（缓存）+ shared_ptr（用户） 缓存不延长对象寿命，避免内存泄漏和悬挂

关于 C++ 内存管理和所有权设计原则 的总结。主要目的是教你如何合理地管理对象生命周期和所有权，避免内存泄漏和资源管理错误。以下是逐条解析：

1. 默认使用“作用域生命周期”对象（scoped lifetime）

  • 包括：局部变量（local） 和 成员变量（member）
  • 意义：这些对象是直接拥有的，在创建它们的作用域结束时自动析构。
  • “Zero”表示没有额外管理，它们的生命周期直接绑定在作用域中。
  • 占比：约 80% 的对象 都应当使用这种方式。
    优点：
  • 简单、安全。
  • 不需要手动管理内存。
  • 自动析构、不会泄漏。

2. 如果对象需要独立的生命周期（通常是在堆上）并且可以“唯一拥有”**：

  • 用 std::unique_ptr / std::make_unique 或者标准容器（如 std::vector）
  • 适用于：树、链表等数据结构的实现（独占所有权，无共享）
  • 原理上等同于 new/delete 和 malloc/free，但更安全，自动释放。
    应用场景：
  • 对象生命周期比作用域长（如返回值、异步操作）
  • 独占所有权，无引用共享。
    约占 20% 的对象使用场景

3. 如果对象需要独立生命周期并且必须“共享所有权”**：

  • 使用 std::shared_ptr / std::make_shared
  • 用于：有向无环图（DAG）或共享树结构中的节点
  • 相当于自动化的“引用计数”（Reference Counting, RC）
    优点：
  • 简化了手动引用计数逻辑。
  • 多模块共享对象时，使用方便。
    注意：
  • 可能引起循环引用（cycle），导致内存泄漏。
  • 使用 std::weak_ptr 断开循环，防止对象无法析构。

重要警告：

  • 不要使用裸指针（owning raw *）来拥有对象：不要手动 delete**
  • 不要跨模块“向上”持有所有权：例如下层模块不应该持有上层模块的对象 → 破坏模块化层级
  • 如果必须共享但又避免循环，用 weak_ptr 来管理非拥有的引用

总结：推荐的 C++ 对象生命周期策略

生命周期策略 工具 使用比例 示例/说明
Scoped（作用域绑定） 局部变量/成员变量 ~80% 自动析构，无需管理
Unique Ownership（唯一） unique_ptr / 容器 ~20% 树、链表实现，无共享
Shared Ownership（共享） shared_ptr / weak_ptr 少数场景 DAG、引用共享，但注意引用循环问题

**跨模块引用循环（ownership cycles）**的深度分析。下面我帮你逐段解释这些核心思想：

问题：如何避免在模块之间形成引用循环（cycle）？

答案简明：

不要“向上”持有所有权（own upward） —— 也就是：

  • 不要在底层模块中持有对上层模块对象的 shared_ptr。
  • 这样违反了模块层级（layering）原则。

详细说明：

什么是“向上”拥有？

  • 低层模块（例如库）不应持有上层代码的所有权。
  • 举个例子，上层传递一个 shared_ptr 到库内部，并被库缓存下来（store），这就是“own upward”。
  • 如果库内部也通过 shared_ptr 拥有这个对象，就可能形成循环引用：对象 → 库 → 回调 → 对象，最终内存永远释放不了。

【坏例子 #1】：

void bad(const shared_ptr<X>& x) {
    obj.register(x);  // 库可能存储并拥有 x
}
  • 你把 shared_ptr 传给了 obj，而 obj 是**“未知代码”**，可能存储它并参与循环。

【坏例子 #2】：在回调中捕获 shared_ptr

void bad(const shared_ptr<X>& x) {
    obj.on_draw([=]{ x->extra_work(); });  // 闭包捕获 shared_ptr
}
  • 闭包持有 shared_ptr，如果回调又注册在对象 x 内部，就形成了一个典型的循环。

【好做法】：使用 weak_ptr 打破循环

void good(const shared_ptr<X>& x) {
    obj.on_draw([w = weak_ptr<X>(x)]{ 
        if (auto x = w.lock()) x->extra_work(); 
    });
}
  • 这样，闭包里只捕获 weak_ptr，如果对象已经被销毁，不会阻止释放内存。
  • weak_ptr 用于非拥有引用，可以打破引用环。

类比：和“持锁时调用未知代码”一样危险

  • 并发编程中，有个经验法则：不要在持锁状态下调用未知函数，因为它可能也会尝试加锁，导致死锁。
  • 类似地，不要把拥有权传递给可能“存储引用”的未知代码，会导致对象生命周期错乱甚至内存泄漏。

其他语言也有同类问题

  • Java、C# 虽然有 GC，但仍然会出现引用泄漏，特别是忘记注销监听器、回调等。
  • 所以，所有语言都应注意避免结构性循环引用，而不仅仅是 C++ 的问题。

核心原则总结：

问题 原因 解决方法
跨模块循环引用 “向上”持有 shared_ptr 不传递 shared_ptr 给未知代码
回调闭包中持有 shared_ptr 闭包生命周期延长了对象生命周期 用 weak_ptr 代替
底层模块存储上层对象的 shared_ptr 破坏模块层级，形成循环 只存储 weak_ptr 或回调接口

深入讨论了 跨模块（Inter-module）和模块内部（Intra-module）对象生命周期管理与循环引用的差异，重点是：

1. 模块内部（Intra-module）循环：可以安全、自然地使用

场景：

  • 比如一个环形链表 CircularList 或 图（Graph）结构
  • 循环是静态的（固定结构），而不是运行时交叉模块形成的引用循环

可接受的原因：

  • 在模块内部，开发者可以完全控制构造、销毁、访问规则。
  • 可以利用 unique_ptr 来表达对象所有权，构造时声明生命周期（declare lifetime by construction）

示例：静态环形链表

class CircularList {
    class Node {
        std::unique_ptr<Node> next;
        std::unique_ptr<Node>& head;  // 引用外部 head
    public:
        auto get_next() { return next ? next.get() : head.get(); }
    };
    std::unique_ptr<Node> head;
};
特点：
  • 所有权清晰：head 和 next 都是 unique_ptr。
  • 没有原始指针拥有权，构造函数就能确定生命周期。
  • 除了 next() 部分需要手动处理连接（静态循环），其余部分是自动安全的。
    优点总结：
  • Correct（正确）：不用看函数体就知道对象何时析构
  • Efficient（高效）：与手写 new/delete 无差别的性能
  • Robust（健壮）：只要你没有“主动做错”（例如滥用裸指针），就不会泄漏

2. 跨模块（Inter-module）循环：危险，应避免

场景：

  • 不同库（模块）之间各自拥有自己的堆对象
  • 如果互相传递 shared_ptr 并存储对方对象，就形成异质循环（heterogeneous cycle）

错误示范：

// 库 A 传 shared_ptr 给库 B 的回调，库 B 存储并形成循环
void bad(const shared_ptr<X>& x) {
    obj.on_draw([=] { x->extra_work(); });  // 回调中持有 shared_ptr
}
  • 回调生命周期不明确，可能导致对象 x 无法析构 → 内存泄漏
  • 相当于模块 A “向下传”了一个 shared_ptr，被模块 B “向上持有”了

正确做法：使用 weak_ptr

void good(const shared_ptr<X>& x) {
    obj.on_draw([w = weak_ptr<X>(x)] {
        if (auto p = w.lock()) p->extra_work();
    });
}

3. 复杂对象结构：如图（Graph）结构，如何建模生命周期？

示例：带有父子关系的图

class Graph {
    struct Node {
        vector<Node*> children;
        vector<Node*> parents;
        // ...
    };
    vector<Node*> roots;
    vector<unique_ptr<Node>> nodes;
};

分析：

  • nodes 是 unique_ptr 所拥有的 → 释放 Graph 时自动释放所有节点
  • 生命周期是由构造声明的（部分）
  • 但：你仍需要手动识别不可达节点（unreachable nodes）并调用 erase()
    • 类似于手动调用 delete
所以：

这不是完全自动内存管理，而是“部分声明 + 手动垃圾回收”。

总结：所有权模型的适用性（从最安全到最危险）

场景 推荐做法 是否自动内存管理 是否安全
局部作用域 / 成员字段 unique_ptr / 值语义 是 高
模块内部的静态结构（如环形链表） unique_ptr，构造声明生命周期 是 高
复杂图结构，可能有不可达节点 unique_ptr + 手动清理 部分 要小心
跨模块所有权（shared_ptr 传递） 避免，使用 weak_ptr 中继 依赖开发者 易出错

C++ 内存管理演讲中关于**有可能形成环的图结构（possibly-cyclic graph）**的所有权建模。以下是你的内容及其深入解释：

Q: What’s the natural ownership abstraction for a possibly-cyclic graph of nodes?

A: Partial.

在今天的可移植 C++ 中，图结构中没有“完美自动化”的内存管理方案，我们能做的只是“部分声明所有权”。

使用 vector<unique_ptr<Node>> nodes 的方式：

class Graph {
    struct Node {
        vector<Node*> children;
        vector<Node*> parents;
        // ... 数据
    };
    vector<Node*> roots;
    vector<unique_ptr<Node>> nodes;  // 每个 Node 的所有权由 Graph 管理
};
优点（Pros）：
  • Graph 对象拥有所有节点 → 销毁 Graph 时节点全部自动销毁（终点内存泄漏不会发生）
  • 所有权关系明确 —— unique_ptr 显示声明了管理权
缺点（Cons）：
  • children 和 parents 是裸指针 → 容易指向已被释放的节点（悬挂指针）
  • 无法自动识别“不可达节点”（unreachable node） → 必须手动清理！

Challenge: 手动实现 Graph::remove_unused_nodes()

思路：

我们要做的是：

  1. 获取所有 nodes 中的 Node 指针（orphans）
  2. 遍历整个图（从 roots 开始），找出实际可达的 Node
  3. 从 orphans 中移除这些可达节点，剩下的就是“垃圾”
  4. 最后在 nodes 中删除这些“垃圾”节点（就像调用 delete）

示例代码解析：

void Graph::remove_unused_nodes() {
    // 第一步：初始化 orphans 列表（复制所有节点的原始指针）
    vector<const Node*> orphans(nodes.size());
    transform(nodes.begin(), nodes.end(), orphans.begin(),
              [](const auto& x) { return x.get(); });
    // 第二步：排序，方便之后用 lower_bound 查找
    sort(orphans.begin(), orphans.end());
    // 第三步：遍历图，从 roots 出发，找到实际使用到的节点
    for (const auto& node : all_nodes())  // 假设有 DFS/BFS 函数
        orphans.erase(lower_bound(orphans.begin(), orphans.end(), node.get()));
    // 第四步：删除无法访问的 orphan 节点
    for (const auto o : orphans)
        nodes.erase(find_if(nodes.begin(), nodes.end(),
            [o](const auto& x) { return x.get() == o; }));
}

缺点总结（Cons）：

缺点 解释
等价于手动调用 delete 虽然 unique_ptr 被用了，但清理工作仍然是“显式”的
需要写模板样板代码 每次都需要写类似的 erase、transform、lower_bound 等
图遍历开销大 为了清理你不得不遍历整个图结构（这在大图中代价高）

总结：图结构所有权建模的现状

情况 所有权建模 是否自动管理 是否易于使用
节点之间不会循环引用 unique_ptr + 指针 （基本自动）
节点之间存在循环引用 unique_ptr + 手动清理 （部分） 要小心
使用 shared_ptr 创建双向边 容易产生循环 （危险） 不推荐
想完全自动化地收集垃圾节点 需要 GC 或第三方库支持

推荐实践

  • unique_ptr 是声明性、安全的首选，但仍需手动清理逻辑
  • 图遍历、识别不可达节点属于**“逻辑回收”，不是 C++ 默认行为**
  • 不推荐用 shared_ptr + shared_ptr 互持（会泄漏），必要时使用 weak_ptr

核心主题总结：

Happiness is… scopes + unique_ptrs + shared_ptrs (and not too many cycles)

这是一种鼓励使用作用域绑定的所有权模型来确保资源泄漏最小化、易于管理、自动释放的现代 C++ 编程哲学。

关键理解点：

所有权循环（Ownership Cycles）是问题根源：

  • shared_ptr 使用引用计数管理生命周期
  • 引用计数的致命弱点：无法识别循环 → 内存泄漏
  • weak_ptr 是打破引用循环的工具，但：
    • 不是所有循环都能自然地被打破（例如多个模块之间交错依赖）
    • 编程复杂度增加

shared_ptr 的其他隐患：

问题 描述
拷贝代价不固定 shared_ptr 的赋值操作可能涉及原子操作，拷贝成本可能不可预测，影响实时系统
析构时可能嵌套 析构过程是递归的，如果对象树很深，会爆栈（尤其在受限环境中）
可传递所有权 一个对象可以间接拥有另一个对象，导致析构链变深

图结构的所有权建模再次强调：

Q: “What’s the natural ownership abstraction for a possibly-cyclic graph of nodes?”

A: Partial — using unique_ptr + manual GC (sweep)

class Graph {
    struct Node {
        vector<Node*> children;
        vector<Node*> parents;
    };
    vector<Node*> roots;
    vector<unique_ptr<Node>> nodes;
};

unique_ptr 防止内存泄漏（Graph 销毁时 nodes 被销毁）

“无法访问但仍保留的节点”需要你自己写 remove_unused_nodes()

提出的改进建议（探索中）

为了不每次都手动写“清理逻辑”，他提出一些思路：

技巧：加“年龄标记”（Age Counter）

  • 给每个 Node 添加一个 int age
  • 每次 traversal 时设置成当前 age
  • remove_unused_nodes() 时，删除 age < current_age 的节点
int current_age = ++global_age;
dfs_mark_from_roots(current_age);
for (auto& node : nodes)
    if (node->age < current_age)
        // prune node

单次遍历即可清理不可达节点
仍然是手动内存管理逻辑

提出的问题：

“Can we automate any part of this lifetime as a reusable library,

like we automated new/delete with unique_ptr and RC with shared_ptr?”

unique_ptr → 自动释放堆资源

shared_ptr → 自动引用计数

对“有环结构”的垃圾回收 → 仍是手工的（没标准库支持 GC）

生命周期回收策略比较（析构释放树状结构）：

策略 时间复杂度 栈空间 堆空间 特点
默认（递归销毁） O(N) 递归爆栈风险 无 简单
迭代、就地销毁 O(N log N) 无 遍历+释放
迭代、拷贝对象后销毁 O(N) O(N) 先收集再释放
迭代、延迟销毁 O(N) O(N) 推迟释放时间

Herb 最后的警告：

WARNING — EXPERIMENT IN PROGRESS

意思是：这些“自动垃圾收集”的思路还在探索阶段，目前C++ 标准库还没提供专门工具处理环形结构下的自动内存管理。

总结

最佳实践 原因
使用 unique_ptr 表示所有权 明确、作用域绑定、自动销毁
用 weak_ptr 打破共享所有权的循环 避免 shared_ptr 泄漏
图结构中仍需手动处理不可达节点 当前 C++ 无 GC 支持
shared_ptr 滥用可能导致栈爆、拷贝开销不可控 小心使用
不推荐用裸 new/delete 或手动 delete 容易泄漏、不安全

实验性垃圾回收库 —— gcpp，其核心理念是：

deferred_heap / deferred_ptr：实验性的“自动管理生命周期”机制

1. 传统智能指针总结：

模型 对象数 拥有者数 类型
单对象，单拥有者 1 object / 1 owner unique_ptr<T>
单对象，多拥有者 1 object / N owners shared_ptr<T>

这两者都适用于：“对象的生命周期可以在局部范围决定” 的情形。

问题出现在：

图 / 网络 / 模块组合结构中：

  • 拥有权不再清晰
  • 循环引用不可避免
  • 生命周期是**“一个整体”（群体 reachability）**的属性

2. 新提案：deferred_ptr<T> + deferred_heap

Herb 的实验库 gcpp 提出了一个模型：

deferred_heap：

  • 类似一个小型的“局部垃圾收集器”
  • 管理一组相互引用的对象
  • 自动销毁**“不可达对象”**
  • 释放内存时：不嵌套递归析构，而是迭代式、一批处理

特性：

功能 说明
make<T>() 在 heap 上创建一个对象，返回 deferred_ptr<T>（像 shared_ptr）
.collect() 启动 GC，追踪 root 可达对象，析构不可达的
~deferred_heap() 释放 heap 中所有资源，保证无泄漏
析构器自动管理 析构中，其他 deferred 对象指针会自动置为 nullptr（避免悬空引用）

使用模型：局部隔离的 heap 群

Library A          Library B           Library C
   ↓                 ↓                  ↓
deferred_heap_A   deferred_heap_B    deferred_heap_C
  • 每个模块使用自己的 heap（模块级资源隔离）
  • 不允许 heap 之间有引用循环（只能在内部形成循环）
  • 可组合、可裁剪，适用于大系统中模块清晰解耦

目的：

实现类似 GC 的行为，但 不引入完整的垃圾收集器模型，而是通过：

  • 明确区域（heap）控制范围
  • 明确 .collect() 的触发时机
  • 显式调用 + 安全解构 + 可预测性
  • 自动清理不可达对象

但目前是实验性的：

“Not production-quality (but feedback welcome)”

  • gcpp 是一个 demo 级别项目：
    • 用于演示 如何自动处理复杂所有权结构
    • 不打算替代 unique_ptr / shared_ptr，而是作为 fallback

本质思想总结：

对象数量/复杂度 建议使用的智能指针
简单、线性、树状结构 unique_ptr
局部共享、弱共享、少量循环 shared_ptr + weak_ptr
图状、模块组合、复杂有环结构 deferred_ptr in deferred_heap

小结

优点 缺点
自动管理复杂图结构 实验性质，不适合生产环境
不再需要手动写 remove_unused_nodes() 必须小心管理 heap 生命周期
低开销的区域回收机制（非全局 GC） 跨 heap 循环仍需避免
安全析构：析构时指向其他对象的指针为 nullptr 接口/语义仍在发展中

如果你想动手实践：

项目地址： github.com/hsutter/gcpp

一个面向未来 C++ 生命周期管理的新思路，核心是：

Q: What’s the natural ownership abstraction for a possibly-cyclic graph?

A (experimental): deferred_ptr<T> in a deferred_heap

背景问题

传统的智能指针无法很好地管理可能形成环的对象图：

问题 shared_ptr / unique_ptr
引用环 shared_ptr 泄漏
手动清理不可达节点 繁琐、易错（remove_unused_nodes()）
析构时栈爆炸风险 树状析构可能嵌套太深

新实验模型：deferred_ptr + deferred_heap

class Graph {
    deferred_heap my_heap;
    struct Node {
        deferred_ptr<Node> left, right, up;
        /* …data… */
    };
    vector<deferred_ptr<Node>> roots;
    void remove_unused_nodes() {
        my_heap.collect();  // 自动清理不可达节点
    }
};
特点总结：
特性 描述
自动清理不可达对象 .collect() 自动遍历清理不再可达的对象
支持环状结构 引用关系任意组合（包括 parent 指针）
非递归析构，避免栈溢出 延迟析构、可迭代地执行
安全析构 在析构期间，其他 deferred_ptrs 会变为 nullptr
无泄漏保证 如果生命周期由 heap 管理，则确定无泄漏

支持 N 叉图的形式

还考虑到了更通用的情况：

class Graph {
    static deferred_heap my_heap;
    struct Node {
        deferred_vector<deferred_ptr<Node>> children{my_heap};
        deferred_vector<deferred_ptr<Node>> parents{my_heap};
        /* …data… */
    };
    vector<deferred_ptr<Node>> roots;
};
技术细节：
组件 描述
deferred_vector<T> 是 std::vector<T, deferred_allocator<T>> 的别名，用于让 vector 中的内容也属于 deferred_heap
所有节点和其成员 都在 my_heap 上分配、托管
collect() 追踪 roots 可达对象，其它会被析构

注意事项：

  • deferred_heap 不允许跨 heap引用循环（每个 heap 是封闭的引用宇宙）
  • 是实验性质（尚未进入 C++ 标准库）
  • 适用于模块化场景 / 局部复杂结构

用例建议：

用例 建议方案
树结构、单向关系 unique_ptr<T>
少量共享、无环 shared_ptr<T> + weak_ptr<T>
环状图、局部内存域 deferred_heap + deferred_ptr<T>

结语

“Declares lifetime by construction.”

意思是：只要构建图时用 deferred_ptr + deferred_heap，就能在静态结构中声明生命周期约束，无需到运行时追踪 delete / free 或写遍历器来清理不可达对象。
如你希望，我可以提供：

  • 一个完整的基于 gcpp 的图构建示例（有环结构 + 自动回收）
  • 一个替代实现（如果不使用 gcpp，用 unique_ptr 手动模拟）

对不同所有权/生命周期策略做的深度比较与建议。我们可以将这一系列内容总结为一个分层所有权/生命周期模型，非常实用于构建安全、可控、无泄漏的 C++ 程序：

目标：确保对象在不再需要时被销毁

策略选择层级（推荐顺序）

# 策略 典型场景 成本 推荐频率
1 作用域内生命周期（scoped lifetime） 本地变量、类成员 零成本 ~80% 对象
2 unique_ptr<T> / 容器托管 无共享、无环的堆对象，如树 等价于 new/delete，简单堆管理 ~20% 对象
3 shared_ptr<T> + make_shared DAG、有共享但无环的图结构 手动引用计数的成本 DAG/缓存场景
4 deferred_ptr<T> + deferred_heap 有环结构、实时要求、嵌套析构不可控 高开销（延迟+追踪） 少数场景，用于复杂生命周期管理

deferred_ptr 的两个高级组合案例

案例 A：RC 根对象托管 deferred 图

“A graph of deferred objects rooted in a reference-counted (shared_ptr) object.”

  • 整体生命周期由 RC 控制（引用计数控制整张图的生命周期）
  • 图内对象可以自由形成环
  • 析构是有序的
  • 场景：shared_ptr<Graph> + 图内的 deferred_ptr<Node>
    自动释放整个图，同时避免爆栈析构

案例 B：deferred 根对象包含 RC 对象

“A graph of RC objects rooted in a deferred_ptr object.”

  • 整体生命周期是 lazy（只在 collect() 时析构）
  • 内部的 RC 对象仍然有析构顺序
  • 适合树结构，惰性生命周期
  • 场景：一个 deferred 对象拥有多个 shared_ptr<T> 成员，析构集中发生（但彼此间有序）

shared_ptr 的挑战

Herb Sutter 点出 shared_ptr 存在的多个问题，尤其在复杂结构中：

问题 原因
循环引用泄漏 shared_ptr 无法发现循环，需要人工 weak_ptr
赋值代价不确定 RC 增减需要原子操作，有时不能满足实时需求
析构栈爆炸 深层嵌套对象会递归析构，可能溢出栈
异常处理路径代价高 析构顺序嵌套、执行复杂，难控制

deferred_ptr 的价值主张（关键词）

  • deferred destruction（延迟析构）：避免立即析构带来的不确定时机与栈深风险
  • unordered destruction（无序析构）：允许安全地按任意顺序销毁，不出错、不“复活”对象
~deferred_heap()
{
    // 递归地、非嵌套地执行所有析构
    // 确保 deferred_ptr 都变成 nullptr
    // 类似 region-based destruction
}

小结：选择 deferred_ptr 的典型场景

是否适合 deferred_ptr？ 条件
是 数据结构可能有循环引用，如图
是 需要惰性销毁（延迟到某个时机一起）
是 嵌套结构太深，不适合递归析构
否 简单的树/列表结构，或无生命周期嵌套需求
否 仅需要共享引用，且不会形成环的 DAG 结构

实战建议：

Herb 的总结明确指出：

Prefer unique_ptr or shared_ptr in that order where possible.

Use deferred_ptr only when really needed, not as a default.

网站公告

今日签到

点亮在社区的每一天
去签到

热门文章

最新发布