download zip of files only
Tue Oct 31 10:18:25 HKT 2017
From /weblog/java/fundamental
Overview 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.
With PhantomReference, this situation is impossible -- when a PhantomReference is enqueued, there is absolutely no way to get a pointer to the now-dead object (which is good, because it isn't in memory any longer). Because PhantomReference cannot be used to resurrect an object, the object can be instantly cleaned up during the first garbage collection cycle in which it is found to be phantomly reachable. You can then dispose whatever resources you need to at your convenience.
Arguably, the finalize() method should never have been provided in the first place. PhantomReferences are definitely safer and more efficient to use, and eliminating finalize() would have made parts of the VM considerably simpler. But, they're also more work to implement, so I confess to still using finalize() most of the time. The good news is that at least you have a choice. 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)
Thu Aug 31 10:38:43 HKT 2017
From /weblog/java/tools
The jhsdb tool is described on its Oracle JDK 9 Documentation Early Access page, "You use the jhsdb tool to attach to a Java process or to launch a postmortem debugger to analyze the content of a core-dump from a crashed Java Virtual Machine (JVM)." The tool comes with several "modes" and several of these modes correspond in name and function with individual command-line tools available in previous JDK distributions. The jhsdb tool not only provides a single tool that encompasses functionality of multiple other tools, but it also provides a single, consistent approach to applying these different functions. For example, the jhsdb command-line syntax for getting help for each of the "modes" is identical. http://marxsoftware.blogspot.hk/2017/06/jhsdb-jdk9.html https://docs.oracle.com[..]UID-0345CAEB-71CE-4D71-97FE-AA53A4AB028E
(google search)
(amazon search)
Fri Mar 10 17:49:16 HKT 2017
From /weblog/java/concurrency
putall can cause ConcurrentModifcationException - http://cr.openjdk.java.net[..]ses/sun/management/Agent.java.sdiff.html Note on writing CopyOnWrite wrapper - http://flyingspaniel.blogspot.com[..]ot.com/2010/12/copyonwrite-wrappers.html Sometime this is a bit difficult for Chinese to be a good programmer, recently some colleague and me discuss about the behaviour of this class and look like we have difficult understanding A: ConcurrentHashMap support for locking as this is thread-safe B: ConcurrentHashMap is thread safe for read but not for write because there is no lock, we still need to have external lock to keep it thread safe. By the way, I get ConcurrentModificationException from this before. C: ConcurrentHashMap don't support for locking but they still thread safe for all operations, which is how "This class is fully interoperable with Hashtable in programs that rely on its thread safety but not on its synchronization details." mentioned. Too good that we can actually take a look at the source code to see what going on nowadays rather than just guessing - http://www.google.com[..]HashMap&sourceid=opera&ie=utf-8&oe=utf-8 By the way, this constructor is useful for a lot of concurrency access but actually not many developer notice about this - http://java.sun.com[..]rrentHashMap.html#ConcurrentHashMap(int, float, int) Lazy initialization of map values - http://artisans-serverintellect-com.si-eioswww6.com[..]ect-com.si-eioswww6.com/default.asp?W122 HashMap.get() can cause infinite loop - http://lightbody.net[..]5/07/hashmapget_can_cause_an_infini.html Discussing the effect of initCapacity() of HashMap in Java - http://saloon.javaranch.com[..]ltimatebb.cgi?ubb=get_topic&f=1&t=021171 OpenJDK and HashMap …. Safely Teaching an Old Dog New (Off-Heap!) Tricks - http://www.infoq.com/articles/Open-JDK-and-HashMap-Off-Heap We can run search in ConcurrenctHashMap - https://dzone.com/articles/concurrenthashmap-in-java8
(google search)
(amazon search)
|