How to analyze a java thread dump?

by

The TID is thead id and NID is: Native thread ID. This ID is highly platform dependent. It’s the NID in jstack thread dumps. On Windows, it’s simply the OS-level thread ID within a process. On Linux and Solaris, it’s the PID of the thread (which in turn is a light-weight process). On Mac OS X, it is said to be the native pthread_t value.

Go to this link: Java-level thread ID: for a definition and a further explanation of these two terms.

On IBM’s site I found this link: How to interpret a thread dump. that covers this in greater detail:

It explains what that waiting on means:
A lock prevents more than one entity from accessing a shared resource. Each object in Java™ has an associated lock (gained by using a synchronized block or method). In the case of the JVM, threads compete for various resources in the JVM and locks on Java objects.

Then it describes the monitor as a special kind of locking mechanism that is used in the JVM to allow flexible synchronization between threads. For the purpose of this section, read the terms monitor and lock interchangeably.

Then it goes further:

To avoid having a monitor on every object, the JVM usually uses a flag in a class or method block to indicate that the item is locked. Most of the time, a piece of code will transit some locked section without contention. Therefore, the guardian flag is enough to protect this piece of code. This is called a flat monitor. However, if another thread wants to access some code that is locked, a genuine contention has occurred. The JVM must now create (or inflate) the monitor object to hold the second thread and arrange for a signaling mechanism to coordinate access to the code section. This monitor is now called an inflated monitor.

Here is a more in-depth explanation of what you are seeing on the lines from the thread dump. A Java thread is implemented by a native thread of the operating system. Each thread is represented by a line in bold such as:

“Thread-1” (TID:0x9017A0, sys_thread_t:0x23EAC8, state:R, native ID:0x6E4) prio=5

*The following 6 items explains this as I’ve matched them from the example, values in the brackets[]:

  1. name [Thread-1],
  2. identifier [0x9017A0],
  3. JVM data structure address [0x23EAC8],
  4. current state [R],
  5. native thread identifier [0x6E4],
  6. and priority [5].

The “wait on” appears to be a daemon thread associated with the jvm itself and not the application thread perse. When you get an “in Object.wait()”, that means the daemon thread, “finalizer” here, is waiting on a notification about a lock on an object, in this case it shows you what notification it’s waiting on:
“- waiting on <0x27ef0288> (a java.lang.ref.ReferenceQueue$Lock)”

Definition of the ReferenceQueue is:
Reference queues, to which registered reference objects are appended by the garbage collector after the appropriate reachability changes are detected.

The finalizer thread runs so the garbage collection operates to clean up resources associated with an object. If I’m seeing it corectly, the finalizer can’t get the lock to this object: java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) because the java object is running a method, so the finalizer thread is locked until that object is finished with it’s current task.

Also, the finalizer isn’t just looking to reclaim memory, it’s more involved than that for cleaning up resources. I need to do more study on it, but if you have files open, sockets, etc… related to an objects methods, then the finalizer is going to work on freeing those items up as well.

What is the figure in squared parenthesis after Object.wait in the
thread dump?

It is a pointer in memory to the thread. Here is a more detailed description:

C.4.1 Thread Information

The first part of the thread section shows the thread that provoked the fatal error, as follows:

Current thread (0x0805ac88):  JavaThread "main" [_thread_in_native, id=21139]
                    |             |         |            |          +-- ID
                    |             |         |            +------------- state
                    |             |         +-------------------------- name
                    |             +------------------------------------ type
                    +-------------------------------------------------- pointer

The thread pointer is the pointer to the Java VM internal thread structure. It is generally of no interest unless you are debugging a live Java VM or core file.

This last description came from: Troubleshooting Guide for Java SE 6 with HotSpot VM

Here are a few more links on thread dumps:

More Related Contents:

  1. Generate a Java thread dump without restarting.
  2. Java: Why main class does not extend Thread class [closed]
  3. What is the volatile keyword useful for?
  4. Using threads to make database requests
  5. wait until all threads finish their work in java
  6. How can I kill a thread? without using stop();
  7. Threads with Key Bindings
  8. When would you call java’s thread.run() instead of thread.start()?
  9. Is a HashMap thread-safe for different keys?
  10. is there a ‘block until condition becomes true’ function in java?
  11. How to get the ThreadPoolExecutor to increase threads to max before queueing?
  12. How does memory reordering help processors and compilers?
  13. Refreshing GUI by another thread in java (swing)
  14. Printing Even and Odd using two Threads in Java
  15. Android – Prevent white screen at startup
  16. When should I use a CompletionService over an ExecutorService?
  17. Busy loop in other thread delays EDT processing
  18. Thread safety of static blocks in Java
  19. Run external program from Java, read output, allow interruption
  20. Threads in Java
  21. Threads and file writing
  22. Thread Confinement
  23. Can’t get past 2542 Threads in Java on 4GB iMac OSX 10.6.3 Snow Leopard (32bit)
  24. java.lang.OutOfMemoryError: unable to create new native thread error using ChromeDriver and Chrome through Selenium in Spring boot
  25. Run Handler messages in a background thread
  26. Regarding thread safety of servlet [duplicate]
  27. JAVAFX : why wait cursor needs a new thread?
  28. Stopping a specific java thread
  29. notifyAll() throws IllegalMonitorStateException
  30. If a synchronized method calls another non-synchronized method, is there a lock on the non-synchronized method

Leave a Comment