JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning 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: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 204 contents

Long time reader Brent Boyer points out that my point "if you have done all the updating of the HashMap in a single thread or synchronized, then after that it's safe to access it from multiple threads (if they have the view of the map after updating has finished)" from September's newsletter is specific to the existing HashMap implementation; another (future) implementation could perfectly reasonably mutate the map on reads, with Brent giving a desired example of a self-adapting HashMap that changes its internal structure to optimize the read pattern it is being used with, as it monitors those reads.

And of course that's quite true. I wasn't saying that you SHOULD do that with HashMap. If you have a concurrent use for a hashed based map you should definitely use ConcurrentHashMap, and indeed I recommend (as I did last August) that you actually use ConcurrentHashMap as your default map implementation so that maintenance changes are handled correctly.

My point in September's newsletter was about maintenance and could be misconstrued so let me be more accurate:

• Use thread-safe structures where concurrent access/update can happen
• Concurrency do-it-yourself is really hard to get right, try to find a mature thread-safe structure that does it for you (even if that means you have to adapt your flow to use that)
• If you really do need to build thread-safety yourself, do it in an encapsulated way, eg with all the multi-threaded management of access and updates to your data structures hidden behind class APIs so that fixes can be applied internally with no need for the external users to have to change their usage

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

News

Java performance tuning related news.

• JEP to provide a low-overhead way of sampling Java heap allocations, accessible via JVMTI
• Feature request to provide a low-overhead way of sampling Java heap allocations, accessible via JVMTI
• you should know the difference between heap and stack memory if you want to get the most from your applications - converting heap to stack is a valid (but difficult) tuning technique
• Java support for Docker CPU and memory limits

Tools

Java performance tuning related tools.

• The Allocation Instrumenter is a Java agent written using the java.lang.instrument API and ASM. Each allocation in your Java program is instrumented; a user-defined callback is invoked on each allocation
• instructions per cycle is what you want to look at
• Zipkin distributed tracing
• A java agent to generate method mappings to use with the linux 'perf' tool

Articles

• In-Memory Caching: Curb Tail Latency (Yao Yue/InfoQ)
• Optimizing Java with Linux Perf (Staffan Friberg, Thorvald Natvig/JavaOne)
• Finding Subtle but Common Concurrency Issues in Java Programs (Mark Winterrowd/Oracle Developers)
• How to Properly Blame Things for Causing Latency: Distributed Tracing & Zipkin (Adrian Cole/Barcelona JUG)

Jack Shirazi

Back to newsletter 204 contents