2

我一直在使用我们系统的线程转储来解决各种问题，我注意到的一件事是，无论好坏，我们在线程转储中有很多这样的事情：

"TP-Processor59" - Thread t@915
   java.lang.Thread.State: RUNNABLE
    at java.lang.Class.getEnclosingMethod0(Native Method)
    at java.lang.Class.getEnclosingMethodInfo(Class.java:929)
    at java.lang.Class.getEnclosingClass(Class.java:1081)
    at java.lang.Class.getSimpleBinaryName(Class.java:1220)
    at java.lang.Class.getSimpleName(Class.java:1112)

现在，我们确实对我们的配置系统所依赖的 getSimpleName() 进行了很多调用。但我的问题是为什么他们总是陷入这种特殊的方法？这是一个 Windows JVM，1.6.0_29，64 位。

我觉得 getSimpleName() 通常应该是一个非常快速的调用。这很可能是 getEnclosureMethod0() 在某种程度上非常慢，还是该本机方法可能会以某种方式阻塞某些东西（当然，这不会出现在 JVM 线程转储中）？

4

1 回答 1

0

今天我们遇到了一个无限循环的问题。在对问题进行故障排除时，我们看到大多数情况下线程堆栈都以这个方法调用结束。

当我们发现问题时，它与 getEnclosureMethod0 无关，而是更高级别的无限循环。尽管在循环中做了一些相当昂贵的事情，但 getEnclosureMethod0 调用似乎是迄今为止完成的最慢的事情。

我的结论是 getEnclosureMethod0 有时会非常慢，即使它没有阻塞（在我们的案例中它没有阻塞 AFAIK）。

于 2012-11-20T14:58:05.373 回答