Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers|

Our valued sponsors who help make this site possible
New Relic: Try free w/ production profiling and get a free shirt! 

Site24x7: Java Method-Level Tracing into Transactions @ $12/Month/JVM. Sign Up! 

News July 2015

jKool for DevOps
Light up your Apps & get a cool t-shirt

JProfiler
Get rid of your performance problems and memory leaks!


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:


New Relic
New Relic: Try free w/ production profiling and get a free shirt!

Site24x7
Site24x7: Java Method-Level Tracing into Transactions @ $12/Month/JVM. Sign Up!


jKool for DevOps
Light up your Apps & get a cool t-shirt

JProfiler
Get rid of your performance problems and memory leaks!


Back to newsletter 176 contents

A tiny change in Java 8 is that Thread.stop(Throwable) is now disabled - it now throws an UnsupportedOperationException instead of working as it did in earlier Java versions. Thread.stop() still works (ie the stop() call with no argument).

A note from this newsletter's sponsor

Site24x7.com : Deep dive Application Performance Monitoring
Fix performance issues with Java, .NET and Ruby platforms.
*** Monitor one app instance starting at $9 ***.

It's likely you've never used either of these calls (apart from maybe just testing when playing around to understand threads), and it's true that both have been deprecated for many many years now (since 1998). It is normally recommended that you shouldn't have any type of Thread.stop() call in your code, because if you do, you're probably doing something wrong. I'll leave it to you to read up on the reason why they're unsafe (which is why they've been deprecated for years). The choice to disable one of the two in Java 8 was a bit idiosyncratic - mainly because it's been deprecated for so long that it was felt that it was time to finally disable it. Thread.stop(Throwable) was chosen as it was the less used and more dangerous of the two (because it lets you throw an arbitrary throwable on any thread).

There is one seemingly valid use-case for keeping the remaining Thread.stop() working - as a last ditch attempt for killing rogue threads in correctly implemented code (threads which you can identify as not correctly operating, you need them to die for whatever reason but you'd rather not terminate the process). But if you've tried this then you've seen threads which haven't responded to Thread.stop() in correctly implemented interruptable code because they're stuck in some kind of native section; and others in loops that wouldn't die (sometime loops can be killed, sometimes not). Generally, this means that there is no reliable way to kill a rogue thread. There're two strategies for dealing with this: 1. Treat the thread as a zombie, just leave it doing effectively nothing and start another thread that works; or 2. Spawn a separate process that IS killable to do the work.

This latter approach is relatively common and Java is being gradually enhanced to allow better control over spawned processes, for example Java 8 now has a Process.destroyForcibly() method for rogue spawned processes; and of course you can use something like ChronicleMap (was SharedHashMap) or MappedBus or any (preferably simple) IPC mechanism to coordinate across the processes. It seems a little clunky to do it this way, but spawning child processes and killing them if necessary is a tried and tested way of maintaining full control over resource usage. Now on to all our usual sections: links to tools, articles, news, talks and as ever, all the extracted tips from all of this month's referenced articles.

A note from this newsletter's sponsor

Java performance tuning related news.

Tools

Java performance tuning related tools.

A note from this newsletter's sponsor

New Relic - Try New Relic today and get your free Data Nerd shirt!
Free SaaS APM tool to monitor, troubleshoot, and tune apps
running on Websphere, Weblogic, Tomcat, Jetty, JBoss, Solr, Resin

Articles

Jack Shirazi


Back to newsletter 176 contents


Last Updated: 2017-03-29
Copyright © 2000-2017 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/news176.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us