Ram Lakshmanan

Interesting point of view Shamsul. Thanks.

Good point Robert. It might be a good contents for a new article. Thanks.

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.

Hello James! Here is the open source code repo: GitHub - ycrash/buggyapp

Hello Yogesh! What is the downside you are seeing to this approach? Created files are unique.

Hello Chandra! You may register here to get desktop trial version: https://heaphero.io/heap-trial-registration.jsp

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.

Accept our apologies. Now fixed it.

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()

Excellent article. Very informative, You can also use online tools such as: http://fastthread.io/ - which can analyze thread dumps.

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.