We Keep Coding

garbage collection after a local method in C#

I'm a beginner in C#, just a question on garbage collection in C#. Let's say we have the following code:
...
public void Test()
{
...
MyClass a = new Myclass()
}
so when will a be garbage collected by CLR? I mean immediately garbage collected after Test() method gets executed? or when the program finishes?

Running this code will not let you control or know when the garbage collection will run, there are a number of conditions that will trigger the garbage collection:
Conditions for a garbage collection
The system has low physical memory. This is detected by either the low
memory notification from the OS or low memory indicated by the host.
The memory that is used by allocated objects on the managed heap
surpasses an acceptable threshold. This threshold is continuously
adjusted as the process runs.
The GC.Collect method is called. In almost all cases, you do not have
to call this method, because the garbage collector runs continuously.
This method is primarily used for unique situations and testing.
More information: Conditions for a garbage collection / learn.microsoft.com

Answer from : https://www.codeproject.com/Articles/1095402/Garbage-Collection-and-Csharp
When GC Gets Triggered?
There are no specific timings for GC to get triggered, GC automatically starts operation on the following conditions:
When virtual memory is running out of space.
When allocated memory is suppressed acceptable threshold (when GC found if the survival rate (living objects) is high, then it increases the threshold allocation).
When we call GC.Collect() method explicitly, as GC runs continuously, we actually do not need to call this method.

Unlike in other languages, c# manages itself to clean up most resources for you. As you can read in other answers, resources are freed, when the GC detect's that they are not needed anymore and he has the time to do it. But if you really need to trigger this manually, you can use the GC.Collect() Method.
If you are interested in freeing unmanaged resources (files, connections, unmanaged code, basically everything that is not controlled by the CLR) you should have a look into the dispose-pattern. Usually you would Implement the IDisposable interface. But there are really many handsome approaches to this, to also free unmanaged resources, even if Dispose() doesn't get called by the code. Have a look at this.

