我看到std::weak_ptr<T>作为std::shared_ptr<T>的句柄:它允许我 获取std::shared_ptr<T>(如果它仍然存在)，但是它不会扩展它的 一生。在以下几种情况下，这种观点是有用的:

// Some sort of image; very expensive to create.
std::shared_ptr< Texture > texture;

// A Widget should be able to quickly get a handle to a Texture. On the
// other hand, I don't want to keep Textures around just because a widget
// may need it.

struct Widget {
    std::weak_ptr< Texture > texture_handle;
    void render() {
        if (auto texture = texture_handle.get(); texture) {
            // do stuff with texture. Warning: `texture`
            // is now extending the lifetime because it
            // is a std::shared_ptr< Texture >.
        } else {
            // gracefully degrade; there's no texture.
        }
    }
};

另一个重要的场景是打破数据结构中的循环。

// Asking for trouble because a node owns the next node, and the next node owns
// the previous node: memory leak; no destructors automatically called.
struct Node {
    std::shared_ptr< Node > next;
    std::shared_ptr< Node > prev;
};

// Asking for trouble because a parent owns its children and children own their
// parents: memory leak; no destructors automatically called.
struct Node {
    std::shared_ptr< Node > parent;
    std::shared_ptr< Node > left_child;
    std::shared_ptr< Node > right_child;
};

// Better: break dependencies using a std::weak_ptr (but not best way to do it;
// see Herb Sutter's talk).
struct Node {
    std::shared_ptr< Node > next;
    std::weak_ptr< Node > prev;
};

// Better: break dependencies using a std::weak_ptr (but not best way to do it;
// see Herb Sutter's talk).
struct Node {
    std::weak_ptr< Node > parent;
    std::shared_ptr< Node > left_child;
    std::shared_ptr< Node > right_child;
};

赫布·萨特有一篇精彩的演讲，解释了语言的最佳使用 特性(在这种情况下是智能指针)，以确保默认情况下的泄漏自由 (意思是:所有的东西都是通过建设来实现的;你很难搞砸它 )。这是必看的节目。

缓存就是一个很好的例子。

对于最近访问的对象，您希望将它们保存在内存中，因此可以保留一个指向它们的强指针。定期扫描缓存，确定最近没有访问哪些对象。你不需要把它们保存在内存中，所以你去掉强指针。

但是，如果该对象正在使用，而其他一些代码持有指向它的强指针，该怎么办?如果缓存删除了指向该对象的唯一指针，就再也找不到它了。因此，缓存保留了一个弱指针，指向它需要找到的对象，如果它们碰巧留在内存中。

这正是弱指针所做的——它允许你在一个对象仍然在附近时定位它，但如果没有其他东西需要它，它就不会保留它。

Here's one example, given to me by @jleahy: Suppose you have a collection of tasks, executed asynchronously, and managed by an std::shared_ptr<Task>. You may want to do something with those tasks periodically, so a timer event may traverse a std::vector<std::weak_ptr<Task>> and give the tasks something to do. However, simultaneously a task may have concurrently decided that it is no longer needed and die. The timer can thus check whether the task is still alive by making a shared pointer from the weak pointer and using that shared pointer, provided it isn't null.

除了其他已经提到的有效用例，std::weak_ptr在多线程环境中是一个很棒的工具，因为

它不拥有对象，因此不能妨碍在不同线程中删除 Std::shared_ptr与Std::weak_ptr结合在一起对悬空指针是安全的——与Std::unique_ptr与原始指针结合在一起相反 std::weak_ptr::lock()是一个原子操作(参见关于weak_ptr的线程安全)

考虑一个任务，将一个目录(~10.000)的所有图像同时加载到内存中(例如作为缩略图缓存)。显然，做到这一点的最佳方法是一个控制线程(处理和管理图像)和多个工作线程(加载图像)。这是一个简单的任务。这里是一个非常简化的实现(join()等被省略了，线程将不得不在一个真正的实现中被不同地处理等)

// a simplified class to hold the thumbnail and data
struct ImageData {
  std::string path;
  std::unique_ptr<YourFavoriteImageLibData> image;
};

// a simplified reader fn
void read( std::vector<std::shared_ptr<ImageData>> imagesToLoad ) {
   for( auto& imageData : imagesToLoad )
     imageData->image = YourFavoriteImageLib::load( imageData->path );
}

