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 June 2010

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 115 contents

Threads, threads, threads. I gave some interesting examples of concurrency issues in my talk last month, and I showed how to identify and resolve them. I was interested to see that the audience found these examples just as challenging as when I first encountered them "in the wild" - i.e. in the production systems I was troubleshooting when I first found them. But there was one particular question that I want to address here: is there a general way to code to avoid concurrency problems?

The answer is yes. It's not a technique I thought of, in fact it was my own concurrency guru, Brian Goetz (who is still with Oracle after the Sun takeover), who pointed it out to me. The technique is to never write any multi-threading or synchronizing code, except in specialist classes which handle all the issues under the covers. Ideally, you use what has already been developed by the experts out there: use ConcurrentHashMap rather than HashMap as your default Map; use a BlockingQueue to pass things between threads without having to think about synchronization to share the data; GC is dirt cheap now for short-lived objects so don't think twice about copying out data to a temporary object for manipulation or iterating; and so on.

A note from this newsletter's sponsor

JProbe?is an enterprise-class Java profiler, providing?diagnostics
on memory usage, performance and test coverage. Download
a 10-day trial and see why it?s the industry leader in Java profiling.

Of course, sadly there is not a data structure for every, or even most, of the code problems you need to solve. So inevitably you will have to write some classes yourself that handle concurrency issues. The point that Brian made to me was that you should isolate that concurrency managing code into separate dedicated classes and, most importantly, spend a lot of time getting those classes right and reusable because concurrency is hard, even for the experts.

If you find yourself writing concurrency handling code in some method you are implementing, then you need to stop and think: where should that code actually be? Because I shouldn't be writing this here, it should be abstracted away into some handling class which will allow me to write this code without explicit concurrency management. Easier said than done, of course, but the payback in reduced incidents and maintenenance costs is well worth it.

Now on with this month's newsletter. We have all our usual Java performance tools, news, and article links, though no Javva The Hutt as he preferred Glastonbury to the rigour of his column deadline. Over at fasterj we have a new cartoon showing where the application spends its time; and, as usual, we have extracted tips from all of this month's referenced articles.

A note from this newsletter's sponsor

ManageEngine: Application Performance Management for Java EE Apps.
Monitor App Servers: JBoss, WebSphere, WebLogic, JVMs and JMX Apps.
*** Monitor up to 25 App Servers, Databases & Servers at $795/Yr***.

News

Java performance tuning related news.

Tools

Java performance tuning related tools.

A note from this newsletter's sponsor

New Relic RPM - The Revolution in Java Performance Management is Here!
Affordable SaaS APM tool to monitor, troubleshoot, and tune apps
running on Websphere, Weblogic, Tomcat, Jetty, JBoss, Solr, Resin

Articles

Jack Shirazi


Back to newsletter 115 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/news115.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us