最近我阅读了很多关于智能指针在应用程序中存在性能问题的讨论。其中一个经常建议的解决方案是将智能指针作为const&而不是作为副本进行传递，像这样:
void doSomething(std::shared_ptr<T> o) {}
对决
void doSomething(const std::shared_ptr<T> &o) {}
然而，第二个变体实际上不是共享指针的目的吗？ 在这里，我们实际上正在共享共享指针，因此，如果由于某些原因在调用代码中释放指针（考虑可重入性或副作用），那么该const指针将变为无效。这是共享指针实际上应该防止的情况。 我明白const&可以节省时间，因为没有涉及复制并且没有锁定来管理引用计数。 但代价是使代码不太安全，对吧？
const& 传递 shared_ptr 的好处在于不需要增加和减少引用计数。由于这些操作必须是线程安全的，因此可能会很昂贵。shared_ptr，然后将其引用传递到调用栈中。调用栈深处的一个函数从容器中删除了对象，导致所有引用突然指向一个不存在的对象。shared_ptr 而不是引用传递的特定原因的用例。最常见的原因是被调用的函数可能需要延长对象的生命周期。）shared_ptr 对象由非活动对象的容器持有。该非活动对象位于其容器中。将指向容器中的shared_ptr的引用通过引用传递给命令处理程序。通过一系列引用，这个shared_ptr最终到达了意识到这是一个需要激活的非活动对象的代码。该对象被从非活动容器中删除（这会销毁非活动容器的shared_ptr），并添加到活动容器中（这会向“添加”例程传递的shared_ptr添加另一个引用）。
此时，唯一存在的指向对象的shared_ptr可能是在非活动容器中的那个。调用栈中的每个其他函数只是对它的引用。当对象从非活动容器中删除时，对象可以被销毁，所有这些引用都指向一个不再存在的shared_ptr。
解决这个问题大约花了一个月的时间。
shared_ptr，则知道容器可能会被修改，但不知道将进行什么修改，那么您不能传递对该shared_ptr的引用。实际上，如果我们在上一句话中用int替换shared_ptr，则同样适用，并且如果有人问“我注意到通过引用传递int比值更快，我应该盲目地替换所有调用吗？” 不行。 - Steve Jessopshared_ptr，生命周期会很好，因为shared_ptr正在发挥作用”，但实际上并非如此。 - Steve Jessopshared_ptr下传到调用链。传递对所引用对象的引用、该对象的原始指针或可能是可选项的盒子。
但是当您传递shared_ptr时，最好通过const 引用传递，因为复制shared_ptr会产生额外的开销。复制必须更新共享引用计数，并且此更新必须是线程安全的。因此，存在可以（安全地）避免的小小的低效率。
关于
”价格使代码更不安全，对吗？
不对。价格是简单生成的机器代码中的额外间接性，但编译器管理它。因此，只需避免一个微小但完全不必要的开销，编译器就不能为您优化，除非它非常聪明。
正如David Schwarz在他的回答中所示，当您通过引用传递const时，可能会出现别名问题，即您调用的函数依次更改或调用更改原始对象的函数。按照墨菲定律，在最不方便的时间、最大的成本和最离奇的、难以理解的代码中会发生这种情况。但是，这与参数是string还是shared_ptr或其他内容无关。令人欣慰的是，这是非常罕见的问题。但是请记住，同样适用于传递shared_ptr实例。
shared_ptr特有的问题，这一点非常重要！我认为，在所有答案中，它最好地指出了实际问题。 - Cort Ammonshared_ptrдёҺйҖҡиҝҮconstеј•з”Ёдј йҖ’е®ғд№Ӣй—ҙзҡ„еҢәеҲ«гҖӮдҪ зҡ„еӣһзӯ”дёӯжІЎжңүж¶үеҸҠеҲ°иҝҷдёҖзӮ№гҖӮ - David Schwartzshared_ptr需要时间。构造涉及原子递增，而销毁则涉及原子递减，原子更新（无论是递增还是递减）可能会阻止许多编译器优化（内存加载/存储无法迁移操作），并且在硬件级别上涉及CPU缓存一致性协议，以确保整个缓存行由执行修改的核心拥有（独占模式）。std::shared_ptr<T> const&可以用作比仅使用std::shared_ptr<T>更好的性能提升。
std::shared_ptr<T> const&的少数情况应该与T&，T const&，T*等的总使用次数相比较微不足道。
shared_ptr<T> const&是“奇怪的”。以下情况很常见：
shared_ptr<T>：我需要一个shared_ptr的副本T*/T const&/T&/T const&：我需要一个（可能为null的）指向T的句柄shared_ptr<T>&：我可能会重新设置shared_ptrshared_ptr<T> const&？合法用途非常非常罕见。T时，传递shared_ptr<T> const&是一种反模式：您强制用户使用shared_ptr，而他们可以以其他方式分配T！大多数情况下（99.99..%），您不应该关心如何分配T。shared_ptr<T> const&的地方都应该极度谨慎。如果您的方法没有涉及所有权的修改，则不需要通过复制或const引用方式使用shared_ptr，这会污染API并可能增加开销（如果通过复制传递）
干净的方法是根据您的用例通过const引用或引用方式传递基础类型
void doSomething(const T& o) {}
auto s = std::make_shared<T>(...);
// ...
doSomething(*s);
在方法调用期间无法释放底层指针。
shared_ptrдёҺйҖҡиҝҮconstеј•з”Ёдј йҖ’shared_ptrд№Ӣй—ҙзҡ„еҢәеҲ«гҖӮ - David Schwartzconst &传递参数是完全合理的。在这种情况下，可以节省增加引用计数的成本-因为在这些有限情况下您实际上不需要额外的安全性-前提是您了解其影响并确信代码是安全的。const &。然而，我认为，如果这是您的意图，让函数按值接受参数会使事情更清晰。这种清晰度也不会以更慢的操作为代价：因为您始终可以将shared_ptr按值参数移动到其在函数内的最终位置，如果需要，因此您不需要额外的副本。 - Smeeheeyshared_ptr时。实际上，按值移动传递是Herb推荐的方式，所以如果这就是你的意思，那么我之前说它毫无意义是错误的。但是当你有一个调用链，即使只有两个级别，成本也会反过来（复制+复制+移动与ref+ref+copy+move），如果必须选择单一约定，则支持通过引用传递到const。 - Cheers and hth. - Alfshared_ptr的最后使用），那么您可以沿着链移动共享指针，这样就避免了您提到的额外复制。话虽如此，我相信仍然有一些情况适合您的方法。我只是不同意最初的观点，即我的原始评论是“无意义的”。 - Smeeheey
std::shared_ptr上执行操作还是只需要对指向的对象进行操作？如果是后者，那么就使用const T&；doSomething函数不需要关心对象是如何存储的。 - TartanLlamashared_ptr的原因是您有一个使用案例，您希望需要扩展生命周期。 - David Schwartz