unique_ptr 零开销的真相与边界

C++ 的"零开销抽象"原则通常被表述为：不使用某项特性时，不应为其付出额外成本；使用某项特性时，不应比手写等价代码更差。这并非指任何用法都零成本，而是强调抽象不应强加非必要的运行时或空间开销。std::unique_ptr 常被称为零开销智能指针，但这一结论依赖于模板参数的具体选择。当删除器为空类型且指针为原生指针时，unique_ptr 与裸指针尺寸相同；一旦删除器携带状态或类型本身非空，实例尺寸便可能膨胀，并进一步影响函数调用 ABI、容器存储效率和二进制接口。

核心问题：unique_ptr<T> 何时与 T* 同尺寸？何时膨胀？膨胀的代价体现在哪些层面？

本文通过实验矩阵分析不同模板参数组合下的布局：

组合	指针类型	删除器类型	预期尺寸
1	`T*`	`std::default_delete<T>`	8 字节
2	`T*`	函数指针 `void()(T)`	16 字节
3	`T*`	无捕获 lambda	8 字节
4	`T*`	捕获一个 `int` 的 lambda	12/16 字节（取决于填充）
5	`T*`	捕获两个 `int` 的 lambda	16 字节
6	`T*`	有状态 functor（含一个 `int`）	12/16 字节
7	自定义指针 `fancy_ptr<T>`	`std::default_delete<T, fancy_ptr<T>>`	根据指针大小
8	`T*`	`std::default_delete<T[]>`（数组特化）	8 字节

测试环境：本文所有编译期断言和布局观察基于 64 位平台，遵循 x86-64 System V ABI（或 AArch64 AAPCS64，文中会注明），使用主流编译器（如 GCC 和 Clang）配合 libstdc++ 或 libc++，优化级别为 -O2。由于智能指针布局属于实现细节，不同标准库版本可能存在差异，下文所有结论均以所述实现为准，并建议读者在自己的目标平台上通过 static_assert 验证。

1. 核心原理：模板参数、EBO 与删除器存储

std::unique_ptr<T, D> 的典型实现通常包含两个成员：受管理的指针 T* 和一个删除器对象 D。为了优化空删除器的空间占用，标准库实现普遍采用压缩技术，如 std::tuple 或自定义 compressed_pair，利用空基类优化（Empty Base Optimization, EBO）或 C++20 的 [[no_unique_address]] 属性，避免为空删除器分配独立存储空间。

EBO 的成立条件：如果删除器类型 D 是一个空类（没有非静态数据成员），且不是 final，并且作为基类时不会与另一个同类型空基类发生地址冲突，那么编译器可以将其作为基类子对象与指针成员重叠存储。在 unique_ptr 中，标准库通常将指针和删除器包装在一个压缩对（compressed pair）中，当删除器为空类时，该压缩对仅占用指针大小，从而 unique_ptr 与裸指针尺寸相同。

默认删除器 std::default_delete<T> 被定义为空类，没有数据成员，因此 unique_ptr<T> 默认构造时尺寸等于 sizeof(T*)。数组特化 std::default_delete<T[]> 同样是空类，不影响尺寸。函数指针删除器则不同：函数指针本身是一个标量对象，占用 8 字节（64 位平台），无法压缩，因此 unique_ptr<T, void(*)(T*)> 的尺寸至少为 16 字节（受对齐限制可能仍为 16，因为指针和函数指针均为 8 字节对齐，总大小 16 正好对齐）。无捕获 lambda 类型是空类，且通常不是 final，因此可以作为空基类被优化，unique_ptr<T, decltype(lambda)> 尺寸回到 8 字节。捕获 lambda 的尺寸等于捕获列表的总大小（可能有填充），因此删除器状态直接增加对象尺寸。

自定义指针类型（如带标签的指针或 fancy pointer）会改变指针成员的大小，若指针类型本身不为 8 字节，则对象尺寸随之变化。例如一个带有额外元数据的 fancy pointer 可能为 16 字节，那么即使删除器为空，unique_ptr 尺寸也为 16 字节。

下图示意三种典型布局（假设 64 位平台）：

裸指针：[ T* ] 8 字节
默认删除器（EBO 压缩）：[ T* | empty base ] 实际只存储指针，大小 8 字节
函数指针删除器：[ T* ][ function pointer ] 大小 16 字节

