Analysis against JVM Thread Dump - Resource Contention

Most of performance issues analyzed against Thread Dump is Resource Contention. That is to say, two or more threads are fighting for the same resource (java object) to ensure they are capable to run, however the resource (java object) is being locked/consumed by another thread and fails to be released in a given time. The keyword in the Thread Dump is "waiting for monitor entry". You may say why it is not "BLOCKED", I will tell you the true in future demonstration.

Demonstration

In this article, let us imagine there are three boys sharing the same bread (the only bread), but each time only ONE boy is allowed to eat the partial and the next boy has to wait until the previous one is done. Here the bread is the shared resource/object and we define it as static in java code.

static Object bread = new Object();

As the current boy requires a few time to chew the bread and no others are allowed to share concurrently, we use synchronized function to lock the bread like below.

synchronized (bread) {
  // eating for a few time
}

All the boys are line up to share the bread one by one, we organize them into three Thread. So the whole source code is clearly presented below.

Run the standalone program and monitor the result, will see "boy 1" consumes much time and the other queued "boy 2" and "boy 3" have no chance to share the bread yet. That is because the resource is locked by "boy 1" and not released.

E:\>java -classpath . zigzag.research.threaddump.ResourceContention
current boy: 1
current boy: 2
current boy: 3
The boy 1 is eating the bread

Such result will bring bad performance to application.

Analysis

Check the Thread Dump and as I stated above the keyword is "waiting for monitor entry". We easily find out that Thread-2 and Thread-1 are "waiting to lock 0x00000007d663a6d0", and "0x00000007d663a6d0" is actually the bread object and it is locked by Thread-0 (locked 0x00000007d663a6d0). So there is nothing to explain more, your duty is to dive into Thread-0 to check the root cause right now.

Nested Contention

A common typical case is that many threads are waiting for thread A to release its resource, and thread A however, is waiting for thread B to release B's resource. I call it nested resource contention. In this case, we shall not be treated by the pretension, instead, put your focus on the REAL root cause B, not A.


Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About


Jie Chen is the L3 memeber in Oracle Agile Support.
This blog focuses on the Maintenance, Diagnosis and Tuning related technical skills.
The technology covers Java/JavaEE, Weblogic, Security, Clustering, and Database of course.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today