Explicitly freeing memory in c#

前端 未结 9 705
刺人心
刺人心 2020-12-01 01:12

I\'ve create a c# application which uses up 150mb of memory (private bytes), mainly due to a big dictionary:

Dictionary Txns = new Diction         


        
相关标签:
9条回答
  • 2020-12-01 01:51

    It's not usually a good idea trying to force the GC. Do you really need to have the whole dictionary in memory?

    0 讨论(0)
  • 2020-12-01 01:59

    Edit:

    To be fair, setting the reference to null does not free the memory, it assigns it's container to a different address, in this case null. According to MSDN, calling Clear(), does this: "The Count property is set to 0, and references to other objects from elements of the collection are also released. The capacity remains unchanged."

    ...

    You should never call the garbage collector. You are using managed objects with no native resources, trust the garbage collector to clean up after you.

    Besides the size of your dictionary, you don't need to worry about memory, memory isn't your problem, it's garbage collectors problem.

    Calling Clear() will remove the references to any contained object inside, but the capacity remains unchanged.

    On a technical note, collecting memory is expensive and a considerable time consuming operating. Reason being, not only does the GC handle heap memory and clean up your heap, it also sort of defrags the heap. It tries to move memory into contiguous blocks to speed up allocation for when some piece of code makes a large request.

    p.s. How big is your dictionary that you use 155MB of memory?

    0 讨论(0)
  • 2020-12-01 02:00

    Windows has two memory availability events. I'd expect the CLR to respond to this. If there's plenty of memory available, the smart thing is to NOT run the garbage collector. So, to make sure that you are indeed observing bad CLR behavior, please repeat this test with another dummy application using a big heap of memory.

    0 讨论(0)
  • 2020-12-01 02:01

    Private bytes reflect the process' memory usage. When objects are collected the associated memory segment may or may not be freed to the OS. The CLR manages memory at the OS level and since allocating and freeing memory isn't free there's no reason to free each piece of memory immediately as chances are that the application will probably request more memory later.

    0 讨论(0)
  • 2020-12-01 02:03

    if u call GC.Collect() it start to do its job , but it returns immediately, it doesnt block, so you dont see its affect, if you just call GC.WaitForPendingFinalizers() after that it will block your app until GC.Collect() finish its job

    0 讨论(0)
  • 2020-12-01 02:04

    Not sure from memory if Dictionary has a Dispose() or not, but it's bound to have a Clear(). Call either of these before setting any references to null.

    Then, simply let the garbage collector do its work. It is almost never a good idea to call GC.Collect() explicitly yourself and it might not even do what you want/need/expect and end up costing you performance. Static Code Analysis (=FxCop) doesn't warn you with Reliability rule CA2001 about this for nothing, you know? Simply do not do this unless you really know what you're doing. And even then don't do it. ;-)

    Are you sure the dictionary is that huge? Isn't it just 10 Mb of memory and the rest is otherwise taken by your application? Question that might help you: Have you used a profiler yet to see where memory is actually consumed...?

    0 讨论(0)
提交回复
热议问题