I am looking for comprehensive information on generating and interpreting thread dumps with as many examples as possible and in as many Operating systems as possible.Can somebody point me to some useful resources on the net and suggest some good books that comprehensively cover this aspect? I looked at the information on Sun's website: http://java.sun.com/developer/technicalArticles/Programming/Stacktrace/ but what I need is something beyond this. I tried searching a lot in the popular search engines but could get information that only scratches the surface. I am looking at gaining a thorough understanding of whats happenning in the system by looking at thread dunps.Most of the material I saw on the net just touches upon the deadlock issue which will be somewhat obvious from the jdk 1.4 logs.
posted 14 years ago
Can somebody please help me with some information in this front?
What kind of information are you looking for, exactly? Java stack traces won't vary by OS, per se; they'll vary by JVM version and vendor, in that the format might be different, or the specific system threads that exist will be different. You're definitely not going to find a single document that explains every possibility, and in fact, you're really not going to find anything that explains everything about all the system threads in even single Sun JVM version -- they don't generally document that stuff.
Anyway, besides what's in the article you linked to, what else are you hoping to be able to learn from a stack trace? That article covers pretty much everything useful.
I am looking for some examples and some fundamentals needed in taking a thread dump and how to diagnoise the presence of typical threading problems like:
a)Locking b)Hanging. c)Crashes (this will need a core dump). d)Race conditions. e)Busy Programs or any other possibilities.
The key things I learnt from the article are: Current Thread, Monitor States. Unfortunately when faced with such problems on production systems,I could not hit upon any scientific way of analysing the thread dumps.So I am looking for specific information as given above and also a process to be followed and conceptual knowledge for debugging production problems thru thread dumps.I know its very difficult to get black and white information but I always felt I should know more when ever faced with such problems.
You can detect problems by finding threads that indicate they're waiting on a monitor, and then looking to see if another thread is already holding that monitor. In general, those kinds of problems have to be detected by hand -- it's an unsolvable problem to find them automatically because you have to know the context and understand the code to know if there's actually a problem. In any case, Sun's stack traces all say "waiting on monitor" or "locked monitor" in the appropriate places so this information is available.
True deadlock -- where a series of threads are all waiting for resources also held by other threads in the same group, and none can proceed -- also can't be detected automatically in the general case, although for the most common cases it can be. But to recognize it by eye, you look for the same things as above, but double -- i.e., Thread 1 is holding lock A and waiting for B, and Thread 2 is holding B and waiting for A.
Race conditions leave no "trace" in s stack trace. You can't tell from a stack trace that two threads are accessing the same data in an unsynchronized way.
Beyond that, stack dumps you get from exceptions tell you where a thread was when it threw the exception; that's it, and that's about all you need. To make use of a core dump, you'd have to be debugging the JVM, and to do this with any kind of results, you'd need the exact source code of the JVM you were running -- and you'd have to understand it. Even then, you wouldn't have source for the HotSpot-generated code. If it's a JVM bug, it's a JVM bug, though, so there's little point in your trying to debug it.