// a simplified manager
class Manager {
   std::vector<std::shared_ptr<ImageData>> m_imageDatas;
   std::vector<std::unique_ptr<std::thread>> m_threads;
public:
   void load( const std::string& folderPath ) {
      std::vector<std::string> imagePaths = readFolder( folderPath );
      m_imageDatas = createImageDatas( imagePaths );
      const unsigned numThreads = std::thread::hardware_concurrency();
      std::vector<std::vector<std::shared_ptr<ImageData>>> splitDatas = 
        splitImageDatas( m_imageDatas, numThreads );
      for( auto& dataRangeToLoad : splitDatas )
        m_threads.push_back( std::make_unique<std::thread>(read, dataRangeToLoad) );
   }
};

但是，如果你想中断图像的加载，例如，因为用户选择了一个不同的目录，它会变得复杂得多。或者即使你想毁掉经理。

在更改m_imageDatas字段之前，您需要线程通信并必须停止所有加载器线程。否则，加载器将继续加载，直到所有图像都完成—即使它们已经过时。在简化的示例中，这不会太难，但在实际环境中，事情可能要复杂得多。

The threads would probably be part of a thread pool used by multiple managers, of which some are being stopped, and some aren't etc. The simple parameter imagesToLoad would be a locked queue, into which those managers push their image requests from different control threads with the readers popping the requests - in an arbitrary order - at the other end. And so the communication becomes difficult, slow and error-prone. A very elegant way to avoid any additional communication in such cases is to use std::shared_ptr in conjunction with std::weak_ptr.

// a simplified reader fn
void read( std::vector<std::weak_ptr<ImageData>> imagesToLoad ) {
   for( auto& imageDataWeak : imagesToLoad ) {
     std::shared_ptr<ImageData> imageData = imageDataWeak.lock();
     if( !imageData )
        continue;
     imageData->image = YourFavoriteImageLib::load( imageData->path );
   }
}

// a simplified manager
class Manager {
   std::vector<std::shared_ptr<ImageData>> m_imageDatas;
   std::vector<std::unique_ptr<std::thread>> m_threads;
public:
   void load( const std::string& folderPath ) {
      std::vector<std::string> imagePaths = readFolder( folderPath );
      m_imageDatas = createImageDatas( imagePaths );
      const unsigned numThreads = std::thread::hardware_concurrency();
      std::vector<std::vector<std::weak_ptr<ImageData>>> splitDatas = 
        splitImageDatasToWeak( m_imageDatas, numThreads );
      for( auto& dataRangeToLoad : splitDatas )
        m_threads.push_back( std::make_unique<std::thread>(read, dataRangeToLoad) );
   }
};

此实现几乎与第一个实现一样简单，不需要任何额外的线程通信，并且可以在实际实现中作为线程池/队列的一部分。由于过期的图像被跳过，而未过期的图像被处理，因此在正常操作期间线程永远不必停止。 你总是可以安全地更改路径或销毁你的管理器，因为读取器fn检查，如果拥有的指针没有过期。

受到@offirmo回复的启发，我写了这段代码，然后运行visual studio诊断工具:

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

using namespace std;

struct Member;
struct Team;

struct Member {
    int x = 0;

    Member(int xArg) {
        x = xArg;
    }

    shared_ptr<Team> teamPointer;
};

struct Team {
    vector<shared_ptr<Member>> members;
};

void foo() {
    auto t1 = make_shared<Team>();
    for (int i = 0; i < 1000000; i++) {
        t1->members.push_back(make_shared<Member>(i));
        t1->members.back()->teamPointer = t1;
    }
}

int main() {
    foo();

    while (1);

    return 0;
}

当指向团队的成员指针是shared_ptr teamPointer时，在foo()完成后内存就没有空闲了，即它停留在150mb左右。

但是如果在诊断工具中将其更改为weak_ptr teamPointer，您将看到一个峰值，然后内存使用量恢复到大约2MB。

另一个答案，希望更简单。(对谷歌员工)

假设您有Team和Member对象。

显然，这是一个关系:Team对象将拥有指向其成员的指针。成员也可能有一个指向他们的Team对象的后向指针。

然后你就有了一个依赖循环。如果您使用shared_ptr，当您放弃对对象的引用时，对象将不再被自动释放，因为它们以循环的方式相互引用。这是内存泄漏。

您可以使用weak_ptr来打破这种情况。“所有者”通常使用shared_ptr，而“所有者”使用weak_ptr来访问父节点，并在需要访问父节点时临时将其转换为shared_ptr。

存储一个弱ptr:

weak_ptr<Parent> parentWeakPtr_ = parentSharedPtr; // automatic conversion to weak from shared

然后在需要的时候使用它

shared_ptr<Parent> tempParentSharedPtr = parentWeakPtr_.lock(); // on the stack, from the weak ptr
if( !tempParentSharedPtr ) {
  // yes, it may fail if the parent was freed since we stored weak_ptr
} else {
  // do stuff
}
// tempParentSharedPtr is released when it goes out of scope