Java 线程：解释正在运行的 JVM 的线程状态
Java 线程始终处于以下十种状态之一：
NEW: Just starting up, i.e., 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.
未使用状态 (UNINITIALIZED) 已从列表中省略。
虽然上面给出了状态的定义，但我正在寻找“经验法则”来解释正在运行的应用程序服务器的给定线程状态设置。更具体地说：
假设一个实时应用程序服务器具有以下线程统计信息（使用 jstack）在不同时间点：
- 100 个线程：35
BLOCKED、65IN_NATIVE - 113 个线程：35
BLOCKED>、77IN_NATIVE、1IN_VM - 52 个线程：38
BLOCKED、1IN_JAVA、6IN_NATIVE< /code>, 7IN_VM - 120 个线程：39
BLOCKED, 1IN_JAVA, 80IN_NATIVE - 94 个线程：34 < code>BLOCKED, 59
IN_NATIVE, 1IN_NATIVE_TRANS
对于五个统计信息中的每个线程 - 可以推断出有关 JVM 整体状态的什么信息？ 即“在这种情况下，JVM 看起来正在空闲等待请求”、“机器正忙于处理请求”等。
A Java thread is always in one of the following ten states:
NEW: Just starting up, i.e., 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.
The unused state (UNINITIALIZED) has been omitted from the list.
While the definitions of the states are given above I'm looking for "rule-of-thumbs" for interpreting a given thread state setup for a running appserver. And, more specifically:
Assume a live application server with the following thread statistics (obtained using jstack) at various points in time:
- 100 threads: 35
BLOCKED, 65IN_NATIVE - 113 threads: 35
BLOCKED, 77IN_NATIVE, 1IN_VM - 52 threads: 38
BLOCKED, 1IN_JAVA, 6IN_NATIVE, 7IN_VM - 120 threads: 39
BLOCKED, 1IN_JAVA, 80IN_NATIVE - 94 threads: 34
BLOCKED, 59IN_NATIVE, 1IN_NATIVE_TRANS
For each thread of the five statistics - what can be inferred with regards to the overall JVM state? I.e. "in this scenario the JVM looks to be idling waiting for requests", "the machine is busy processing requests", etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
此级别的输出无法提供足够的信息来做出此类陈述。
举个例子，考虑 BLOCKED 状态：有很多事情可能导致线程被阻塞。其中两个正在等待来自客户端的数据，并等待数据从数据库返回。在第一种情况下，您的应用程序处于空闲状态，在第二种情况下，您的应用程序已过载。
编辑：没有查看 jstack 的输出，我想这两个条件也可以表示为 IN_NATIVE。然而，同样的评论也成立：您不知道他们在做什么，因此您无法对整个应用程序做出任何陈述。
This level of output doesn't provide enough information to make such statements.
As an example, consider the BLOCKED state: there are many things that can cause a thread to be blocked. Two of them are waiting for data to come from a client, and waiting for data to come back from a database. In the first case, your application is idle, in the second it's overloaded.
Edit: not having looked at the output from jstack, I suppose that these two conditions could also be represented as IN_NATIVE. However, the same comment holds: you don't know what they're doing, so you can't make any statements about the application as a whole.
kdgregory 是正确的，线程状态本身不一定会揭示您想要的内容。然而，jstack 还应该为您提供堆栈跟踪，让您准确地看到线程在程序中的位置（假设它没有被混淆或其他什么）。例如，一个 BLOCKED 线程的跟踪包含对 InputStream.read() 的调用，应该是相当明显的。
kdgregory is correct that thread state won't necessarily reveal what you want by itself. However, jstack should also give you stack traces, letting you see exactly where the threads are in your program (assuming it's not obfuscated or something). A BLOCKED thread whose trace contains a call to InputStream.read(), for example, should be fairly obvious.
我想说，在查看线程状态或实际上分析数据时，通常有趣的是能够问自己“我是否期望出现这种情况？”如果您对获得的数据是坏/好/预期/意外没有意见，那么就很难对此做太多事情。
对于线程状态，我认为查看单个线程的行为然后问自己“我是否期望该线程处于该状态/等待该锁这么长时间？”会更有趣。 ”仅仅知道给定的线程被阻塞/等待等本身并不像知道它被阻塞/等待什么那么有趣。
I'd say what's interesting in general when looking at thread states or indeed profiling data in general is to be able to ask yourself "Did I expect this to be the case?" If you have no opinion on whether the data you're getting is bad/good/expected/unexpected, then it's difficult to do much about it.
With thread states, I think this is more interesting to look at the behaviour of individual threads and then ask yourself "did I expect that thread to be in that state/waiting for that lock for quite so long?" And just knowing that a given thread is blocked/waiting etc per se isn't so interesting as knowing WHAT it was blocked/waiting for.