Tue Oct 31 02:18:25 GMT 2017 java.lang.refOverview of weak, soft and Phantom References Second, PhantomReferences avoid a fundamental problem with finalization: finalize() methods can "resurrect" objects by creating new strong references to them. So what, you say? Well, the problem is that an object which overrides finalize() must now be determined to be garbage in at least two separate garbage collection cycles in order to be collected. When the first cycle determines that it is garbage, it becomes eligible for finalization. Because of the (slim, but unfortunately real) possibility that the object was "resurrected" during finalization, the garbage collector has to run again before the object can actually be removed. And because finalization might not have happened in a timely fashion, an arbitrary number of garbage collection cycles might have happened while the object was waiting for finalization. This can mean serious delays in actually cleaning up garbage objects, and is why you can get OutOfMemoryErrors even when most of the heap is garbage. http://weblogs.java.net[..]las/archive/2006/05/understanding_w.html The other valuable reference about object life cycle - http://java.sun.com[..]ormance/1st_edition/html/JPAppGC.fm.html Incorrect use of reference can cause GC issue - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4405807 fews more related blog - http://www.egimaben.com[..]garbage-collector-and-reference-objects/ https://medium.com[..]in-java-and-why-they-matter-c04bfc9dc792 (google search) (amazon search) second |