2. 完整代码：布局探针与 static_assert

以下探针代码可用于在目标平台上验证 unique_ptr 的布局。由于 unique_ptr 不是标准布局类型，不能使用 offsetof 宏来探测内部成员偏移，但我们可以通过 sizeof、alignof 和类型特征来确认布局契约。此外，还展示了如何对自定义的类用成员指针技巧计算成员偏移，以辅助理解 EBO 的效果。

cpp 复制代码

#include <cstddef>
#include <memory>
#include <type_traits>
#include <iostream>
#include <new>

// 成员偏移探测：仅适用于可访问成员的标准布局或自定义类
template<typename T, typename M>
std::size_t offset_of(M T::*member) {
    return reinterpret_cast<std::size_t>(&(reinterpret_cast<T*>(0)->*member));
}

// 自定义有状态删除器
struct StatefulDeleter {
    int state = 0;
    void operator()(int* p) const { delete p; }
};

// 自定义空删除器（非 final 空类）
struct EmptyDeleter {
    void operator()(int* p) const { delete p; }
};

// 无捕获 lambda 删除器类型
auto lambda_deleter = [](int* p) { delete p; };
using LambdaDeleter = decltype(lambda_deleter);

// 捕获一个 int 的 lambda 删除器类型
int captured = 42;
auto capturing_lambda = [captured](int* p) { delete p; };
using CapturingLambdaDeleter = decltype(capturing_lambda);

// 布局契约静态断言
static_assert(sizeof(std::unique_ptr<int>) == sizeof(int*), "unique_ptr<int> must be same size as int*");
static_assert(sizeof(std::unique_ptr<int, EmptyDeleter>) == sizeof(int*), "Empty deleter should be compressed");
static_assert(sizeof(std::unique_ptr<int, LambdaDeleter>) == sizeof(int*), "Captureless lambda deleter should be compressed");
static_assert(sizeof(std::unique_ptr<int, void(*)(int*)>) == 2 * sizeof(int*), "Function pointer deleter doubles size");
static_assert(sizeof(std::unique_ptr<int, StatefulDeleter>) >= sizeof(int*) + sizeof(int), "Stateful deleter adds state");
static_assert(sizeof(std::unique_ptr<int[]>) == sizeof(int*), "Array unique_ptr default deleter should be same size");

// 类型特征检查
static_assert(std::is_nothrow_destructible_v<std::unique_ptr<int>>, "unique_ptr destructor is noexcept");
static_assert(!std::is_trivially_copyable_v<std::unique_ptr<int>>, "unique_ptr is move-only, not trivially copyable");
static_assert(std::is_nothrow_move_constructible_v<std::unique_ptr<int>>, "move constructor should be noexcept");

int main() {
    std::cout << "sizeof(int*): " << sizeof(int*) << '\n';
    std::cout << "sizeof(unique_ptr<int>): " << sizeof(std::unique_ptr<int>) << '\n';
    std::cout << "sizeof(unique_ptr<int, void(*)(int*)>): " << sizeof(std::unique_ptr<int, void(*)(int*)>) << '\n';
    std::cout << "sizeof(unique_ptr<int, StatefulDeleter>): " << sizeof(std::unique_ptr<int, StatefulDeleter>) << '\n';
    std::cout << "sizeof(unique_ptr<int, CapturingLambdaDeleter>): " << sizeof(std::unique_ptr<int, CapturingLambdaDeleter>) << '\n';
    std::cout << "alignof(unique_ptr<int>): " << alignof(std::unique_ptr<int>) << '\n';

    // 演示 offset_of 用于自定义类
    struct Pair { int* ptr; EmptyDeleter deleter; };
    std::cout << "Offset of Pair::deleter: " << offset_of(&Pair::deleter) << '\n';
    return 0;
}

当某个 static_assert 失败时，编译器会输出类似 error: static_assert failed due to requirement 'sizeof(std::unique_ptr<int, void (*)(int *)>) == 2 * sizeof(int *)' "Function pointer deleter doubles size" 的消息。这种布局契约测试可以纳入 CI，防止升级标准库或编译器后隐形改变 ABI。

3. 实测：sizeof、传参与返回的寄存器行为

在 64 位 x86-64 System V ABI 下，sizeof 与 alignof 的典型结果如下表所示（基于常见实现，实际数值需在目标平台验证）：

