错误使用 scoped_lock 导致的内存泄漏？

Posted 2023-02-21

【中文标题】错误使用 scoped_lock 导致的内存泄漏？

【英文标题】：Memory leak caused by a wrong usage of scoped_lock?

【发布时间】：2009-10-08 01:53:02

【问题描述】：

我有一个内存泄漏，我猜它是由错误使用 scoped_lock (Boost) 引起的。但是我没能找到确切的问题，而且我相信代码的编写方式也不完全正确。

代码在这个类中： http://taf.codeplex.com/SourceControl/changeset/view/31767#511225

主要的重要方法是ThreadedLoop()。基本上，此方法在线程中启动，并定期检查要为雅虎下载的市场数据。对于每只股票（或其他），将创建一个新线程（用于 ExecuteNextRequest() 方法），将指向包含股票名称的字符串的指针作为参数传递。这是我唯一做的内存分配，但它在线程执行结束时被释放。

我也会对如何增强此代码感兴趣（当然我可以使用线程池，但这还不是重点）。非常感谢！

【问题讨论】：

滥用锁定原语更有可能导致死锁，而不是内存泄漏

您可以只使用简单的std::string 而不是指向它的指针。我认为指针没有任何用途，但我也不认为这是您的内存泄漏的原因......

@sth：我同意你的评论。但是，如果您可能希望使用可变字符串，并且所有看到它的引用都可以看到更改，那么shared_ptr 仍然有用。 :-)

【参考方案1】：

我建议不要使用指向std::string 的“原始”指针，而是使用boost::shared_ptr<std::string>，然后传递它。完成后，调用它的reset() 函数；它会减少使用计数，当计数为0时自动释放字符串。

作为奖励，您可以将boost::weak_ptr 对象附加到这些字符串（您可以将它们粘贴到vector 中），并监控其中有多少仍然“活动”。通过这种方式，您将知道是否有任何原因导致字符串不递减为 0。

要明确：

if (_tickersQueue.size() > 0)

    boost::shared_ptr<std::string> ticker(new std::string(PopNextTicker()));
    if (!ticker->empty())
        _threads.create_thread(boost::bind(&TAFYahooFinanceParadigm::ExecuteNextRequest, this, ticker));
    else
        ticker.reset();  // optional; ticker will drop out of scope anyway

是的，你必须适当调整ExecuteNextRequest的函数类型。 :-)

【讨论】：

没错，在这里使用原始指针是没用的。但是，内存泄漏与线程的密集创建有关......我实现了一个极简线程池，它工作得更好。