Question

我的应用正在使用Gson 2.2将POJOs转换为JSON。当我进行负载测试时，我偶然发现Gson构造函数中阻塞了很多线程：

"http-apr-28201-exec-28" #370 daemon prio=5 os_prio=0 tid=0x0000000001ee7800 nid=0x62cb waiting for monitor entry [0x00007fe64df9a000]
    java.lang.Thread.State: BLOCKED (on object monitor)
    at com.google.gson.Gson.<init>(Gson.java:200)
    at com.google.gson.Gson.<init>(Gson.java:179)

线程转储不显示任何持有[0x00007fe64df9a000] monitor的线程。 如何找出谁拥有它？

Gson代码at line 200看起来非常无辜：

// built-in type adapters that cannot be overridden
factories.add(TypeAdapters.STRING_FACTORY);
factories.add(TypeAdapters.INTEGER_FACTORY);

我在JRE 1.8.0_91

上使用Linux

Answer 1

tl; dr 我认为您正在遇到与GC相关的行为，其中线程处于等待状态以允许垃圾收集。

我没有全部真相，但我希望提供一些见解。

第一个要认识到的是，括号中的数字[0x00007fe64df9a000]不是监视器的地址。对于转储中的所有线程，即使是处于运行状态的线程，也可以看到括号中的数字。这个数字也没有变化。我的测试转储示例：

main" #1 prio=5 os_prio=0 tid=0x00007fe27c009000 nid=0x27e5c runnable [0x00007fe283bc2000]
   java.lang.Thread.State: RUNNABLE
        at Foo.main(Foo.java:12)

我不确定数字的含义，但是this page暗示它是：

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

虽然说明的跟踪格式有点不同所以我不确定我是否正确。

当显示实际监视器的地址时转储的显示方式：

"qtp48612937-70" #70 prio=5 os_prio=0 tid=0x00007fbb845b4800 nid=0x133c waiting for monitor entry [0x00007fbad69e8000]
   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)   <--- Line of l.add()

虽然与OP的跟踪不完全相同，但如果不涉及同步，则有一个线程waiting on condition很有意思。我用较小的堆更频繁地体验它，表明它可能与GC有关。

另一种可能是包含同步的代码已经过JIT编译，这会阻止您查看监视器的实际地址。但是，我认为这不太可能，因为您在ArrayList.add上体验过它。如果是这种情况，我知道无法找到显示器的实际持有人。

Answer 2

如果您没有 GC 问题，那么实际上可能有某个线程已获取对象上的锁，而卡住的线程正在等待获取同一对象上的锁。弄清楚的方法是寻找

- waiting to lock <some_hex_address> (a <java_class>)

例子是

- waiting to lock <0x00000000f139bb98> (a java.util.concurrent.ConcurrentHashMap)

在显示 waiting for monitor entry 的条目的线程转储中。找到它后，您可以搜索已经获得地址为 <some_hex_address> 的对象的锁的线程，示例中看起来像这样 -

- locked <0x00000000f139bb98> (a java.util.concurrent.ConcurrentHashMap)

现在您可以查看该线程的堆栈跟踪，以确定哪一行代码已获取它。

如何找出哪个线程容纳监视器？

2 个答案: