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
JProfiler: Get rid of your performance problems and memory leaks! 

News August 2017

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:



JProfiler
Get rid of your performance problems and memory leaks!


Back to newsletter 201 contents

Two months ago I talked about the 3 axes of performance (concurrency, data size and responsiveness) that can help you decide whether good coding practices are sufficient for your component or whether you need to go beyond. This month I'll go into a little detail on the concurrency axis.

(Referenced from my Devoxx talk, slides).

For concurrency, there's an obvious immediate step change in going from 1 to 2 or more threads using your component - once you go beyond one thread you need to make whatever is involved thread safe! Thread safety is much more about program correctness than performance - multi-threaded update to a non-thread-safe data structure can result in corrupt data. Good coding practices for thread-safety is about locking all access and update to any mutable data structure - but that tends to be quite bad for concurrent applications, because you're effectively turning multi-threaded processing into single-threaded processing for any use of that data structure. This is a dilemma - good coding practice competes with good performance.

The solution to this dilemma is to factor in the amount of concurrency needed, preferably by measurement. For low levels of concurrency, locking is likely to be entirely sufficient to achieve performance targets and there is no conflict for following good coding practices. For higher levels of concurrency you need to selectively replace lock- guarded data structures with lock-free mechanisms where the concurrency is getting bottlenecked and limiting throughput. But the implementation of lock-free (or reduced lock) data structures is very difficult, it's easy to add in subtle bugs, so use a mature library rather than implement it yourself wherever possible.

Now on to our usual links to articles, tools, news, talks, blogs. And if you need the tips from this month's articles and talks, as ever they are extracted into this month's tips page.

A note from this newsletter's sponsor

Discover the fastest Java Multi-Model DBMS with an Apache 2 License

News

Java performance tuning related news.

Tools

Java performance tuning related tools.

Articles

Jack Shirazi


Back to newsletter 201 contents


Last Updated: 2017-10-26
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/news201.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us