Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>A very good read is <a href="https://blogs.msdn.microsoft.com/oldnewthing/20100809-00/?p=13203" rel="nofollow noreferrer">Everybody thinks about garbage collection the wrong way</a>. </p> <p>In general, a memory leak, or any resource leak, is whenever the program allocates memory (or any other resource) and then omits to deallocate it when finished with it. In native application memory leak is the most common resource leak and can happen when the resource reference (the pointer to the allocated block) goes out of scope and is destroyed, but allocated resource (the memory block) does not get destroyed. In this case the resource (memory) is leaked because the program has lost the ability to release it, even if it wants to, because it no longer remembers the location of the resource (the address of the block).</p> <p>In managed applications memory leaks are a bit trickier. Since the runtime can track references to resources automatically, it can also understand when a resource (an object) is no longer referenced by any active part of the application (there is no chain of references from a stack frame to that resource on any thread) and thus the runtime can understand when is safe to collect the objects no longer references by the application. So in managed world a a 'leak' would occur when you believe that the applicaiton no longer references an object (and thus it can be collected by the runtime) but in fact, through some chain of references, you <em>do</em> have a reference to it and thus it cannot be collected. </p> <p>I highly recommend Raymond Chen's article linked above, is very very illuminating.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload