Java tutorial index  Java 5 profiling (introduction)  ThreadMXBean

Search this site:
Threads Database Profiling Regular expressions Random numbers Compression Exceptions C Equivalents in Java

 What do you think of this article? Did it help you? Found a mistake? Feedback and suggestions here

Using the Java 5 profiling facilities
for servlet and server profiling

A significant enhancement in Java 5, which has received surprisingly little attention in the Java programming literature, was the introduction of various profiling facilities directly in Java. Since Java 5 it has been possible to perform various profiling tasks directly from Java, without having to resort to native code. An upshot of this is that it is much easier and safer to embed profiling facilities in a live environment. This article will be geared slightly towards profiling in a Servlet environment, although much of what we discuss will be applicable to server (and indeed client) profiling generally.

To start with it's important to note that the profiling techniques we'll be discussing here don't involve a simple plug-in-one-line-of-code-and-go. Java 5 provides you with the core routines to get profiling data out of the JVM, but you'll generally need to wrap some code around it for this information to be useful. But in a sense that's the whole point: you can tailor your profiling code to do exactly what you need for your particular application. And it turns out that the code required isn't generally too long or complicated.

Introduction to thread profiling

We'll be looking specifically at thread profiling: that is, taking a measure of what proportion of time (and/or CPU) threads are spending in different parts of your code1. As we develop our profiling code, some questions we'll need to consider include:

  • what tradeoff do we want to make between accuracy of the profile and impact that profiling has on the server or application?
  • do we speficially care about measuring which portions of code are specifically using CPU, or do we simply want a measure of where threads are spending time (even if this is actually doing non-CPU intensive work such as performing IO)?
  • what granularity or grouping of measurements will be most useful to us? Do we want to go down to the level of the individual line, or do we only care which methods occupy more thread time? When method A calls method B, how do we decide whether to count this as time spent inside method A, B or both?
  • are there cases that we want to exclude from our profiling data? (e.g. if we know that such-and-such a class or thread is uninteresting, perhaps we don't want to count it.)

On the next page, we'll begin looking at some basic thread profiling methodology.

1. Actually, we could also look at other things such as what proprtion of time they're spending in different states (running, waiting for IO etc).

Written by Neil Coffey. Copyright © Javamex UK 2008. All rights reserved.