Finalization

1.what is the main disadvantage of garbage collection？

Typically, garbage collection has certain disadvantages, including consuming additional resources, performance impacts, possible stalls in program execution, and incompatibility with manual resource management.

 

Garbage collection consumes computing resources in deciding which memory to free, even though the programmer may have already known this information.

The penalty惩罚 for the convenience of not annotating object lifetime manually in the source code is overhead, which can lead to decreased or uneven performance.^[4] 

A peer-reviewed paper came to the conclusion that GC needs five times the memory to compensate for this overhead and to perform as fast as explicit memory management.^[5] 

Interaction with memory hierarchy effects can make this overhead intolerable in circumstances that are hard to predict or to detect in routine testing.

The impact on performance was also given by Apple as a reason for not adopting garbage collection in iOS despite being the most desired feature.^[6]

 

The moment when the garbage is actually collected can be unpredictable, resulting in stalls (pauses to shift/free memory) scattered throughout a session.

Unpredictable stalls can be unacceptable in real-time environments, in transaction processing, or in interactive programs.

Incremental, concurrent, and real-time garbage collectors address these problems, with varying trade-offs.

 

The modern GC implementations try to avoid blocking "stop-the-world" stalls by doing as much work as possible on the background (i.e. on a separate thread),

for example marking unreachable garbage instances while the application process continues to run.

In spite of these advancements, for example in .NET CLR paradigm it is still very difficult to maintain large heaps (millions of objects) with resident objects

that get promoted to older generations without incurring noticeable delays (sometimes a few seconds).

 

Non-deterministic GC is incompatible with RAII based management of non-GCed resources^{[citation needed]}.

As a result, the need for explicit manual resource management (release/close) for non-GCed resources becomes transitive to composition.

That is: in a non-deterministic GC system, if a resource or a resource-like object requires manual resource management (release/close),

and this object is used as "part of" another object, then the composed object will also become a resource-like object that itself requires manual resource management (release/close).

 

2.How do you achieve deterime finalization?

https://www.safaribooksonline.com/library/view/programming-net-components/0596102070/ch04s05.html

The Open/Close Pattern

The Dispose() Pattern

The IDisposable Pattern

Disposing and Error Handling

作者:Chuck Lu    GitHub