C++内存管理基础中unique_ptr与shared

unique_ptr独占资源所有权，无引用计数，性能高；shared_ptr共享所有权，通过引用计数管理生命周期，但有性能开销和循环引用风险。

c++内存管理基础中unique_ptr与shared_ptr区别

C++内存管理中，

unique_ptr

登录后复制

和

shared_ptr

登录后复制

的核心区别在于它们对资源所有权的管理策略：

unique_ptr

登录后复制

强制独占所有权，即同一时间只有一个指针能管理特定资源；而

shared_ptr

登录后复制

则实现共享所有权，允许多个指针共同管理同一资源，直到所有引用都失效才释放。这种所有权模型的不同，决定了它们各自的适用场景和内存管理开销。

当我们在C++中谈论内存管理，尤其是在现代C++的语境下，智能指针是绕不开的话题。它们被设计出来，就是为了解决传统裸指针带来的内存泄漏、悬空指针等一系列头疼问题，将资源管理自动化。但

unique_ptr

登录后复制

和

shared_ptr

登录后复制

虽然都属于智能指针家族，它们在设计哲学和实际应用中却有着根本性的差异。

unique_ptr

登录后复制

，顾名思义，强调的是“唯一”性。它就像你买了一件限量版的艺术品，只有你拥有它。你可以把它转赠给别人（通过移动语义），但一旦转赠，你就不能再声称拥有了。这意味着

unique_ptr

登录后复制

所指向的资源，在任何时刻都只由一个

unique_ptr

登录后复制

实例来管理。当这个

unique_ptr

登录后复制

的生命周期结束时，它所管理的资源就会被自动释放。这种独占性带来了极低的运行时开销，因为它不需要维护引用计数，性能几乎可以与裸指针媲美。然而，它的代价是不能被复制，只能被移动，这严格限制了资源所有权的传递方式。

shared_ptr

登录后复制

则完全是另一种思路，它强调“共享”。你可以把它想象成你和几个朋友合伙买了一辆车，你们都可以使用，但只有当所有合伙人都放弃了对这辆车的使用权（即所有

shared_ptr

登录后复制

实例都被销毁或重新赋值）时，这辆车才会被处理掉。

shared_ptr

登录后复制

通过内部的引用计数（reference count）机制来追踪有多少个

shared_ptr

登录后复制

实例正在指向同一个资源。每当一个新的

shared_ptr

登录后复制

被创建并指向该资源，引用计数就增加；每当一个

shared_ptr

登录后复制

被销毁或重新赋值，引用计数就减少。只有当引用计数降为零时，资源才会被真正释放。这种机制在处理多方共享资源时非常方便，但它也带来了额外的开销，主要是引用计数需要原子操作来保证多线程安全，以及可能引发循环引用问题。

立即学习“C++免费学习笔记（深入）”；

为什么

unique_ptr

登录后复制

比

shared_ptr

登录后复制

更“轻量”？（以及何时优先选择它）

“轻量”这个词，在

unique_ptr

登录后复制

这里，不仅仅是一种感觉，更是实实在在的性能优势。

unique_ptr

登录后复制

在设计上，几乎没有额外的运行时开销。它内部通常只存储一个裸指针，不涉及引用计数的增减操作，更没有原子操作带来的性能负担。这意味着，当你需要一个资源具有明确的独占所有权，并且这个资源不会被多个地方共享时，

unique_ptr

登录后复制

是你的不二之选。

比如，一个函数内部创建的对象，或者一个类成员变量，它只由该类实例拥有和管理，那么

unique_ptr

登录后复制

就是最合适的。我个人觉得，很多时候，我们其实并不需要共享所有权，只是懒得手动管理内存。在这种情况下，

unique_ptr

登录后复制

就是那个“刚好够用”的工具，它提供了内存安全，同时保持了接近裸指针的性能。当你发现你的设计中，一个对象的所有权是明确且单一的，不要犹豫，

unique_ptr

登录后复制

