我认为你遇到了与GC相关的行为,其中线程被置于等待状态以允许垃圾收集。简而言之。
I do not have the whole truth but I hope to provide some pieces of insight.
首先需要认识到的是,方括号中的数字“[0x00007fe64df9a000]”并不是显示器的地址。在转储中,所有线程都可以看到方括号中的数字,即使是运行状态的线程也一样。这个数字也不会改变。以下是我测试转储的示例:
main"
java.lang.Thread.State: RUNNABLE
at Foo.main(Foo.java:12)
我不确定这个数字的含义,但
this page表明它是Java VM内部线程结构的指针。除非你正在调试实时Java VM或核心文件,否则通常没有兴趣。尽管所解释的跟踪格式有点不同,所以我不确定我是否正确。当显示实际监视器的地址时,转储的方式如下:
"qtp48612937-70"
java.lang.Thread.State: BLOCKED (on object monitor)
at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:233)
- waiting to lock <0x00000005b8d68e90> (a java.lang.Object)
请注意跟踪中的
waiting to lock
行,以及监视器的地址与括号中的数字不同。
我们无法看到涉及的监视器地址表明该监视器仅存在于本地代码中。
其次,所涉及的Gson代码根本没有包含任何同步。 该代码只是向一个
ArrayList
添加一个元素(假设没有进行字节码操作并且在低级别上没有做任何可疑的事情)。 也就是说,在此调用时看到线程等待标准同步监视器是没有意义的。
我发现
some,
indications,当有大量GC正在进行时,线程可能会显示为等待监视器条目。
我编写了一个简单的测试程序,尝试通过向数组列表中添加大量元素来重现它:
List<String> l = new ArrayList<>();
while (true) {
for (int i = 0; i < 100_100; i++) {
l.add("" + i);
}
l = new ArrayList<>();
}
然后我对这个程序进行了线程转储。偶尔我遇到了以下跟踪:
"main" #1 prio=5 os_prio=0 tid=0x00007f35a8009000 nid=0x12448 waiting on condition [0x00007f35ac335000]
java.lang.Thread.State: RUNNABLE
at Foo.main(Foo.java:10) <
虽然与OP的跟踪不完全相同,但有趣的是,在没有涉及同步的情况下,有一个线程“等待条件”。我发现在堆较小的情况下更频繁出现,这表明它可能与GC有关。另一个可能性是包含同步的代码已被JIT编译,这会阻止您看到监视器的实际地址。但是,我认为这种可能性较小,因为您在ArrayList.add上遇到了这种情况。如果是这种情况,我不知道如何找到监视器的实际持有者。
factories.add
是同步的或者持有一个监视器,或者它调用了其他持有监视器的代码。这可能会给你一个开始查找的地方。我需要知道factories
的类型并且可能需要它的代码才能提供更详细的建议。 - Warren Dew