java 分析线程_多线程 - 如何分析java线程转储？

TID是thead id，NID是：本机线程ID。 此ID高度依赖于平台。 它是jstack线程转储中的NID。 在Windows上，它只是进程中的操作系统级线程ID。 在Linux和Solaris上，它是线程的PID(这又是一个轻量级的过程)。 在Mac OS X上，它被称为本机pthread_t值。

转到此链接：Java级别的线程ID：有关这两个术语的定义和进一步说明。

在IBM的网站上，我找到了这个链接：如何解释线程转储。 更详细地介绍了这一点：

它解释了等待的意思：锁可防止多个实体访问共享资源。 Java™中的每个对象都有一个关联的锁(通过使用同步块或方法获得)。 对于JVM，线程竞争JVM中的各种资源并锁定Java对象。

然后，它将监视器描述为一种特殊的锁定机制，在JVM中使用它以允许线程之间的灵活同步。 出于本节的目的，请交替阅读术语监视器和锁定。

然后它进一步：

为避免在每个对象上都有监视器，JVM通常使用类或方法块中的标志来指示该项是否已锁定。 大多数情况下，一段代码会在没有争用的情况下传输一些锁定的部分。 因此，监护人标志足以保护这段代码。 这称为平板显示器。 但是，如果另一个线程想要访问某些已锁定的代码，则会发生真正的争用。 JVM现在必须创建(或膨胀)监视器对象以保存第二个线程，并安排信号机制来协调对代码段的访问。 此监视器现在称为充气监视器。

以下是对线程转储中的内容进行更深入的解释。 Java线程由操作系统的本机线程实现。 每个线程用粗体表示，例如：

＆＃34;线程1＆＃34; (TID：0x9017A0，sys_thread_t：0x23EAC8，状态：R，本机ID：0x6E4)prio = 5

*以下6个项目解释了这一点，因为我已从示例中将它们与括号[]中的值进行匹配：

name [Thread-1]，

标识符[0x9017A0]，

JVM数据结构地址[0x23EAC8]，

现状[R]，

本机线程标识符[0x6E4]，

和优先[5]。

＆＃34;等待＆＃34; 似乎是与jvm本身相关联的守护程序线程，而不是应用程序线程perse。 当你在Object.wait()＆＃34;中获得＆＃34;时，这意味着守护程序线程＆＃34;终结器＆＃34; 在这里，正在等待关于对象锁定的通知，在这种情况下，它会显示它正在等待的通知：＆＃34; - 等待＆lt; 0x27ef0288＆gt; (一个java.lang.ref.ReferenceQueue $ Lock)＆＃34;

ReferenceQueue的定义是：参考队列，在检测到适当的可达性更改后，垃圾收集器将附加的注册引用对象附加到该引用队列。

终结器线程运行，因此垃圾收集操作以清理与对象关联的资源。 如果我正确地看到它，终结器无法获得对此对象的锁定：java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)因为java对象正在运行一个方法，所以 终结器线程被锁定，直到该对象完成它的当前任务。

此外，终结者并不只是想回收内存，它比清理资源更具参与性。 我需要对它进行更多的研究，但是如果你有文件打开，套接字等......与对象方法有关，那么终结器也可以解决这些问题。

在Object.wait之后的平方括号中的数字是多少   线程转储？

它是内存中指向线程的指针。 这是一个更详细的描述：

C.4.1线程信息

线程部分的第一部分显示了引发致命错误的线程，如下所示：

Current thread (0x0805ac88): JavaThread "main" [_thread_in_native, id=21139]

| | | | +-- ID

| | | +------------- state

| | +-------------------------- name

| +------------------------------------ type

+-------------------------------------------------- pointer

线程指针是指向Java VM内部线程结构的指针。 除非您正在调试实时Java VM或核心文件，否则通常没有意义。

最后的描述来自：使用HotSpot VM的Java SE 6故障排除指南

以下是有关线程转储的更多链接：

线程如何工作

如何分析线程转储

Java线程转储

Java VM线程

Stackoverflow问题：如何映射线程