类型	`sizeof`	`alignof`	与裸指针差值
`int*`	8	8	0
`unique_ptr<int>`	8	8	0
`unique_ptr<int, void()(int)>`	16	8	+8
`unique_ptr<int, EmptyDeleter>`	8	8	0
`unique_ptr<int, LambdaDeleter>`	8	8	0
`unique_ptr<int, CapturingLambdaDeleter>`（捕获一个 int）	16	8	+8
`unique_ptr<int, StatefulDeleter>`（含一个 int）	16	8	+8
`unique_ptr<int[]>`	8	8	0

（注：捕获一个 int 的 lambda 与含一个 int 的 functor 在 64 位下通常因对齐填充到 16 字节，但具体取决于类型成员顺序与填充策略。）

函数调用时，参数传递遵循 ABI 分类。在 x86-64 SysV 中，大于 16 字节的对象通过内存传递，16 字节及以下的对象可能通过寄存器传递。unique_ptr<int>（8 字节）通常通过 RDI 寄存器传递；unique_ptr<int, void(*)(int*)>（16 字节）可能通过两个寄存器（如 RDI 和 RSI）传递，仍为寄存器传递但占用两个寄存器。若删除器状态进一步膨胀（例如捕获一个 32 字节对象的 lambda），则可能被归类为 MEMORY，转为栈传递。这会影响函数调用的代码生成性能，特别是在频繁调用的接口中。

返回值的处理：C++17 保证的拷贝省略（NRVO）和移动语义使返回 unique_ptr 通常非常高效。默认情况下，返回局部 unique_ptr 会直接构造在调用者的返回槽中，不发生移动。使用 [[nodiscard]] 标记工厂函数可以提醒调用者不要丢弃返回值，但不会改变代码生成。我们可以通过编译器生成的汇编确认：对于返回 unique_ptr<int> 的函数，核心路径通常只是一次指针赋值，没有额外开销。

将 unique_ptr 放入 std::vector 时，元素大小直接影响容器内存占用与缓存行利用率。例如，每元素 8 字节与每元素 16 字节的 vector 在相同容量下占用内存不同，扩容时移动/析构成本也不同。由于 unique_ptr 是 move-only 类型，vector 扩容时使用移动构造而非拷贝，其成本为一次指针拷贝和删除器的移动（对于空删除器为零成本，对于有状态删除器则需移动状态）。以下是一个简易吞吐基准测试的框架：

cpp 复制代码

#include <vector>
#include <memory>
#include <chrono>
#include <iostream>

template<typename UP>
void benchmark(const char* name) {
    constexpr size_t N = 1'000'000;
    std::vector<UP> v;
    v.reserve(N);
    auto start = std::chrono::steady_clock::now();
    for (size_t i = 0; i < N; ++i) {
        v.emplace_back(new int(i));
    }
    auto mid = std::chrono::steady_clock::now();
    v.clear();
    auto end = std::chrono::steady_clock::now();
    std::cout << name << " construct: "
              << std::chrono::duration_cast<std::chrono::milliseconds>(mid - start).count()
              << " ms, destruction: "
              << std::chrono::duration_cast<std::chrono::milliseconds>(end - mid).count()
              << " ms\n";
}

int main() {
    benchmark<std::unique_ptr<int>>("unique_ptr<int>");
    benchmark<std::unique_ptr<int, void(*)(int*)>>("unique_ptr<int, funcptr>");
}

注意：此类微基准受缓存、频率缩放、内存分配器影响，应多次运行取中位数，并关闭 CPU 频率调节，避免过度解读微秒级差异。本文不提供具体数值，仅提供方法；读者可在自己的环境中测量相对趋势。

4. 工程边界：跨模块、异常路径与析构语义

跨模块（DSO）边界：unique_ptr 的删除器类型是模板签名的一部分，因此不同删除器的 unique_ptr 是不同类型。跨模块传递 unique_ptr 时，其类型必须完全一致，否则破坏 ABI。模板实例化可能受 -fvisibility 影响，如果删除器类型定义在共享库内部且未导出，外部模块可能无法实例化同类型而链接失败。对于默认删除器，跨模块释放内存时要求分配和释放使用同一个堆（同一 C++ 运行时），否则会出现分配器不匹配错误（例如 Linux 上跨 .so 使用不同堆实现，或 Windows 上跨 CRT）。使用函数指针或自定义删除器可显式指定释放函数，但增加了对象大小。

