Back in my consulting days, I worked with a lot of guys who interviewed a lot. Once day this guy was telling of how he aced four rounds of interviewing to finally lose out because he knew nothing about Java threads.

It's possible to have a lucrative career in Java without ever dealing with threads. As long as you know how to use static and instance variables, the Java and J2EE APIs are pretty safe. But when you do have threading problems, it's a skill that you'll need to learn.

One way I experienced this wasn't in writing multi-Threaded apps, but in using third party frameworks and toolkits in my j2ee apps. Since everything goes into the ear, I'm redeploying to make changes. When I redeploy, the app server stops the application and then restarts it. Some thread based apps don't like being stopped properly. And of course it's a pain to track down the offending threads. So my app servers wouldn't shut down properly because of dangling threads.

A co-worker of mine recommended the very blandly named "StackTrace" tool from "Troubleshooting Tools For Java^TM" (no doubt named by the same team that came up with "Microsoft Office"). This tool is pretty useful for getting the thread dump of existing java processes. It's not OS, but you can get a free eval and can run it directly from their web site using their web start link.

After firing up this tool, it became pretty clear who the offending threads were and it was easy to patch them up. My particular problem was caused because the application was launching its own threads and setting them as non-daemon. This means the the jvm would wait for them to finish before exiting out. Usually, in a j2ee app, all launched threads (if you really must) should be set as daemon so if an admin tries to shut down the app server process, everything closes down cleanly.