≡ Menu

Troubleshooting using Java Thread Dumps – Part 1


‘Threads’ is perhaps the most misunderstood component among Application support engineers and even among Software Developers. Take a look at the following questions that we typically come across in our glorious support career:

  1. What does it mean to say ‘There must be hung Threads’ in the Application?
  2. Have you exhausted the available Threads in Application Server?
  3. Which Thread Pool is used for Web Container?
  4. Do I have to configure the number of JDBC Connections in the connection pool equal to the number of Threads I have in the Application Server?
  5. How can I find out which thread is currently running in the Application Server?
  6. Is ‘number of Threads’ configurable? Can I have unlimited Threads?
  7. How can I find out all Threads that are currently running?
  8. Is there a Thread Dead Lock going on?
  9. How can I kill hung Threads?

Well, after going through this three part series, you will be able to answer all the above questions.

What is a Thread?

Let us clarify one thing first:

The name ‘Thread’ actually can appear in two contexts when we are dealing with JEE Application Servers.

  1. Context 1: Thread as in ‘A thread explicitly created by Application Developer from the code (typically by extending the ‘Thread’ class or by implementing ‘Runnable’ interface).
  2. Context 2: The Application Server Threads provided by the Application Server which is configurable via Application Server Admin utilities (mostly Admin Console)

In this lecture, whenever we say Thread, we will be talking about Context 2 (Application Server Threads). So when you are talking to a developer, be clear about this.

Let us define the Thread:

Work enters Application Server via Threads.  Everything the Application Server does is via Threads. For example, when the Application Server first starts, it spawns a Thread to load the Web Application.

Application Server can spawn multiple Threads to execute things simultaneously. For example, when a user is actively performing some work in the application, it usually occupies a Thread. Now, if a new user logs in, the Application Server can spawn a new thread and execute work for the new user using the new Thread.

Geek Note

A thread is also known as LWPLight Weight Process, It is the basic unit of execution.

A Thread is created by a Process (Heavy weight Process). A process can create multiple Threads (Multi-Threaded Process) or just one Thread (Single Threaded Process). A process at least has one thread which is the PRIMARY Thread.

As you may have guessed, the JVM is a multi-Threaded Process.

Each Thread has its own stack.

All the Threads within a process share the global resources (such as Memory, Operating Systems Resources etc)

Threads in a Java EE Application Server

Remember: The Java EE Application Server (Weblogic, WebSphere etc) are nothing but ‘processes’ as far as Operating System is concerne. Each Application Server instance is a ‘java’ program running in the Operating System. This Application Server Java program is a multi-Threaded program. What is the purpose of this program? It loads and runs the JEE Application written by the developers. Some aspects of the Threads in JEE Application Server (for example: number of Threads) is configurable via the Admin tools provided by the Vendor (ex: Admin Console, wsadmin scripts etc).

Thread Management of one Application Server can differ from another (for example, Jboss and Weblogic)


What is a relationship between the Application Server Threads and the Number of CPUs?

The Server can execute as many Threads simultaneously as the number of CPU cores. Number of cores you have in your server is one of the major factors in determining the number of Threads. But it is not the ONLY factor.

Generally, you should not have to tweak the number of Threads as newer versions of JEE Application servers automatically manage this. Use the following method to determine if you have the optimal number of Threads

  1. Load the application using load testing tools like Jmeter or LoadRunner (or somehow mimic a peak load on the application)
  2. Measure the CPU utilization of the Server (using Operating system tools is fine. For example Windows Task Manager or Unix ‘top’command)
  3. If the CPU is mostly idle, you could technically increase the number of Threads
  4. If the CPU is heavily utilized, you may want to reduce the number of Threads.

Note: Pay attention to the Memory usage as well as Threads consume memory. The above method is only approximate. Multiple iterations of load testing is required if you need to arrive at the best number.


When do you need to take a Thread dump?

The Thread dump will reveal the activity of all the threads within the JVM process at the time of the Thread dump. It is like an X-Ray for the Application Server. You typically need to take a Thread Dump for following types of issues.

  1. Hung Applications (Applications that do not respond)
  2. Extremely poor response times
  3. Very slow startup
  4. Unusual amount of resource utilization (for example, 100% CPU usage most of the time)
  5. Any time you want to see what the Application Server is doing

What you have learnt is a great start for using Thread dumps for troubleshooting. In part2, we will look at the following:

Does taking Thread dump kill the Application Server? Are there any side effects?

How to take a thread dump in various Application Servers?

What is the most imporant piece of information you should look for in a Thread Dump ?

Stay tuned and keep up the good work of keeping the lights on.

Note: For more time saving tips and education, subscribe using the ‘subscribe’ form on the home page.

{ 1 comment… add one }
  • avinash July 6, 2017, 2:20 pm

    Very informative series.

Leave a Comment