往往是更好的选择。它甚至可以作为工厂函数的返回类型，明确地将新创建对象的所有权转移给调用者，这在API设计中非常有用。

// 示例：unique_ptr作为函数返回值，转移所有权
std::unique_ptr<MyObject> createObject() {
    // MyObject的创建和管理完全由unique_ptr负责
    return std::make_unique<MyObject>(); 
}

// 示例：类成员变量，独占资源
class ResourceManager {
private:
    std::unique_ptr<Resource> _resource; // 资源由ResourceManager独占
public:
    ResourceManager() : _resource(std::make_unique<Resource>()) {
        // ...
    }
    // ...
};

登录后复制

这种独占性让代码意图更加清晰，也避免了不必要的开销。

shared_ptr

登录后复制

如何解决资源共享的复杂性？它又带来了哪些“甜蜜的负担”？

shared_ptr

登录后复制

的出现，确实解决了C++中一个长期存在的痛点：多个对象需要共同管理同一块内存，并且需要在最后一个使用者释放时才真正销毁。这在很多设计模式中都非常有用，比如观察者模式、缓存管理、或者一些图形渲染场景，多个渲染组件可能需要访问同一个纹理或模型数据。它的“甜蜜”之处在于，你不需要关心谁是最后一个使用者，

shared_ptr

登录后复制

的引用计数机制会自动帮你处理。你可以随意拷贝

shared_ptr

登录后复制

，将其作为函数参数传递，或者存储在容器中，而不用担心资源被提前释放。这种便利性极大地简化了复杂对象图的内存管理。

Trae国内版

国内首款AI原生IDE，专为中国开发者打造

815

查看详情

然而，这种“甜蜜”并非没有代价。首先是性能开销，引用计数的增减通常需要原子操作来保证多线程环境下的正确性，这比简单的指针赋值要慢。其次，也是更隐蔽且棘手的问题：循环引用（circular dependency）。如果对象A持有一个指向B的

shared_ptr

登录后复制

，同时对象B又持有一个指向A的

shared_ptr

登录后复制

，那么即使外部没有其他

shared_ptr

登录后复制

指向A或B，它们的引用计数也永远不会降为零，导致内存泄漏。这就像两个人都在等待对方先放手，结果谁也放不了手，资源就永远得不到释放。

// 示例：循环引用问题
class B; // 前向声明

class A {
public:
    std::shared_ptr<B> b_ptr;
    ~A() { std::cout << "A destroyed" << std::endl; }
};

class B {
public:
    // 如果这里是shared_ptr，就会形成循环引用
    std::shared_ptr<A> a_ptr; 
    ~B() { std::cout << "B destroyed" << std::endl; }
};

void demonstrateCircularReference() {
    auto a = std::make_shared<A>();
    auto b = std::make_shared<B>();
    a->b_ptr = b; // b的引用计数变为2 (a->b_ptr和b)
    b->a_ptr = a; // a的引用计数变为2 (b->a_ptr和a)
    // 当a和b离开作用域时，它们的引用计数会减到1，但不会到0，导致内存泄漏
}

登录后复制

解决循环引用通常需要引入

weak_ptr

登录后复制

。

weak_ptr

登录后复制

是一种不增加引用计数的智能指针，它允许你观察一个

shared_ptr

登录后复制

所管理的对象，但不会影响其生命周期。当你需要访问对象时，可以尝试将其转换为

shared_ptr

登录后复制

（通过

lock()

登录后复制

方法），如果对象已被销毁，

lock()

登录后复制

会返回一个空的

shared_ptr

登录后复制

。

// 解决循环引用：使用weak_ptr
class B_Fixed;

class A_Fixed {
public:
    std::shared_ptr<B_Fixed> b_ptr;
    ~A_Fixed() { std::cout << "A_Fixed destroyed" << std::endl; }
};

class B_Fixed {
public:
    std::weak_ptr<A_Fixed> a_ptr; // 使用weak_ptr打破循环
    ~B_Fixed() { std::cout << "B_Fixed destroyed" << std::endl; }
};

