Quick and Dirty Test for Thread Leakage in Java
Join the DZone community and get the full member experience.Join For Free
I was looking at a bit of code was leaking class loaders when deployed to tomcat - so I wanted to quick rule out that a background Thread was holding onto the loader. Pain by eye, it is quite easy with a few unix commands to process the stack trace, filter for the lines that contain the thread name, filter for just the thread names and sort:
sudo -u tomcat jstack 1853 | grep " prio=" | sed -e 's/"\(.*\)".*/\1/' | sortOnce this is done it is a simple matter to pipe the output to a file, say /tmp/before.threads, then run the deploy task a small prime number of times in order to create a clear signal, and then compare with the original thread list
[gdavison ~]$ diff /tmp/before.threads /tmp/after.threads 26a27 > RMI TCP Connection(11)-127.0.0.1 [gdavison ~]$As with any server there will be a lot going on, in this case I saw a spurious RMI thread we can probably ignore, but if there was any application specific thread leakage the problem should repeat a number of times that is cleanly divisible with the prime number you picked before, for example where the prime is three with an example issue:
[gdavison@slc01htu ~]$ diff /tmp/before.threads /tmp/after.threads 8a9,11 > Problem Thread > Problem Thread > Problem Thread 26a30 > RMI TCP Connection(11)-127.0.0.1 [gdavison ~]$
As I say quick and dirty; but might be worth writing down for later use.
Published at DZone with permission of Gerard Davison, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.