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

https://www.youtube.com/watch?v=iPQbOTv5wRk
Java Concurrency: Fun Footguns for all! (Page last updated November 2018, Added 2020-04-28, Author Thomas May, Publisher Clearwater Analytics). Tips:

• Threads are lightweight processes (but not very lightweight) with shared memory within the process.
• Main threading problems are deadlocks, livelocks, race conditions, and context switching
• Creating new threads should not be done for short activities as teh thread overhead swamps the time taken
• Handling thread data concurrency can be done by using volatile, locks, or making objects immutable (all fields final)
• Immutable objects are very useful and the recommended way to avoid concurrency bugs but do incur additional copying overheads
• Locking objects can be very safe for concurrency, but inefficient and easy to cause bugs
• Deadlocks can be avoided with any of lock ordering, immutable objects, and consolidating locks
• Parallelism coordination overhead can easily cancel any expected benefit from going parallel
• Improving the algorithm is where to focus first before trying to go parallel

https://www.youtube.com/watch?v=cvPgHsRHyMg
Monitoring Tools for Java Heap Sizing for StreamBase 7 and 10 (Page last updated August 2018, Added 2020-04-28, Author Tibco, Publisher Tibco). Tips:

• VisualVM shows JVM args (overview tab); CPU, class, memory and thread statistics (monitor tab); a heap dump button (monitor tab); thread stack view (menu option); plugins (visualgc is recommended).
• Look for a sawtooth pattern in the VisualVM Monitor->Heap tab which is a roughly constant pattern - a regular periodicity with similar peak values and similar trough values - this indicates a stable memory application. If the troughs of the sawtooth are instead gradually increasing, that indicates the application will come under memory pressure and eventually memory exhausation
• The garbage collector becomes much more active when the application is more active. Activities like queueing puts more pressure on the garbage collector.
• Testing should include stressing the application so that monitoring shows the effect of stressing the application and tuning can be lead that way
• JMC adds option flight recording capability but that has some overhead
• JMC includes the JVM overview, mbeans, triggers for alerting on various metrics, system, memory (heap and non-heap), threads, and a diagnostic commands tab that has query actions available.
• Pay attention to CPU use and frequency and depth of garbage collections. Not enough CPU can lead to pressure on the garbage collector.

https://mydeveloperplanet.com/2018/11/14/how-to-solve-your-java-performance-problems-part-1/
How to Solve Your Java Performance Problems (Part 1) (Page last updated November 2018, Added 2020-04-28, Author Gunter Rotsaert, Publisher mydeveloperplanet). Tips:

• The Performance Diagnostic Methodology (PDM): is kernel CPU > 10% => OS issue; otherwise is CPU NOT high => no dominator; otherwise is the object lifecycle efficient => application issue; otherwise it's a JVM issue (eg GC)
• Before tuning, know your resources, know the application architecture, and measure at each entry and exit point of your architecture
• vmstat-> look at system utilization - is it > 10%? look at context switching, disk IO, virtualization (like throttling), or network IO
• vmstat-> look at user CPU - is it close to 100%? look at GC
• Memory leaks can be quickly diagnosed by looking at generation counts - high values suggest these objects are leaking
• If CPU usage is low, this suggests threads are waiting on locks or IO. Use thread analysis to see why.

Jack Shirazi Back to newsletter 233 contents