The following are tips for debugging multi-threading issues.
Some of the breakpoints support the application of thread filters. A thread filter causes the breakpoint to halt execution of the debuggee only when the breakpoint is hit from within the named thread. This can be useful for controlling when the breakpoint stops your program.
An alternative to using a thread filter is to use a count filter. This simply means that you set the breakpoint to stop the debuggee up to a certain number of times. This can be used to allow the breakpoint to be hit once (or twice, or more) but thereafter it will be ignored.
To reset the breakpoint, simply change its expiration count.
Since each type of breakpoint displays a message in the Output
window whenever the breakpoint is hit, it acts similarly to a call to
println
. The breakpoint hit message will always include
the thread name or unique identifier, so you can easily see which
threads are reaching a particular location. Just set the breakpoint
suspend policy to "none" so that the impact on the thread timing in
the debuggee will be minimal. This can be especially useful if you are
debugging code that you cannot modify.
Note that some breakpoint monitors cause the debuggee to suspend momentarily, such as the expression and stack trace monitors. This will possibly affect the thread timing in the debuggee, so avoid using these monitors if the breakpoint suspend policy is "none".
To catch a thread that is changing a field of a particular object instance, you can use a special type of variable breakpoint that is set on a per-instance basis. This is done via the Variables view context menu. This breakpoint will stop whenever the field of a specific instance of a class is modified, which can be very useful if the field is changing unexpectedly.