Java Reference
In-Depth Information
Blocking Methods and Thread Timelines
Figure 3-4 shows the GlassFish startup using a different instrumented profiling tool (the
NetBeans profiler). Now the execution time is dominated by the park() and parkNanos()
methods (and to a lesser extent, the read() method).
Figure 3-4. A profile with blocked methods
Those methods (and similar blocking methods) do not consume CPU time, so they are not
contributing to the overall CPU usage of the application. Their execution cannot necessarily
be optimized. Threads in the application are not spending 632 seconds executing code in the
parkNanos() method; they are spending 632 seconds waiting for something else to happen
(e.g., for another thread to call the notify() method). The same is true of the park() and
read() methods.
For that reason, most profilers will not report methods that are blocked; those threads are
shown as being idle (and in this case, NetBeans was set to explicitly include those and all
other Java-level methods). In this particular example, that is a good thing: the threads that are
parked are the threads of the Java threadpool that will execute servlet (and other) requests as
they come into the server. No such requests occur during startup, and so those threads remain
blocked, waiting for some task to execute. That is their normal state.
In other cases, you do want to see the time spent in those blocking calls. The time that a
thread spends inside the wait() method—waiting for some other thread to notify it—is a
significant determinant of the overall execution time of many applications. Most Java-based
Search WWH ::




Custom Search