Java Collections components (such as Map, List, Set) are used in our applications. When their keys are not properly handled, it will result in a memory leak.
ThreadLocal variables in Java, if not cleared, can accumulate in memory, causing an OutOfMemoryError. Learn how to clear them after use to avoid memory leaks.
Learn how to capture and analyze thread dumps in Java to troubleshoot performance issues, identify bottlenecks, and optimize your application's performance.
java.lang.OutOfMemoryError: Metaspace is a challenging error to diagnose. Delve into its root causes, potential solutions, and effective diagnostic methods.
Find out more about how Garbage Collection (GC) plays an important role in Java’s memory management and helps to reclaim memory that is no longer in use.
Explore the process of enabling GC traces, interpreting the trace data, and the right tools and knowledge needed to study the Garbage Collection behavior.
Spring Boot is a highly popular framework for Java enterprise applications. We will be analyzing the WebClient crash issues along with how to troubleshoot and fix them.
One of our applications was leveraging this NIO; however, it suffered from frequent ‘java.lang.OutOfMemoryError: Direct buffer memory’ when we were running in Java 11.
In this post, we will explore essential CMS JVM arguments, ranging from basic configurations like enabling CMS to advanced options such as compaction and trigger ratios.
In this post, we’re about to unravel the enigma of this file. We’ll delve into its purpose, learn how to decipher its contents and explore its vital information.
In this post, we embark on a journey to unravel the pivotal role of Garbage Collection analysis and explore seven critical points that underscore its significance.
Explore a key performance metric studied during garbage collection — what it means, its significance in Java applications, and how it impacts overall performance.
Parallel garbage collector is one of the oldest Garbage Collection algorithms introduced in JVM to leverage the processing power of modern multi-core systems.
In this post, we are going to discuss a non-intrusive approach (i.e., approach that doesn’t add any noticeable overhead to the application) to diagnose CPU spike.
Delve into 5 effective strategies to help alleviate GC cycle side effects to optimize application performance and mitigate the impact on hosting expenses.
Several of us might be familiar with the clear () API in the Java collections framework. In this post, let’s discuss what is the purpose of this clear() API?
Hello Sree! :-) Yes, seen several times tech world runs behind new buzzwords. But also seen only truth to prevail. Seen it several times. In 2000s, during dotcom boom time everyone was running behind EJB (considered as the holy saviour) just to figure out the scalability bottleneck it brings about.
Agree 100% Allen. To save those few lines of straight forward code, these tooling adds considerable run-time overhead (in terms of CPU & memory) also makes troubleshooting far more complex.
Richard - appreciate your input. We can't dismiss it as 200mb. It's actually whomping 65% of memory is wasted on this vanilla application. Real business applications will be wasting a lot more than this. If you take an AWS EC2 instance, most likely your applications are saturating memory first before saturating CPU, network or storage on that EC2 instance. Just because memory is getting saturated first, you end up provisioning more and more EC2 instances (while other computing resources i.e. CPU, network, storage are still partially utilized). On the other side of the spectrum, a considerable amount of memory is wasted top to bottom because of inefficient programming practices. If you can make your organization write memory efficient code, you can easily cut-down 50% of Cloud provider bill. Which can be several thousands, millions of dollars depending on the organization.
Hello Manish! Appreciate your input. But please note, we aren't doing any customization or enhancement here. We are just deploying vanilla spring boot framework & their poster child pet clinic application. That by itself is wasting 65% of memory.
In this case after this GC event old generation's space increased and didn't decrease. i.e. from 684832k to 699071k. One might wonder how come after GC event old generation space didn't decreas?. It's because all objects in Old generation are actively referenced. Plus objects are young generation are promoted to old generation. Thus old generation size increased. This is very evident if you observe the entire log statement:
a. Young generation space decreased from 116544K to 12164K i.e. there was reduction of 104380k (i.e.116544K - 12164K)
b. Overall heap space decrease from 801376K to 711236K i.e. there was a reduction of 90140k (i.e. 801376K - 711236K)
c. #a - #b i.e. 104380k - 90140k (i.e. 14240k) is the amount of objects that are promoted from Young Generation to Old Generation. You can observe this increase in the Old Generation size reported in the log statement i.e. 684832K->699071K (i.e. 14239k)
You can also upload the logs to http://gceasy.io/ tool, it's going to show you all the details visually, instead of diggin through all the GC log details. Below is couple of screen shot from http://gceasy.io/ tool, generated after parsing the GC logs.
CORE
Comments
Sep 22, 2021 · Ram Lakshmanan
Interesting point of view Shamsul. Thanks.
Sep 22, 2021 · Ram Lakshmanan
Good point Robert. It might be a good contents for a new article. Thanks.
Sep 22, 2021 · Ram Lakshmanan
Hello Sree! :-) Yes, seen several times tech world runs behind new buzzwords. But also seen only truth to prevail. Seen it several times. In 2000s, during dotcom boom time everyone was running behind EJB (considered as the holy saviour) just to figure out the scalability bottleneck it brings about.
Sep 22, 2021 · Ram Lakshmanan
Agree 100% Allen. To save those few lines of straight forward code, these tooling adds considerable run-time overhead (in terms of CPU & memory) also makes troubleshooting far more complex.
May 21, 2021 · Ram Lakshmanan
Hello James! Here is the open source code repo: GitHub - ycrash/buggyapp
Jul 10, 2020 · Ram Lakshmanan
Hello Yogesh! What is the downside you are seeing to this approach? Created files are unique.
Nov 29, 2019 · Ram Lakshmanan
Hello Chandra! You may register here to get desktop trial version: https://heaphero.io/heap-trial-registration.jsp
Nov 21, 2019 · Ram Lakshmanan
Richard - appreciate your input. We can't dismiss it as 200mb. It's actually whomping 65% of memory is wasted on this vanilla application. Real business applications will be wasting a lot more than this. If you take an AWS EC2 instance, most likely your applications are saturating memory first before saturating CPU, network or storage on that EC2 instance. Just because memory is getting saturated first, you end up provisioning more and more EC2 instances (while other computing resources i.e. CPU, network, storage are still partially utilized). On the other side of the spectrum, a considerable amount of memory is wasted top to bottom because of inefficient programming practices. If you can make your organization write memory efficient code, you can easily cut-down 50% of Cloud provider bill. Which can be several thousands, millions of dollars depending on the organization.
Nov 21, 2019 · Ram Lakshmanan
Hello Manish! Appreciate your input. But please note, we aren't doing any customization or enhancement here. We are just deploying vanilla spring boot framework & their poster child pet clinic application. That by itself is wasting 65% of memory.
Nov 21, 2019 · Ram Lakshmanan
Accept our apologies. Now fixed it.
May 26, 2016 · Ram Lakshmanan
Hello Jose!
It's not true.
Thread will enter in to BLOCKED state when it’s waiting for a monitor lock to enter a synchronized block/method
On the other hand Thread will enter in to WAITING state when it’s calling one of the following methods:
+ Object#wait() with no timeout
+ Thread#join() with no timeout
+ LockSupport#park()
May 19, 2016 · Eric Genesky
Excellent article. Very informative, You can also use online tools such as: http://fastthread.io/ - which can analyze thread dumps.
May 07, 2016 · Ram Lakshmanan
Hello Irfan!
In this case after this GC event old generation's space increased and didn't decrease. i.e. from 684832k to 699071k. One might wonder how come after GC event old generation space didn't decreas?. It's because all objects in Old generation are actively referenced. Plus objects are young generation are promoted to old generation. Thus old generation size increased. This is very evident if you observe the entire log statement:
a. Young generation space decreased from 116544K to 12164K i.e. there was reduction of 104380k (i.e.116544K - 12164K)
b. Overall heap space decrease from 801376K to 711236K i.e. there was a reduction of 90140k (i.e. 801376K - 711236K)
c. #a - #b i.e. 104380k - 90140k (i.e. 14240k) is the amount of objects that are promoted from Young Generation to Old Generation. You can observe this increase in the Old Generation size reported in the log statement i.e. 684832K->699071K (i.e. 14239k)
You can also upload the logs to http://gceasy.io/ tool, it's going to show you all the details visually, instead of diggin through all the GC log details. Below is couple of screen shot from http://gceasy.io/ tool, generated after parsing the GC logs.