0

我不知道为什么我在这里有内存泄漏，非常感谢任何建议。请注意，在进程终止之前，我调用了destroy()，这是一个静态成员函数，它应该删除单例对象。

以下是相关代码和 valgrind 的消息： 

Manager.h:
class Manager {
public:
    // Constructor/destructor
    static Manager * instance();
    static void destroy();
    ~Manager();
        // Bunch of functions that I didn't write here

private:
    Manager();
    static Manager * _singleton; 
        // Bunch of fields that I didn't write here
};

Manager.cpp:
#include "Manager.h"

Manager * Manager::_singleton = NULL;

Manager * Manager::instance() {
    if (_singleton == NULL) {
            _singleton = new Manager();
        }
    return _singleton;
}

void Manager::destroy()
{
    delete _singleton;
    _singleton = NULL;
}

/*
 * Destructor
 */
Manager::~Manager() {
    // Deleting all fields here, memory leak is not from a field anyway
}

这是 valgrind 的报告：

==28688== HEAP SUMMARY:
==28688==     in use at exit: 512 bytes in 1 blocks
==28688==   total heap usage: 12 allocs, 11 frees, 10,376 bytes allocated
==28688== 
==28688== 512 bytes in 1 blocks are definitely lost in loss record 1 of 1
==28688==    at 0x4C27297: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28688==    by 0x4014CE: Manager::Manager() (Manager.cpp:33)
==28688==    by 0x401437: Manager::instance() (Manager.cpp:15)
==28688==    by 0x4064E4: initdevice(char*) (outputdevice.cpp:69)
==28688==    by 0x406141: main (driver.cpp:21)
==28688== 
==28688== LEAK SUMMARY:
==28688==    definitely lost: 512 bytes in 1 blocks
==28688==    indirectly lost: 0 bytes in 0 blocks
==28688==      possibly lost: 0 bytes in 0 blocks
==28688==    still reachable: 0 bytes in 0 blocks
==28688==         suppressed: 0 bytes in 0 blocks

为什么我有这个泄漏？我确实_singleton删除destroy()

正如我所说，我将不胜感激，谢谢！

4

1 回答 1

6

这里有几点需要注意。最明显的是：你什么时候打电话Manager::destroy。第二件事是，valgrind 似乎抱怨的内存是在 的构造函数中分配的 Manager，您没有向我们展示。如果我们可以相信错误信息（并且我发现valgrind在这方面通常是可靠的，尽管它可能会被愚弄），那么就没有指向内存的剩余指针；要么您没有删除对象中的某个字段，要么对象在其构造函数中分配了内存，而该内存未保存在字段中。

最后，最好不要破坏单例。单例习惯用法的全部目的是避免初始化顺序问题（至少在 C++ 中，否则，仅声明对象的静态实例就足够了）。破坏对象引入了可能的破坏顺序问题。如果你不破坏它，valgrind将警告可能的内存泄漏（不是“绝对丢失”）；您可以忽略警告，也可以将其过滤掉。

于 2012-05-15T08:05:36.323 回答