7

We saw a high CPU consumption issue in our production environment recently, and saw something strange while debugging the same. When I did a "top -H" to see the CPU stats per thread ID, I found a thread X consuming high CPU. When I took the thread dumps, I saw that this thread X was in BLOCKED state. What does this mean, can a thread which is in BLOCKED state consume high CPU ? I think this might be trivial question but I am a novice in debugging Performance issues and JVM, and not sure what I might be missing here.

piyugupt
  • 404
  • 2
  • 5
  • 14
  • 1
    You’re only taking a snapshot. That doesn’t prove that the thread is in the `BLOCKED` state throughout the entire time. Depending on the implementation, it might also be possible that the thread can consume CPU cycles in an unsuccessful attempt to leave the `BLOCKED` state. – Holger Mar 08 '17 at 17:20

2 Answers2

7

Entering and exiting a BLOCKED state can be expensive. If you are BLOCKED for even a little while this is not a problem, but if you are blocking briefly in a busy loop, your thread can appear blocked but in reality burning CPU.

I would look for multiple threads repeatedly competing on a shared resources which are entering BLOCKED very briefly.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
4

@Peter has already mentioned good point about busy loop (which could be JVM internal adaptive optimization of spin locks in case of synchronization or busy loop created by application itself on some condition) which can burn CPU. There is another indirect way in which the CPU can go very high because of thread blocking. Typically in a web server if lots of threads are in blocked state ( not because of synchronization lock related blocking but say waiting for IO from a back-end datastore) then it may put lots of pressure on JVM garbage collection. These worker threads are supposed to finish their work quickly so that all the objects created by them on heap is quickly de-referenced and garbage collected. If lots of threads are in this state then the garbage collection threads have to work overtime and they may end up taking lots of CPU.

Shailendra
  • 8,874
  • 2
  • 28
  • 37