/ How to analyze Thread Dump – Part2: JVM Overview ~ Java EE Support Patterns


How to analyze Thread Dump – Part2: JVM Overview

Before going deeper into Thread Dump analysis and problem patterns, it is very important that you understand the fundamentals. The post will cover the basics and allow you to better your JVM and middleware interaction with your Java EE container.

** UPDATE: Thread Dump analysis tutorial videos now available here.

Java VM overview

The Java virtual machine is really the foundation of any Java EE platform. This is where your middleware and applications are deployed and active.

The JVM provides the middleware software and your Java / Java EE program with:

-        A runtime environment for your Java / Java EE program (bytecode format)

-        Several program features and utilities (IO facilities, data structure, Threads management, security, monitoring etc.)
-        Dynamic memory allocation and management via the garbage collector

Your JVM can reside on many OS (Solaris, AIX, Windows etc.) and depending of your physical server specifications, you can install 1...n JVM processes per physical / virtual server.

JVM and Middleware software interactions

Find below a diagram showing you a high level interaction view between the JVM, middleware and application(s).

This is showing you a typical and simple interaction diagram between the JVM, middleware and application. As you can see, the Threads allocation for a standard Java EE application are done mainly between the middleware kernel itself and JVM (there are some exceptions when application itself or some APIs create Threads directly but this is not common and must be done very carefully).

Also, please note that certain Threads are managed internally within the JVM itself such as GC (garbage collection) Threads in order to handle concurrent garbage collections.

Since most of the Thread allocations are done by the Java EE container, it is important that you understand and recognize the Thread Stack Trace and identify it properly from the Thread Dump data. This will allow you to understand quickly the type of request that the Java EE container is attempting to execute.

From a Thread Dump analysis perspective, you will learn how to differentiate between the different Thread Pools found from the JVM and identify the request type.

The Thread Dump Analysis Part 3 is now available and will provide you a high level overview of a Thread Dump and breakdown for the HotSpot VM 1.6 Thread Dump format.


Hi ,

I found this article very interesting . Eagerly waiyting for the next post . When can we have the next post .


Thanks Kiran,

I will be away next week but releasing the part 3 in about 2 weeks or before.


good.. I think in the picture JVM should have been in the bottom and Java EE Apps on the top, i mean it should be bottom up from JVM. am I correct?


Actually for the JVM, you should see it as the overall "bubble" where the middleware and Java EE apps are deployed. The picture presents a different perspective in order to understand the interaction.

From a bottom-up view perspective it is:

JVM >> Middleware >> Java EE Apps


This is a kind of article I was searching for long .. I have just started reading but really impressed with your teaching methodology.
I will give you more feedback going onwards

" (there are some exceptions when application itself or some APIs create Threads directly but this is not common and must be done very carefully)."

can you please provide more info about this? do you mean native threads? which memory does this threads use? jvm heap or other memory block?

Hi Jit,

I meant Java threads you would be creating yourself from your application code which is not recommended. These threads would be under the developer control and using same memory block as middle-ware level threads. Please keep in mind that Java threads mainly requires native memory form the OS and a small portion on the Java heap.


Excuse me !what differences about Java Heap and Native Heap?

Post a Comment