277294.ijbsn.asia: java

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 Sep 28 08:21:47 GMT 2017 From /weblog/java/concurrency

Contended

preventing false sharing with the @Contended annotation - https://dzone.com[..]false-sharing-is-and-how-jvm-prevents-it

(google search) (amazon search)

Thu Aug 31 02:38:43 GMT 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 Jun 02 09:55:34 GMT 2017 From /weblog/java/libraries

Introduction to a library which support faster regular expression processing: http://weblogs.java.net[..]ite/archive/2006/03/a_faster_java_r.html http://www.javaadvent.com[..]-expression-library-benchmarks-2015.html

Regex helper - https://github.com/VerbalExpressions/JavaVerbalExpressions

java-regular-expressions-cheat-sheet - https://zeroturnaround.com[..]abs/java-regular-expressions-cheat-sheet

(google search) (amazon search)

Fri Mar 10 09:49:16 GMT 2017 From /weblog/java/concurrency

Map

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)

Wed Feb 15 09:35:52 GMT 2017 From /weblog/java/libraries