线程内存泄漏

Question

I am trying to track down a memory leak in a larger C# program which spawns multiple threads. In the process, I have created a small side program which I am using to test some basic things, and I found some behavior that I really do not understand.

class Program
{
    static void test()
    {
    }

    static void Main(string[] args)
    {
        while (true)
        {              
            Thread test_thread = new Thread(() => test());
            test_thread.Start();
            Thread.Sleep(20);
        }
    }
}

Running this program, I see that the memory usage of the program increases steadily without stopping. In just a few minutes the memory usage goes well over 100MB and keeps climbing. If I comment out the line test_thread.Start();, the memory used by the program maxes out at about a few megabytes, and levels out. I also tried forcing garbage collection at the end of the while loop using GC.Collect(), but it did not seem to do anything.

I thought that the thread would be dereferenced as soon as the function is finished executing allowing the GC to mop it up, but this doesn't seem to be happening. I must not be understanding something deeper here, and I would appreciate some help with fixing this leak. Thanks in advance!

Answer 1

This is by design, your test program is supposed to exhibit runaway memory usage. You can see the underlying reason from Taskmgr.exe. Use View + Select Columns and tick "Handles". Observe how the number of handles for your process is steadily increasing. Memory usage goes up along with that, reflecting the unmanaged memory used by the handle objects.

The design choice was a very courageous one, the CLR uses 5 operating system objects per thread. Plumbing, used for synchronization. These objects are themselves disposable, the design choice was to not make the Thread class implement IDisposable. That would be quite a hardship on .NET programmers, very difficult to make the Dispose() call at the right time. Courage that wasn't exhibited in the Task class design btw, causing lots of hand-wringing and the general advice not to bother .

This is not normally a problem in a well-designed .NET program. Where the GC runs often enough to clean up those OS objects. And Thread objects are creating sparingly, using the ThreadPool for very short running threads like your test program uses.

It can be, we can't see your real program. Do beware of drawing too many conclusions from such a synthetic test. You can see GC statistics with Perfmon.exe, gives you an idea if it is running often enough. A decent .NET memory profiler is the weapon of choice. GC.Collect() is the backup weapon. For example:

static void Main(string[] args) {
    int cnt = 0;
    while (true) {
        Thread test_thread = new Thread(() => test());
        test_thread.Start();
        if (++cnt % 256 == 0) GC.Collect();
        Thread.Sleep(20);
    }
}

And you'll see it bounce back and forth now, never getting much higher than 4 MB.