0

Java's large number of threads are in a blocked state, waiting for a lock, but there is no thread to have this lock

blocked thread

[root@xxx xxx]# grep BLOCKED 11.txt -C5
    at java.lang.ref.Reference.waitForReferencePendingList(java.base@12.0.2/Native Method)
    at java.lang.ref.Reference.processPendingReferences(java.base@12.0.2/Reference.java:241)
    at java.lang.ref.Reference$ReferenceHandler.run(java.base@12.0.2/Reference.java:213)

"Finalizer" #3 daemon prio=8 os_prio=0 cpu=273.67ms elapsed=1139.36s tid=0x00007fabf2c6a000 nid=0x11 waiting for monitor entry  [0x00007fabb19fd000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at java.lang.ref.Finalizer.runFinalizer(java.base@12.0.2/Finalizer.java:70)
    - waiting to lock <0x000000048046f6f0> (a java.lang.Object)
    at java.lang.ref.Finalizer$FinalizerThread.run(java.base@12.0.2/Finalizer.java:171)

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 cpu=1.42ms elapsed=1139.36s tid=0x00007fabf2c6b000 nid=0x12 runnable  [0x0000000000000000]
--
    at java.util.concurrent.LinkedBlockingQueue.take(java.base@12.0.2/LinkedBlockingQueue.java:433)
    at com.alipay.remoting.ReconnectManager$HealConnectionRunner.run(ReconnectManager.java:144)
    at java.lang.Thread.run(java.base@12.0.2/Thread.java:835)

"Init-TX-Disruptor-0" #26 prio=5 os_prio=0 cpu=4732.71ms elapsed=1122.35s tid=0x00007fabb40c5800 nid=0x5d waiting for monitor entry  [0x00007fab939ec000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at java.lang.ref.Finalizer.<init>(java.base@12.0.2/Finalizer.java:51)
    - waiting to lock <0x000000048046f6f0> (a java.lang.Object)
    at java.lang.ref.Finalizer.register(java.base@12.0.2/Finalizer.java:66)
    at java.lang.Object.<init>(java.base@12.0.2/Object.java:50)
    at org.rocksdb.AbstractNativeReference.<init>(AbstractNativeReference.java:25)
--
    at xx.xxxx.xxx.xx.xxxx.xx.xx.onEvent(InitTxWorkHandler.java:24)
    at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:143)
    at java.lang.Thread.run(java.base@12.0.2/Thread.java:835)

"Init-TX-Disruptor-1" #27 prio=5 os_prio=0 cpu=4698.53ms elapsed=1122.35s tid=0x00007faba7b1a000 nid=0x5e waiting for monitor entry  [0x00007fab9236b000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at java.lang.ref.Finalizer.<init>(java.base@12.0.2/Finalizer.java:51)
    - waiting to lock <0x000000048046f6f0> (a java.lang.Object)
    at java.lang.ref.Finalizer.register(java.base@12.0.2/Finalizer.java:66)
    at java.lang.Object.<init>(java.base@12.0.2/Object.java:50)
    at org.rocksdb.AbstractNativeReference.<init>(AbstractNativeReference.java:25)


grep 0x000000048046f6f0 not found owns the monitor on 0x000000048046f6f0

grep 0x000000048046f6f0

The thread has been blocked for a long time, I want to know why

tom
  • 1
  • 1
  • Do you have a question? The way your post is written, it just looks like an observation. I think you want to understand the cause, in which case you need to find the thread which owns the monitor on `0x000000048046f6f0` – boneill May 05 '22 at 15:09
  • 1
    Since this is the guard to the queue populated by the garbage collector, it might be that the garbage collector is running and enqueuing finalizable objects. I don’t know if this would show up in a thread dump. Normally, enqueuing should not take much time. But when you have a “large number of threads” waiting for this specific lock, it’s an indicator that your application is excessively using finalizers. Not a good idea… – Holger May 05 '22 at 16:33
  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking. – Community May 05 '22 at 16:50
  • not found owns the monitor on 0x000000048046f6f0 – tom May 06 '22 at 03:35
  • This could be a deadlock in your application (or in rocksdb, whatever that is). – Mark Rotteveel May 06 '22 at 16:56
  • Search for the thread that's in the `runFinalizer` method. – boneill May 07 '22 at 14:35

0 Answers0