void demonstrateFixedCircularReference() {
    auto a = std::make_shared<A_Fixed>();
    auto b = std::make_shared<B_Fixed>();
    a->b_ptr = b; // b的引用计数为1
    b->a_ptr = a; // a的引用计数为1 (weak_ptr不增加计数)
    // 当a和b离开作用域时，引用计数会正确降到0，资源会被释放
}

登录后复制

weak_ptr

登录后复制

在处理那些“可能存在，也可能不存在”的引用关系时非常有用，它提供了一种安全的访问机制，避免了悬空指针。

什么时候

std::make_unique

登录后复制

和

std::make_shared

登录后复制

是更好的实践？它们又避免了什么潜在陷阱？

在现代C++编程中，直接使用

new

登录后复制

来创建对象并将其传递给智能指针的构造函数，通常被认为是不太好的实践。而

std::make_unique

登录后复制

和

std::make_shared

登录后复制

正是为了解决这个问题而存在的，它们不仅提供了一种更简洁、更安全的方式来创建智能指针，还避免了某些潜在的资源泄漏。

最主要的陷阱在于异常安全性。考虑这样一个函数调用：

foo(std::shared_ptr<T>(new T()), functionThatMightThrow());

登录后复制

这里涉及到三个操作：

new T()

登录后复制

（分配内存并构造对象），

std::shared_ptr<T>

登录后复制

的构造（接管裸指针），以及

functionThatMightThrow()

登录后复制

（一个可能抛出异常的函数）。C++标准不保证这三个操作的执行顺序。如果

new T()

登录后复制

执行了，但

functionThatMightThrow()

登录后复制

在

std::shared_ptr<T>

登录后复制

构造完成之前抛出了异常，那么

new T()

登录后复制

分配的内存将永远无法被

shared_ptr

登录后复制

接管，从而导致内存泄漏。

而

std::make_shared<T>()

登录后复制

和

std::make_unique<T>()

登录后复制

则能避免这种中间状态。它们会一次性地分配内存，对于

make_shared

登录后复制

，这包括对象本身和智能指针所需的控制块；对于

make_unique

登录后复制

，则仅仅是对象本身。这样，要么整个操作成功，要么整个操作失败并回滚，不会出现资源分配了但智能指针还没来得及接管的情况。它们将裸指针的创建和智能指针的构造绑定在一起，确保了异常安全。

此外，

std::make_shared

登录后复制

还有一个额外的性能优势：它能够将对象数据和智能指针的控制块（包含引用计数等信息）在堆上进行一次性分配。这相比于先

new T()

登录后复制

再构造

shared_ptr

登录后复制

（后者会再次在堆上分配控制块）减少了一次内存分配的开销，并且由于更好的内存局部性，可能带来更好的缓存性能。

std::make_unique

登录后复制

虽然没有控制块的额外开销，但它同样保证了异常安全性和简洁性。

因此，我的建议是，除非有非常特殊的原因（比如需要自定义删除器或者从已有的裸指针接管），否则总是优先使用

std::make_unique

登录后复制

和

std::make_shared

登录后复制

来创建智能指针。它们是现代C++内存管理中，兼顾安全、性能和代码可读性的最佳实践。

// 避免潜在陷阱的示例
// 不推荐：可能导致内存泄漏
// foo(std::shared_ptr<MyObject>(new MyObject()), potentially_throwing_function());

// 推荐：异常安全且高效
// foo(std::make_shared<MyObject>(), potentially_throwing_function());

// std::make_unique的创建示例
auto myUniqueObj = std::make_unique<MyObject>();
// std::make_unique也可以用于数组
auto myUniqueArray = std::make_unique<MyObject[]>(10);

登录后复制

这些辅助函数不仅让代码更健壮，也更清晰地表达了程序员的意图。它们是C++智能指针生态中不可或缺的一部分。

以上就是C++内存管理基础中unique_ptr与shared_ptr区别的详细内容，更多请关注php中文网其它相关文章！