1

I have dump from JProfiler, where I was looking on performance and found blocked threads during test run. It looks like this:

jprofiler blocked thread

Accordind to question here Understanding the Reference Handler thread, the lock on java.lang.ref.Reference$Lock would means object is locked for running finalizers for GC. Is this assumption correct? Also why in second row, it states, this lock is owned by my other own thread? Is that possible?

Does have any knowledge what happening here?

JIV
  • 813
  • 2
  • 12
  • 30
  • Actually, this lock should never be held by application threads. – Holger May 22 '19 at 14:39
  • Or well, perhaps it can, when garbage collection is performed synchronously within the application thread. – Holger May 22 '19 at 14:48
  • Yeah, it might be like we run finalizers manually from client code, but I think we dont. Also it might be error on Jprofiler part. ¯\\_(ツ)_/¯ – JIV May 23 '19 at 06:54
  • Not running finalizers, but rather the *marking phase* performed within the application thread. Whenever the garbage collector encounters a `Reference` object, which doesn’t have to be a finalizable object, it could also be a weak or soft reference, it may hand it over to the reference handler thread, which implies acquiring the lock you see in the dump, *for a very short time*. Then, the reference handler thread will enqueue discovered reference objects and *then* one of the dedicated finalizer threads will dequeue the next finalizer reference, if there is one, and execute the finalize method – Holger May 23 '19 at 10:03

0 Answers0