How do I get .NET to garbage collect aggressively?

后端 未结 12 789
情书的邮戳
情书的邮戳 2020-12-02 14:33

I have an application that is used in image processing, and I find myself typically allocating arrays in the 4000x4000 ushort size, as well as the occasional float and the l

12条回答
  •  孤城傲影
    2020-12-02 14:57

    Start by narrowing down where the problem lies. If you have a native memory leak, poking the GC is not going to do anything for you.

    Run up perfmon and look at the .NET heap size and Private Bytes counters. If the heap size remains fairly constant but private bytes is growing then you've got a native code issue and you'll need to break out the C++ tools to debug it.

    Assuming the problem is with the .NET heap you should run a profiler against the code like Redgate's Ant profiler or JetBrain's DotTrace. This will tell you which objects are taking up the space and not being collected quickly. You can also use WinDbg with SOS for this but it's a fiddly interface (powerful though).

    Once you've found the offending items it should be more obvious how to deal with them. Some of the sort of things that cause problems are static fields referencing objects, event handlers not being unregistered, objects living long enough to get into Gen2 but then dying shortly after, etc etc. Without a profile of the memory heap you won't be able to pinpoint the answer.

    Whatever you do though, "liberally sprinkling" GC.Collect calls is almost always the wrong way to try and solve the problem.

    There is an outside chance that switching to the server version of the GC would improve things (just a property in the config file) - the default workstation version is geared towards keeping a UI responsive so will effectively give up with large, long running colections.

提交回复
热议问题