will not be garbage-collected, while in CPython 3.4 and later, the finalizers will only be called once, and the objects will be garbage-collected the second time they become unreachable. Problems Object resurrection causes a large number of problems. Complicates garbage collection The possibility of object resurrection means that the garbage collector must check for resurrected objects after finalization – even if it does not actually occur – which complicates and slows down garbage collection. Indestructible objects In some circumstances an object may be indestructible: if an object is resurrected in its own finalizer (or a group of objects resurrect each other as a result of their finalizers), and the finalizer is always called when destroying the object, then the object cannot be destroyed and its memory cannot be reclaimed. Accidental resurrection and leaks Thirdly, object resurrection may be unintentional, and the resulting object may be semantic garbage, hence never actually collected, causing a logical memory leak. Inconsistent state and reinitialization A resurrected object may be in an inconsistent state, or violate class invariants, due to the finalizer having been executed and causing an irregular state. Thus resurrected objects generally need to be manually reinitialized. Unique finalization or re-finalization In some languages (such as Java and Python 3.4+) finalization is guaranteed to happen exactly once per object, so resurrected objects will not have their finalizers called; therefore, resurrected objects must execute any necessary cleanup code outside of the finalizer. In some other languages, the programmer can force finalization to be done repeatedly; notably, C# has GC.ReRegisterForFinalize. Solutions Languages have adopted several different methods for coping with object resurrection, most commonly by having two-phase garbage collection in the presence of finalizers, to prevent dangling references; and by only finalizing objects once, particularly by marking objects as having been finalized (via a flag), to ensure that objects can be destroyed. 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. In Python, prior to Python 3.4, the standard CPython implementation would treat resurrected objects identically to other objects (which had never been finalized), making indestructible objects possible. Further, it would not garbage collect cycles that contained an object with a finalizer, to avoid possible problems with object resurrection. Starting in Python 3.4, behavior is largely the same as Java: objects are only finalized once (being marked as