In thread dump analysis, one of the key parameter to watch out is: Thread Count. You need to know the application’s thread count consumption under the normal scenario. This understanding will help you in following scenarios:

1. To gauge severity of the issue:

When application experiences any problem, thread count will help to gauge the severity of the issue. Suppose your application uses 100 threads in normal scenario. Suddenly if you see thread count to shoot up to 500 or 600 threads, then it’s a clear indication that your application is suffering from thread leaks or some other problem.

2. New release to production:

When you make new release to production, it’s always a best practice to compare the thread count & their states with the previously running release in production environment. This comparison is one of the measurements for the healthiness of the new install.

3. Diagnosis:

When you want to diagnose any performance problems, thread count, their states and stack traces are important metrics to be looked.

Tit-bit 1: If application creates too many threads then it can result in “java.lang.OutOfMemoryError: Unable to create new native thread”.

Tit-bit 2: Threads do not occupy memory space with in JVM heap. They occupy memory space outside the JVM Heap. This is one of the reason why typically Java process takes more than -Xmx value.

Why named as Stock Ticker?

Stock ticker is an excellent indicator that goes up or down based on the entity’s performance, market response, .. Similarly thread count is a good indicator for the health of the JVM. The only caveat is: when stock ticker increases rapidly to any amount, investors are happy. On the other side, if thread count increases rapidly, it won’t make performance engineer that much happy 🙂