在 C++ 的内存管理范式中，<memory> 头文件引入的智能指针彻底改变了动态资源的生命周期控制方式。通过 RAII（资源获取即初始化）机制，开发者可以将内存释放的责任委托给栈对象，从而有效规避内存泄漏与悬垂指针等经典问题。其中，std::unique_ptr 与 std::shared_ptr 构成了所有权语义的两大基石。

排他性所有权：std::unique_ptr

std::unique_ptr 实现了严格的独占所有权语义。在任意时刻，仅允许一个 unique_ptr 实例持有底层资源。这种设计摒弃了引用计数的开销，提供了与裸指针几乎等同的运行效率。当该指针离开作用域被销毁，或通过 std::move 显式转移所有权时，底层内存会被自动且确定性地回收。

#include <memory>

struct Position {
    double x;
    double y;
};

// 独占管理一个 Position 对象
auto posPtr = std::make_unique<Position>(Position{10.5, 20.8});

// 所有权转移
auto newPosPtr = std::move(posPtr); 
// 此时 posPtr 变为空，newPosPtr 拥有资源

共享式所有权：std::shared_ptr

与独占模式不同，std::shared_ptr 支持多个指针实例共同持有同一资源。其核心机制是内部维护的引用计数器。每次发生拷贝构造或赋值时，计数值递增；当指针实例销毁时，计数值递减。一旦引用计数归零，系统便会触发资源的析构与释放。尽管这种共享语义极大地简化了复杂对象图的管理，但原子操作维护引用计数会带来不可忽视的性能损耗。

#include <memory>
#include <string>

// 创建共享所有权
auto configPtr1 = std::make_shared<std::string>("default_config");
auto configPtr2 = configPtr1; // 引用计数递增为 2

// 当 configPtr1 和 configPtr2 都离开作用域时，引用计数归零，内存释放

语义选型策略

在实际工程中，默认应优先采用 std::unique_ptr 以追求极致的性能与清晰的 ownership 边界。仅当业务逻辑确实需要多个组件协同管理同一资源生命周期时，才退而求其次选择 std::shared_ptr。然而，共享所有权并非没有代价，其最致命的隐患便是循环引用。

引用计数的陷阱：循环引用

当两个或多个对象通过 std::shared_ptr 相互持有对方时，便会形成闭环。在这种拓扑结构下，即使外部作用域的所有强引用均已销毁，对象内部的相互引用仍会使引用计数保持在 1 以上，导致析构函数永远无法被触发，最终引发严重的内存泄漏。

#include <iostream>
#include <memory>

class Software;

class Hardware {
public:
    std::shared_ptr<Software> sw_link;
    Hardware() { std::cout << "Hardware init\n"; }
    ~Hardware() { std::cout << "Hardware cleanup\n"; }
};

class Software {
public:
    std::shared_ptr<Hardware> hw_link;
    Software() { std::cout << "Software init\n"; }
    ~Software() { std::cout << "Software cleanup\n"; }
};

int main() {
    auto hw = std::make_shared<Hardware>();
    auto sw = std::make_shared<Software>();
    
    // 形成相互引用的闭环
    hw->sw_link = sw;
    sw->hw_link = hw;
    
    return 0; // 内存泄漏，析构函数永远不会被调用
}

破局之道：std::weak_ptr 的观察者模式

为了切断这种致命的引用环，C++ 提供了 std::weak_ptr。作为一种弱引用，它专门用于观察 std::shared_ptr 所管理的资源，且绝不参与强引用计数的累加。在存在双向关联的场景中，只需将其中一端（通常是生命周期较长或从属地位的一端）的指针类型替换为 std::weak_ptr，即可在逻辑上打破闭环。

#include <iostream>
#include <memory>

class Software;

class Hardware {
public:
    std::shared_ptr<Software> sw_link;
    Hardware() { std::cout << "Hardware init\n"; }
    ~Hardware() { std::cout << "Hardware cleanup\n"; }
};

class Software {
public:
    // 降级为弱引用，不增加 Hardware 的强引用计数
    std::weak_ptr<Hardware> hw_observer; 
    Software() { std::cout << "Software init\n"; }
    ~Software() { std::cout << "Software cleanup\n"; }
};

int main() {
    auto hw = std::make_shared<Hardware>();
    auto sw = std::make_shared<Software>();
    
    hw->sw_link = sw;
    sw->hw_observer = hw; // 打破循环引用
    
    return 0; // 程序结束时，Hardware 和 Software 均被正常析构
}

安全访问：通过 lock() 提升为强引用

由于 std::weak_ptr 不拥有资源，直接访问底层对象是极度危险的（可能遭遇资源已被释放的情况）。因此，在访问前必须调用 lock() 方法。该方法会尝试将弱引用"升级"为 std::shared_ptr：若资源依然存活，则返回一个有效的强引用并临时增加引用计数；若资源已被销毁，则返回一个空指针。这种机制确保了并发或异步环境下的内存访问安全。

#include <iostream>
#include <memory>

class Software;

class Hardware {
public:
    std::shared_ptr<Software> sw_link;
    Hardware() { std::cout << "Hardware init\n"; }
    ~Hardware() { std::cout << "Hardware cleanup\n"; }
};

class Software {
public:
    std::weak_ptr<Hardware> hw_observer;
    Software() { std::cout << "Software init\n"; }
    ~Software() { std::cout << "Software cleanup\n"; }
};

int main() {
    auto hw = std::make_shared<Hardware>();
    auto sw = std::make_shared<Software>();
    
    hw->sw_link = sw;
    sw->hw_observer = hw;

    // 尝试将 weak_ptr 提升为 shared_ptr
    if (auto locked_hw = sw->hw_observer.lock()) {
        std::cout << "Hardware is accessible and alive.\n";
    } else {
        std::cout << "Hardware has already been destroyed.\n";
    }

    return 0;
}