Object lifetime

In object-oriented programming (OOP), the object lifetime (or life cycle) of an object is the time between an object's creation and its destruction. Rules for object lifetime vary significantly between languages, in some cases between implementations of a given language, and lifetime of a particular object may vary from one run of the program to another. In object-oriented programming (OOP), the object lifetime (or life cycle) of an object is the time between an object's creation and its destruction. Rules for object lifetime vary significantly between languages, in some cases between implementations of a given language, and lifetime of a particular object may vary from one run of the program to another. In some cases object lifetime coincides with variable lifetime of a variable with that object as value (both for static variables and automatic variables), but in general object lifetime is not tied to the lifetime of any one variable. In many cases – and by default in many object-oriented languages, particularly those that use garbage collection (GC) – objects are allocated on the heap, and object lifetime is not determined by the lifetime of a given variable: the value of a variable holding an object actually corresponds to a reference to the object, not the object itself, and destruction of the variable just destroys the reference, not the underlying object. While the basic idea of object lifetime is simple – an object is created, used, then destroyed – details vary substantially between languages, and within implementations of a given language, and is intimately tied to how memory management is implemented. Further, many fine distinctions are drawn between the steps, and between language-level concepts and implementation-level concepts. Terminology is relatively standard, but which steps correspond to a given term varies significantly between languages. Terms generally come in antonym pairs, one for a creation concept, one for the corresponding destruction concept, like initialize/finalize or constructor/destructor. The creation/destruction pair is also known as initiation/termination, among other terms. The terms allocation and deallocation or freeing are also used, by analogy with memory management, though object creation and destruction can involve significantly more than simply memory allocation and deallocation, and allocation/deallocation are more properly considered steps in creation and destruction, respectively. A major distinction is whether an object's lifetime is deterministic or non-deterministic. This varies by language, and within language varies with the memory allocation of an object; object lifetime may be distinct from variable lifetime. Objects with static memory allocation, notably objects stored in static variables, and classes modules (if classes or modules are themselves objects, and statically allocated), have a subtle non-determinism in many languages: while their lifetime appears to coincide with the run time of the program, the order of creation and destruction – which static object is created first, which second, etc. – is generally nondeterministic. For objects with automatic memory allocation or dynamic memory allocation, object creation generally happens deterministically, either explicitly when an object is explicitly created (such as via new in C++ or Java), or implicitly at the start of variable lifetime, particularly when the scope of an automatic variable is entered, such as at declaration. Object destruction varies, however – in some languages, notably C++, automatic and dynamic objects are destroyed at deterministic times, such as scope exit, explicit destruction (via manual memory management), or reference count reaching zero; while in other languages, such as C#, Java, and Python, these objects are destroyed at non-deterministic times, depending on the garbage collector, and object resurrection may occur during destruction, extending the lifetime. In garbage-collected languages, objects are generally dynamically allocated (on the heap) even if they are initially bound to an automatic variable, unlike automatic variables with primitive values, which are typically automatically allocated (on the stack or in a register). This allows the object to be returned from a function ('escape') without being destroyed. However, in some cases a compiler optimization is possible, namely performing escape analysis and proving that escape is not possible, and thus the object can be allocated on the stack; this is significant in Java. In this case object destruction will occur promptly – possibly even during the variable's lifetime (before the end of its scope), if it is unreachable. A complex case is the use of an object pool, where objects may be created ahead of time or reused, and thus apparent creation and destruction may not correspond to actual creation and destruction of an object, only (re)initialization for creation and finalization for destruction. In this case both creation and destruction may be nondeterministic.