出典(authority):フリー百科事典『ウィキペディア(Wikipedia)』「2013/09/21 02:33:56」(JST)
In object-oriented programming languages that use garbage collection, a finalizer is a special method that is executed when an object is garbage collected. It is similar in function to a destructor. In less technical terms, a finalizer is a piece of code that ensures that certain necessary actions are taken when an acquired resource (such as a file or access to a hardware device) is no longer being used. This could be closing the file or signalling to the operating system that the hardware device is no longer needed. However, as noted below, finalizers are not the preferred way to accomplish this and for the most part are fail-safe.
Unlike destructors, finalizers are usually not deterministic. A destructor is run when the program explicitly frees an object. In contrast, a finalizer is executed when the internal garbage collection system frees the object. Depending on the garbage collection method used, this may happen at an arbitrary moment after the object is freed, possibly never.
Programming languages that use finalizers include C# and Java. In C#, and a few others that support finalizers, the syntax for declaring a finalizer mimics that of destructors in C++.
Due to the lack of programmer control over their execution, it is usually recommended to avoid finalizers for any but the most trivial operations. In particular, operations often performed in destructors are not usually appropriate for finalizers. For example, destructors are often used to free expensive resources such as files or network handles. If placed in a finalizer, the resources may remain in use for long periods of time after the program is finished with them. Instead, most languages encourage the dispose pattern whereby the object has a method to clean up the object's resources, leaving the finalizer fail-safe in the case where the dispose method doesn't get called. C#, Java, and Python include syntactic constructs to aid use of the dispose pattern.
Languages with finalizers must also address the problem of object resurrection. Resurrection occurs when an object's finalizer causes the object to become reachable (that is, not garbage). The garbage collector must determine if the object has been resurrected by the finalizer or risk creating a dangling reference. Languages have adopted several different solutions. For example, Java will not free the object until it has proven that the object is once again unreachable, but will not run the finalizer more than once.[1] Objective-C 2.0 will put resurrected objects into a "zombie" state, where they log all messages sent to them, but do nothing else.[2]
Object resurrection is useful to handle a pool of commonly used objects, but it obscures code and makes it more confusing.[1] It should be used only for objects that may be frequently used and where the construction/destruction of it is time-consuming. An example could be an array of random numbers, where a large number of them is created and destroyed in a short time, but where actually only a small number is in use at the same time. With object resurrection, a pooling technique would reduce the unnecessary overhead of creation and destruction. Here, a pool manager would get onto its object stack information in the form of a reference to the object, if it is currently to be destructed. The pool manager will keep the object for reuse later.[3]
全文を閲覧するには購読必要です。 To read the full text you will need to subscribe.
.