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

https://www.infoq.com/presentations/java-9-gc
Goodbye PrintGCDetails... and Other JDK 9 Changes! (Page last updated April 2017, Added 2017-04-28, Author Tony Printezis, Publisher QCon). Tips:

• GC logging should be enabled (for java 8 or earlier) with -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:[file] -XX:+PrintHeapAtGC -XX:+PrintReferenceGC -XX:+PrintTenuringDistribution
• The times at the end of the GC log, eg "[Times: user=0.55 sys=0.10, real=0.09 secs]" are very useful to indicate if there is competition for CPU or IO resources - for the former you'll see real increase but user stay the same; for the latter sys time will go up.
• Java 9 loses lots of GC logging parameters, for the new unified logging: -Xlog:[gc logging options], eg -Xlog:gc*:file=gc%p%t.log:time,pid or -Xlog:gc=info. The latter produces lines like "[123.450s][info][gc] GC(123) ..." which corresponds to "[time in seconds since JVM start to end of this GC ][info][gc] GC(gc ID) ..."
• Java 9 recommended GC logging parameters are -Xlog:gc*,gc+ref=debug,gc+age=trace,gc+heap=debug:file=gc%p%t.log:tags,uptime,time:filecount=10,filesize=10m (you may need to delete some options for your use).
• Before Java 9, to walk the stack you needed to use Thread.getStackTrace() which always gave the full stack. From Java 9 you can use the StackWalker which is much more efficient.

https://www.youtube.com/watch?v=IBkxiWmjM-g
Java and Performance: Biggest Mistakes (Page last updated June 2015, Added 2017-04-28, Author Andreas Grabner, Publisher SF Java). Tips:

• You can get bad performance from too many SQL statements to obtain results (eg looping to get the data instead of bulk access). If the sample DB is too small, you won't see it in testing, so make sure the test data size is sufficient.
• Measure the time taken by SQL statements, but also how many calls are made. Look also for a count of the same SQL statement being called repeatedly (it's a good prospect for caching the data).
• Measure the time it takes to get each connection from the pool, to show how much time is spent being blocked on connection acquisition.
• Monitor thread counts and idle vs busy thread counts
• Count calls to APIs and times spent in each call so you can see if they are excessive.
• Make sure you test the same version that you deploy - otherwise the test is invalid.
• Ensure the resources you deliver to mobiles are appropriate for a mobile rather than just what you would provide for a webpage - check the number and size of images, the number or redirects, and the size of all resources needed for the app to display.
• Make sure you have tested for expected spikes in traffic - especially if you are trying to generate spiked demand (eg with advertising campaigns), it's a real shame to waste that investment.
• Consider delivering reduced but still useful functionality under high load to ensure responsiveness remains good.
• Add unit tests for performance metrics (eg number of SQL calls).

https://www.youtube.com/watch?v=f2aNWtt0QRo
How to Write Memory-Efficient Java Code (Page last updated June 2015, Added 2017-04-28, Author Chris Bailey, Publisher JavaOne). Tips:

• Avoid allocation by caching objects.
• Objects have overhead, so if you are storing lots of primitive data, use primitive data types where possible.
• Use CompressedOops if your heap is 32GB or under.
• Before Java 9, small Strings use a lot more memory than the bytes needed for the characters
• Temporary objects need to be reclaimed - which takes resources. The more garbage collection the application needs, the more resources it takes away from the application execution.
• Caches can reduce overall memory usage if the objects in the cache can be shared, so avoiding creating multiple instances.
• Using the collection with the minimal set of functionality you need is likely to use a smaller collection (more functionality tends to need more space). Hash collections have a lot of memory overhead. For example ArrayList is much more memory efficient than HashMap.
• Size collections correctly if you know the maximum memory they'll need, this will minimize the memory overhead. Collections do not automatically shrink if they have allocated too much capacity for the actual needs.
• Eclipse MAT has a "Collection Fill Ratio" option that lets you determine how full the collections in a heap dump are.
• Lazily allocate collections to keep memory use down - don't create a collection to store nothing.
• Don't create a collection to store one object, just store the object itself.

https://dzone.com/articles/intricacies-of-multi-threading-in-java
Intricacies of Multi-Threading in Java (Page last updated April 2017, Added 2017-04-28, Author Sumith Puri, Publisher DZone). Tips:

• Where there is concurrent modification of a shared resource, there needs to be controlled access.
• If two threads are trying to acquire a resource where each is held by the other thread, this leads to a deadlock.
• Thread states are: Ready to Run (not yet scheduled on to a CPU, but ready to be); Running (actually executing instructions on the CPU); Waiting/Sleeping/Blocked (waiting for a notification/in a sleep call/blocked on IO); and Completed/Dead.
• If a lock is acquired using "synchronized", it can be released by a wait() call, or by exiting the thread, or by exiting the synchronized block.

Jack Shirazi

Back to newsletter 197 contents