profilers have filter sets and other options that can be tweaked to show or hide these blocking
Alternately, it is usually more fruitful to examine the execution patterns of threads rather than
the amount of time a profiler attributes to the blocking method itself. Figure 3-5 shows such
a thread display from the Oracle Solaris Studio profiling tool.
Figure 3-5. A thread timeline profile
Each horizontal area here is a different thread (so there are two threads in the figure: thread
1.3 and thread 1.2). The colored (or different grayscale) bars represent execution of different
methods; blank areas represent places where the thread is not executing. At a high level, ob-
serve that thread 1.2 executed a lot of code and then waited for thread 1.3 to do something;
thread 1.3 then waited a bit of time for thread 1.2 to do something else, and so on. Diving in-
to those areas with the tool lets us learn how those threads are interacting with each other.
Notice too that there are blank areas where no thread appears to be executing. The image
shows only two of many threads in the application, so it is possible that these threads are
waiting for one of those other threads to do something, or the thread could be executing a
blocking read() (or similar) call.
1. Threads that are blocked may or may not be a source of a performance issue; it is
necessary to examine why they are blocked.
2. Blocked threads can be identified by the method that is blocking, or by a timeline
analysis of the thread.