异常路径：unique_ptr 的析构函数被声明为 noexcept。如果删除器在调用 operator delete 或其他操作时抛出异常，析构函数会调用 std::terminate。因此，自定义删除器应确保不抛出异常；若必须处理异常，应在删除器内部捕获。std::shared_ptr 的析构函数同样是 noexcept，删除器抛出同样导致 std::terminate，但 shared_ptr 的删除器调用发生在控制块销毁时，可能涉及弱引用的交互，需谨慎设计。

不完整类型：unique_ptr<T> 支持 T 为不完整类型（声明时无需完整定义），但析构 unique_ptr<T> 的代码点必须看到 T 的完整定义，否则为未定义行为。这是 PImpl 惯用法的经典陷阱：在头文件中使用 std::unique_ptr<Impl> 声明，并在 .cpp 文件中定义析构函数或使用 = default 于源文件位置，确保完整类型可见。编译期可通过 static_assert(sizeof(T) > 0) 或检查是否完整来提前发现。

与 shared_ptr 的取舍：shared_ptr 引入了控制块分配，引用计数增减使用原子操作，在多线程下有开销，而 unique_ptr 没有这些开销。std::make_shared 可以单次分配对象与控制块，减少分配次数，但对象内存无法在仅剩弱引用时释放；unique_ptr 则完全由调用者控制分配。shared_ptr 支持别名构造，便于管理非拥有指针；跨模块传递 shared_ptr 只要使用相同标准库实现和编译选项，通常比 unique_ptr 更宽容（因为类型可以相同，且控制块机制统一）。但 shared_ptr 并非万能，其原子操作在单线程环境也可能引入同步开销。

线程安全边界：shared_ptr 的引用计数操作是线程安全的，多个线程可以同时复制/销毁不同的 shared_ptr 实例（只要它们引用同一控制块），但被管理的对象本身不受保护。unique_ptr 不提供任何线程安全保证；将一个 unique_ptr 的所有权从一个线程转移到另一个线程需要外部同步（如使用互斥锁或原子操作配合 release/reset），而不能并发访问同一个 unique_ptr 对象。

5. 结论与选型清单

回到标题的问题：unique_ptr 的零开销并非在所有用法下都是免费午餐。当且仅当删除器为空类型（如默认删除器、无捕获 lambda 或自定义空 functor）且指针为原生指针时，unique_ptr 与裸指针同尺寸，实现真正的零空间开销，并在参数传递中与裸指针具有相同的寄存器行为。一旦删除器携带状态（函数指针、捕获 lambda、有状态 functor），对象尺寸便增加，可能影响 ABI 分类、容器内存密度和缓存性能。这是对"额外付费"的显式选择。

选型决策清单：

优先使用默认删除器或无捕获 lambda 删除器（无捕获 lambda 能避免每次实例化新类型导致的代码膨胀，同时保持零尺寸）。
需要运行时多态删除行为时，可考虑 std::function 或函数指针，但应评估尺寸与性能成本；若删除器状态较大，可考虑将状态放在被管理对象内部，保持 unique_ptr 本身小巧。
跨模块接口优先使用裸指针加显式释放函数，或使用 std::shared_ptr 明确所有权契约，避免 unique_ptr 模板实例化导致的 ABI 耦合。
在 PImpl 等场景中，确保析构函数在完整类型可见处定义。
自定义删除器务必 noexcept，避免异常导致 std::terminate。

可复用布局契约测试模板（纳入 CI）：

cpp 复制代码

#include <memory>
#include <type_traits>

// 根据预期调整
static_assert(sizeof(std::unique_ptr<int>) == sizeof(int*), "Default deleter should not add size");
static_assert(sizeof(std::unique_ptr<int, void(*)(int*)>) == 2 * sizeof(int*), "Function pointer deleter adds one pointer");
// 可扩展检查更多组合

未来标准演进：C++20 的 [[no_unique_address]] 已为标准库实现提供更直接的压缩手段，随着其在主要编译器中的支持完善，空删除器压缩将更加普遍。但布局契约仍需通过编译期断言锁定，因为 ABI 稳定性是工程实践的关键。

最终建议：在使用 unique_ptr 时，把"零开销"理解为"默认配置下的零开销"，并对任何非默认删除器配置进行布局验证和成本分析。