Portal Postmortem
Using Java Thread Dumps to Diagnose Application Failures
Joseph Dane
University of Hawaii
2005 University of Hawaii
Overview
Motivation
Concepts
Examples
Resources
Why When Who
Why: because you've got a flaky application, and you don't know the cause
This is your only choice (except, perhaps …)
When: now. Or possibly later.
You do need a running JVM
If you've got a dead JVM, you might have a core
Who: java developers
requires some familiarity with java
threading, locks, etc. in particular
but, no guru level knowledge required
General Principles
The goal is not to solve problems, but to add to the pool of knowledge about the problem
Some sysadmin skills required/useful
Finding PIDs, sending signals, munging text
For some problems (e.g. G.C.), this will all be a complete waste of time
For other (fairly rare) problems, this will immediately point out the problem, e.g. deadlocks
"Postmortem", in that we can (must, in fact) wait until a problem presents
What can we learn
Resource contention
network (database, RSS feed, etc.)
java locks
CPU
Not so good for
memory leaks
Terminology
"thread" -- a single execution path through a program
"method" -- a java function call
"stack" -- the context of the currently called methods/functions
"frame" -- a single method call, or a single line in a stack
"up/down" -- "up" is toward the TOS, "down" is toward the start of the program
"TOS" -- "top of stack", or the currently executing method

下一页