Memory Not Release for Array asignment in Mono (C#)

In my C# program i have function that in it, i create array of Byte with length of 1000000 and when the function executed , memory show 1MB increase in memory usage.
The problem is here, after returning from function , 1MB memory that allocated in function does not release , WHY????

Garbage collector doesn't free up memory right away but
Garbage collection occurs when one of the following conditions is true:
The system has low physical memory. This is detected by either the low memory notification from the OS or low memory indicated by the host.
The memory that is used by allocated objects on the managed heap surpasses an acceptable threshold. This threshold is continuously adjusted as the process runs.
The GC.Collect method is called. In almost all cases, you do not have to call this method, because the garbage collector runs continuously. This method is primarily used for unique situations and testing.
You can find more here.

Managed heap OutOfMemory

EDIT: I reformulated it to be a question and moved the answer to the answers part...
In a relatively complex multithreaded .NET application I experienced OutOfMemoryException even in the cases I could think there is no reason for it.
The situation:
The application is 32bit.
The application creates lot of (thousands) short lived objects that are considered small (less than approx. 85kB).
Additionaly it creates some (hundreds) short lived objects that are considered large (greater than approx. 85kb). This implies these objects are allocated at LOH (large object heap).
Both classes for these objects define finalizer (~MyFinalizer(){...}).
The symptoms:
OutOfMemoryException
Looking at the app via memory profiler, there are thousands of the small objects eligible for collection, but not collected and thus block large amount of memory.
The questions:
Why the app exhausts entire heap?
Why there is lot of "dead" objects still present in the memory?

After some deep investigation I have found the reason. As it took some time, I would like to make it easy for others suffering the same problem.
The reasons:
App has only approx 2GB of virtual address space.
The LOH is by design not compacted and thus might get fragmented very quickly, but for the mentioned count of large objects it should not be any problem.
Due to the design of the Garbage Collector, if there is an object defining the finalizer (even just empty), it is considered as Gen2 object and is placed into GC's finalization queue. This implies, until it is finalized (the MyFinalizer called) it just blocks the memory. In the case of mentioned app the GC thread running the finalizers didn't get the chance to do its work as quickly as needed and thus the heap was exhausted.
The Solution:
Do not use the finalizer for such "dynamic" objects (high volume, short life), workaround the finalization code in other way...
Very useful sources:
The Dangers of the Large Object Heap
Garbage Collection
Will the Garbage Collector call Dispose for me?

Try using a profiler, such as:
ANTS Memory Profiler
ANTS Performance Profiler
Jetbrains Performance Profiler
For LOH force a GC with:
GC.Collect();
GC.WaitForPendingFinalizers();

Why calling GC.Collect() multiple times free some memory that usually isn't cleaned?

I found out a weird thing in GC, when I have application that removed reference to many large objects, it still eats a lot of ram, in my case around 300mb. This memory is not cleaned even if I call GC.Collect()
Then I tried to randomly call it 10 times in few seconds, and result: 200mb of ram was freed resulting in my application eating ONLY 100mb instead of 300mb of private ram (not virtual but the physical / resident ram)
Why is this? How can I make GC clean this memory automatically without having to call it by hand?

Either:
You are still holding onto a reference to the large object somewhere, so even calling GC.Collect can't clean it up.
There is unmanaged memory that accounts for the majority of this memory consumed. You are not properly disposing of that unmanaged resource.

The Garbage Collector will collect any unused objects whenever more memory is needed. An object is only unused when you have no references to it. Use a memory profiler to see what objects are eating up your memory and why they are not collected.
Other than that, you should not need to call GC.Collect ever. The Garbage Collector is more than capable and optimized to choose when it will execute.

Lots of GC questions on SO today!
Maybe it was going to clean it up after that much time had passed anyway. If your program runs out of memory and dies without having that extra call, leave it in, otherwise it's probably unnecessary.

How can I tell if the .Net 3.5 garbage collector has run?

I have an application that creates trees of nodes, then tosses them and makes new trees.
The application allocates about 20 MB upon startup. But I tried loading a large file of nodes many times, and the allocated memory went above 700 MB. I thought I would see memory being freed by the garbage collector on occasion.
The machine I'm on has 12 GB of RAM, so maybe it's just that such a "small" amount of memory being allocated doesn't matter to the GC.
I've found a lot of good info on how the GC works, and that it's best not to tell it what to do. But I wanted to verify that it's actually doing anything, and that I'm not somehow doing something wrong in the code that prevents my objects from being cleaned up.

The GC generally runs when either of the scenarios below occur:
You call GC.Collect (which you shouldn't)
Gen0's budget is exhausted
There are some other scenarios as well, but I'll skip those for now.
You didn't tell us how you measured the memory usage, but if you're looking at the memory usage of process itself (e.g. through task manager), then you may not see the numbers you expect. Remember that the .NET runtime essentially has its own memory manager that handles memory usage on behalf of you managed application. The runtime tries to be smart about it so it doesn't allocate and free memory to the OS all the time (those are expensive operations). This question may be relevant as well.
If you're concerned about memory leaks have a look at some of the answers here.

When does the .Net 3.5 garbage collector run?
I thought I would see memory being freed by the garbage collector on occasion.
Since the GC is non-deterministic, you won't be able to necessarily determine when it is going to issue a collection. Short answer: It will run when needed. Trying to analyze your code and predict or assume it should be running at a certain time usually ends up down a rabbit hole.

Answer to: do I leak objects or GC have not need to run yet?
Use memory profiler to see what objects are allocated. As basic step - force garbage collection (GC.Collect) and check out if allocated memory (GC.GetTotalMemory) seems to be reasonable.

If you want to make sure that you're not leaving any unwanted object behind you can use dotTrace memory profiler. It allows you to take two snapshots of objects in memory (taken some time apart) and compare them. You will can clearly see if any old nodes are still hanging around and what is keeping a reference to them and stops them from being collected.

You may have the managed equivalent of a memory leak. Are you maintaining stale references to these objects (i.e., do you have a List<T> or some other object which tracks these nodes)?
Are the subscribing to an event of an object that is not going out of scope? A reference to the subscribee of an event is maintained, so if you don't detach it will keep your objects alive.
You may also be forgetting to Dispose of objects that implement IDisposable. Can't say without seeing your code.
The exact behavior of the GC is implementation defined. You should design your application such that it does not matter. If you need deterministic memory management then you are using the wrong language. Use a tool (RedGate's ANTS profiler will do) to see if you are leaking references somewhere.

This comic is the best way to explain this topic :)

You can monitor the garbage collector activity in .NET 4.0 and beyond with GC.RegisterForFullGCNotification as described in this link: http://www.abhisheksur.com/2010/08/garbage-collection-notifications-in-net.html