download zip of files only
Sat Feb 13 14:24:00 GMT 2021
From /weblog/java/fundamental
In this post we will be looking at crash logs, the hs_err file, that is generated when the Java Virtual Machine crashes. Trying to find what is going wrong, and which component to blame, is important to understand how to interpret the crash log file. The focus will be on understanding the frames that make up the stack trace. - https://inside.java/2021/02/12/deciphering-the-stacktrace/
(google search)
(amazon search)
Tue Oct 31 02:18:25 GMT 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)
Sun Dec 14 01:38:06 GMT 2014
From /weblog/java/fundamental
createTempFile() will not delete after JDK quit... which I also suppose it will List of issue about File api, which I totally agree. http://hoskinator.blogspot.com/2006/06/using-file-class.html delete() will delete the file immediately even using some 3rd undelete utility cannot recover , I think the implementation should allow recovery chance - http://www.ryanlowe.ca[..]es/000574_java_delete_to_recycle_bin.php http://blog.pengyifan.com/java-io-in-nutshell-22-case-studies/
(google search)
(amazon search)
Sun Dec 14 01:37:13 GMT 2014
From /weblog/java/fundamental
One fact of System.nanoTime() , I think System.nanoTime()'s contract right now is that it *always*
increases by a fixed amount. In other words, it's monotonic. So NTP
updates, or user's changing system time can never cause any change to
System.nanoTime(). https://jsr-310.dev.java.net/servlets/ReadMsg?list=dev&msgNo=1282 A more detailed explanation of nanoTime() and currentMilliSecond() - http://blogs.sun.com/dholmes/entry/inside_the_hotspot_vm_clocks http://blog.joda.org[..]nverting-from-joda-time-to-javatime.html
(google search)
(amazon search)
Sat May 14 18:01:11 GMT 2011
From /weblog/java/fundamental
Add custom classloaders to compilation classpath: "javac -J-Djava.system.class.loader=my.custom.ClassLoaderImpl theSource.java" http://forums.java.net[..]read.jspa?messageID=87728&tstart=0#87728 Possible NULL from static fields... which is documented behaviours - http://qaix.com[..]2-puzzling-class-field-hellip-read.shtml Comparing Class.getResourceAsStream() and bundle.getEntry(), point out some issues of using Class.getResourceAsStream() - http://www.eclipsezone.com/eclipse/forums/t101557.rhtml Basic of classloader - http://www.journaldev.com[..]rstanding-and-extending-java-classloader http://java.sun.com[..]chnicalArticles/Networking/classloaders/
(google search)
(amazon search)
|