Java Performance Tuning
Java(TM) - see bottom of page
Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks!
Training online: Concurrency, Threading, GC, Advanced Java and more ...
Tips October 2023
JProfiler
|
Get rid of your performance problems and memory leaks!
|
JProfiler
|
Get rid of your performance problems and memory leaks!
|
|
|
Back to newsletter 275 contents
https://www.alibabacloud.com/blog/how-to-properly-plan-jvm-performance-tuning_594663
How to Properly Plan JVM Performance Tuning (Page last updated April 2019, Added 2023-10-29, Author Alibaba Cloud, Publisher Alibaba Cloud). Tips:
- Useful skills for JVM performance tuning: Understanding garbage collector; being familiar with the common monitoring tools; the ability to read GC logs.
- Perform JVM tuning only when necessary and practical (JVM performance tuning cannot solve all performance problems).
- Layers to optimize: system architecture; OS configuration; data structures and algorithms in code; JVM garbage collector and memory allocation; database table allocation and SQL.
- The goal of tuning is to make an application have a larger throughput at the lowest cost of hardware consumption.
- Performance gains of any of the three attributes - throughput, latency and memory - is almost always at the cost of the performance loss of one or two of the other attributes.
- Garbage collection tuning principles: each minor GC should collect as many garbage objects as possible to reduce the frequency of Full GC for an application; the larger the memory used by the garbage collector, the more efficient the garbage collection and the smoother the application; tune two of the three performance attributes instead of all the three attributes: throughput, latency, and memory usage.
- A performance tuning procedure - repeat from 1 until all requirements are satisfied, at each stage changing one application aspect or JVM parameter: 1 determine requirements for throughput, latency and memory; 2 select a JVM runtime; 3 optimize application memory usage; 4 optimize application latency; 5 optimize application throughput.
- Determine the active data size: this can be measured by how much space the data in the Java heap occupies when the application is in it's stable phase - ie when it reached a workload that met the business requirements at the business peak in the production environment and stayed stable after the peak was reached.
- GC logs are the best way to collect information required for JVM optimization. These can be enabled in production environments as they have minimal impact on performance while providing rich data.
jmap -histo:live PID
is useful data to analyze he objects used by the application.
- Latency requirements should include acceptable: maximum pause time, minor GC frequency and frequency of the maximum pause time.
- GC tuning should: optimize the young generation size (for pause times, frequency and promotion rate); then the old generation size.
https://dip-mazumder.medium.com/java-memory-leaks-a-comprehensive-guide-to-causes-and-solutions-17e319523499
Java Memory Leaks (OutOfMemoryError) : A Comprehensive Guide to Causes and Solutions (Page last updated September 2023, Added 2023-10-29, Author The Java Trail, Publisher The Java Trail). Tips:
- There are two primary types of memory: stack memory and heap memory. Stack memory is used for managing method calls and storing local variables; Heap memory is where objects and arrays reside, and is managed by the garbage collector.
- A Memory Leak occurs when the application unintentionally retains and consumes memory that is no longer needed or referenced.
- An OutOfMemoryError occurs when the JVM cannot allocate more memory on the heap to accommodate new objects. This error typically arises from inefficient memory usage in the application or insufficient heap space configured.
- You can catch an OutOfMemoryError, but it doesn't usually make sense to do so as you usually can't do much about the lack of memory in your application.
- A common cause of OutOfMemoryError is loading large data sets into memory, like reading large files or processing extensive databases. To solve this, you can either configure the heap size to be big enough, or use streaming or pagination to process data in smaller chunks instead of loading everything at once.
- A common cause of OutOfMemoryError is creating very large arrays. To solve this, you can either configure the heap size to be big enough, or change the structure or algorithm to not need such large arrays.
- Efficient tips for object creation: use immutable objects - these are thread-safe; use efficient data structures for your use case that minimize memory usage and maximize performance; avoid creating unnecessary objects.
- A common cause of OutOfMemoryError is not properly releasing objects. To solve this, use memory profilers to find which objects are still referenced when they needn't be.
- A common cause of OutOfMemoryError is having too small a heap. To solve this, you can should configure the heap size to be big enough using the -Xmx flag.
https://www.youtube.com/watch?v=T6X2Yytrzyg
With Java 21, Your Code Runs Even Faster But How is that Possible? (Page last updated October 2023, Added 2023-10-29, Author Per Minborg, Publisher Devoxx). Tips:
- Interesting metrics: throughput (operations/second), latency (50%, 99.99%), startup latency (time to first request servable), time to normal performance (ie after warmup, when SLAs become valid), power/operation, cost/operation.
- Performance factors to consider: platform architecture (CPU type, number of cores), compute/retrieve ratio (how many operations the CPU can do in the time it takes to retrieve data from memory), GC algorithm, workload distribution (number of threads configured, data variation, traffic load, code paths exercised).
- Testing gotchas: testing once is jittery and un-representative, interpreted code behaves very differently from compiled JIT optimized code, System.currentTimeMillis() can go backwards (eg from NTP), JVM code and branch elimination can give unrepresentative performance for unrepresentative data and workloads, testing on different platforms can give very different (unrepresentative) results, power saving modes can give unrepresentative results, having other processes running at the same time can give unrepresentative results.
- Useful tools while testing: jmh, jfr, perf.
- JDK 21 improved performance of RandomAccessFile, DataOutputStream (so serialization), String.hashCode().
- JDK 22 improved performance of URLEncoder.
- The annotation "@Stable" tells the JVM that the field will be updated at most once - the same as final, but including arrays, ie for an array it indicates that the array elements will be updated at most once.
Jack Shirazi
Back to newsletter 275 contents
Last Updated: 2025-01-27
Copyright © 2000-2025 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/newtips275.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us