Geek Answers Handbook

Java threads: interpreting thread states of a running JVM

A Java thread is always in one of the following states:

NEW: Just starting up, ie, in process of being initialized. NEW_TRANS: Corresponding transition state (not used, included for completness). IN_NATIVE: Running in native code. IN_NATIVE_TRANS: Corresponding transition state. IN_VM: Running in VM. IN_VM_TRANS: Corresponding transition state. IN_JAVA: Running in Java or in stub code. IN_JAVA_TRANS: Corresponding transition state (not used, included for completness). BLOCKED: Blocked in vm. BLOCKED_TRANS: Corresponding transition state.

Unused state ( UNINITIALIZED ) was omitted from the list.

While the state definitions are given above, I’m looking for a “thumb rule” to interpret a given stream state setting for a running application server. And more specifically:

Assume that a real-time application server with the following flow statistics (obtained using jstack ) at different points in time:

  • 100 streams: 35 BLOCKED , 65 IN_NATIVE
  • 113 streams: 35 BLOCKED , 77 IN_NATIVE , 1 IN_VM
  • 52 streams: 38 BLOCKED , 1 IN_JAVA , 6 IN_NATIVE , 7 IN_VM
  • 120 streams: 39 BLOCKED , 1 IN_JAVA , 80 IN_NATIVE
  • 94 streams: 34 BLOCKED , 59 IN_NATIVE , 1 IN_NATIVE_TRANS

For each stream of five statistics — what can be done about the overall state of the JVM? Ie "in this JVM scenario, it looks idle waiting for requests", "the machine is busy processing requests", etc.

+4
source share
3 answers

This output level does not provide enough information to create such statements.

As an example, consider the BLOCKED state: there are many things that can cause thread blocking. Two of them are waiting for data to arrive from the client, and are waiting for data to return from the database. In the first case, your application is idle, in the second it is overloaded.

Edit: without looking at the result from jstack, I believe that these two conditions can also be represented as IN_NATIVE. However, the same comment contains: you do not know what they are doing, so you cannot make any statements about the application as a whole.

+4
source

kdgregory is true that the state of the stream will not necessarily reveal what you want yourself. However, jstack should also give you stack traces, allowing you to see exactly where the threads are in your program (assuming it is not confused or something else). For example, a BLOCKED stream whose trace contains a call to InputStream.read () should be fairly obvious.

+1
source

I would say that it’s interesting to look at the state of the threads in general or to really profile the data as a whole in order to be able to ask myself: “Did I expect this to be so?” Unless you have an opinion on whether the data you are receiving is bad / good / expected / unexpected, then it is difficult to do a lot.

With thread states, I think it’s more interesting to look at the behavior of individual threads, and then ask myself: “I expected this thread to be in this state / wait for this lock for a long time?” And just knowing that this thread is blocked / waiting, etc. By itself, it is not as interesting as knowing that it was blocked / waiting.

+1
source

More articles:


All Articles