This was a simple lite-weighted tracer who monitors deadlock and exit from the program if any deadlock detected. It also prints various states of a thread. But since it is again a thread so it prints states whenever it gets proceed by CPU. Hence you miss all states of thread. YourKit Jprofiler solved this problem.
I commented deadlock detection code from tracer and run program through YourKit Profiler. Now see how this tool informed me about dead lock and various states of all running threads & CPU.
As you can see in the last, both threads A & B are blocked. YourKit popped up a deadlock message and gave me following information about deadlock.
It is clearly mentioned in above screen shot that which thread waiting for a lock locked by another thread. It’ll help you to debug your code. Above 2 lines explains, that thread A is taking a lock on some Integer object while thread B is taking lock on DeadLockDemo object. I’ll suggest you to override toString() of class you are locking on. It’l help you to find out exact position where a thread is locking on.
- If you are running your program through YourKit, it takes more CPU.
- YourKit detects deadlock after a while than Tracer. If tracer detects deadlock and exit from the program, yourkit will never know whether deadlock was occurred.
If you go through CPU stats, you’ll know that Thread.activeCount() & Thread.getState() takes most CPU. These method are called by tracer to know current state of thread and print it.
I dint call tracer this time and observed that CPU consumption clashed down. Dadlock was still there in the program.
Now you will not notice any Hot Spot. See how CPU consumption slashed down.
And here how many threads are running after skipping tracer.