我的经验，内存泄漏只有一个或两个，而不管内部操作的数量表示输入或输出变量的泄漏。检查系统外部接口的会计一致性。

std :: shared_ptr 它自动适合作为外部接口。用户可以在不知道由 DSP 定义的管理细节的情况下与ref计数对象进行交互。

没有太多的东西可以做直觉你的程序发生了什么。

I'm working on my digital signal processing framework. To provide a data exchange interface, I wrap all buffers in a Data class, which has a reference count based GC mechanism(the system is simple enough so I believe ref count can handle this).

It works like this:

1. When a Data instance is constructed, it sets its ref count to zero.
2. When the instance is dispatched to N DSP modules, add N to its ref count.
3. When a DSP module finishes with the instance, it reduces the ref count.
4. When the ref count decreases to zero, it delete this;

However I found out that there is memory leak in my program.

To debug, I added static variables m_alloccount and m_freecount to the Data class to record the time of allocation and freeing. Then I pause the execution at random times, only finding out there is just slight difference between the two numbers.

E.g. in different trials:

Trial         1   2    3      4
m_alloccount  12  924  34413  364427
m_freecount   11  923  34412  364425

But the fact is that the memory usage is still growing. I believe all memory allocation is bound to the Data class. Really can't figure out the reason now.

int Data::m_alloctime=0;
int Data::m_freetime=0;

Data::Data(DataPinOut*parent, int type, int size)
:m_ptr(NULL)
,m_parent(parent)
,m_refcnt(0)
,m_type(type)
,m_size(size)
{
    if(size>0)
        m_ptr=new char[TypeSizeLookup()*size];
    m_alloctime++;
}

Data::~Data()
{
    delete [] (char*)m_ptr;
    m_freetime++;
}

void Data::Delete()
{
    std::lock_guard<std::mutex>*lock=new std::lock_guard<std::mutex>(m_mutex);

    if(m_refcnt>1)
    {
        m_refcnt--;
        delete lock;
    }
    else
    {
        delete lock;
        delete this;
    }
}

In my experience, a memory leak of just one or two regardless of the amount of internal operations indicates a leak of an input or output variable. Check the accounting consistency of the external interface of your system.

std::shared_ptr is nice because being standard, it is automatically suitable as an external interface. The user can interact with ref-counted objects without knowing the management details defined by DSP.

Other than that, there's not much we can do to intuit what's happening in your program.