is sometimes called a or zombie, but this term is used for various object states related to object destruction, with usage depending on language and author. A "zombie object" has a specialized meaning in Objective-C, however, which is detailed below. Zombie objects are somewhat analogous to zombie processes, in that they have undergone a termination state change and are close to deallocation, but the details are significantly different. Variants In the .NET Framework, notably C# and VB.NET, "object resurrection" instead refers to the state of an object during finalization: the object is brought back to life (from being inaccessible), the finalizer is run, and then returned to being inaccessible (and no longer is registered for future finalization). In .NET, which objects need finalization is not tracked object-by-object, but instead is stored in a finalization "queue", so rather than a notion of resurrected objects in the sense of this article, one speaks of objects "queued for finalization". Further, objects can be re-enqueued for finalization via GC.ReRegisterForFinalize, taking care to not multiply enqueue objects. Mechanism There are two main ways that an object can resurrect itself or another object: by creating a reference to itself in an object that it can reach (garbage is not reachable, but garbage can reference non-garbage objects), or by creating a reference in the environment (global variables, or in some cases static variables or variables in a closure). Python examples of both follow, for an object resurrecting itself. It is also possible for an object to resurrect other objects if both are being collected in a given garbage collection cycle, by the same mechanisms. Resurrects itself by creating a reference in an object it can reach: class Clingy: def __init__(self, ref=None) -> None: self.ref = ref def __del__(self): if self.ref: self.ref.ref = self print("Don't leave me!") a = Clingy(Clingy()) # Create a 2-element linked list, # referenced by |a| a.ref.ref = a # Create a cycle a.ref = None # Clearing the reference from the first node # to the second makes the second garbage a.ref = None Resurrects itself by creating a reference in the global environment: c = None class Immortal: def __del__(self): global c c = self print("I'm not dead yet.") c = Immortal() c = None # Clearing |c| makes the object garbage c = None In the above examples, in CPython prior to 3.4, these will run finalizers repeatedly, and the objects