Permalink

VisualVM for Java Development

May 09, 2011

I'm continually surprised to see so many Java developers unaware of, or just unwilling to use, the many tools available to them.

When I was a Windows programmer, my group was steadfast on running and testing with the debug version of the Windows kernel before releasing any software. Doing so seemed to always reveal many critical issues, such as memory leaks and potential misuse of Windows API calls. One of the strengths of being a Windows developer has been Microsoft's support in terms of tools and online help.

However, I'm continually surprised to see so many Java developers unaware of, or just unwilling to use, the many tools available to them as well. Two of the tools that I've relied on through the years include VisualVM and VisualGC, which are now available as a standalone tool and within NetBeans and Eclipse. Although Oracle provides it as a separate download, it's included with the latest versions of the Java SE 6 JDK. Look in the bin directory of your local installation to start it in standalone mode. If for some reason you don't have it there, download it via the URL above; it's the same thing.

When started, VisualVM lists all running JVMs on a system (local and remote, if you'd like), and allows you to do the following with them:

View configuration information, such as the JVM version, application and JVM flags used at startup, libraries/JARs imported, process ID, and other system properties that the JVM is running with.
Dynamically monitor (with live updates) the Java application as it runs, including GC activity, heap allocation activity, loaded classes, and running threads.
Monitor CPU usage per thread within your application, and visually identify deadlocks, contention, and other potential locking issues.
Monitor memory usage to watch allocations in action, or take heap dumps at specific moments of time and then compare them to locate potential memory leaks.
Profile your application to identify the largest consumers of memory and CPU within your application, to help you locate hot spots for further debugging and optimizations.
Are you experiencing JVM shutdowns, crashes, or core dumps? You can use VisualVM to analyze the output of the core dump or JVM shutdown to help determine what lead up to it.

Getting Started

Before you begin, I strongly urge you to look at the list of available plugins, and at least install the VisualGC plugin. This tool gives you incredibly detailed insight into what's happening within the garbage collector (GC) and your application's heap usage. GC can be a source of huge performance loss, latency issues, and overall unpredictable behavior if your application has memory-related problems, or is in need of tuning.

To install a plugin from VisualVM Plugins Center follow these steps:

Choose the VisualVM "Tools" menu, and select the "Plugins" menu option
Click the Available Plugins tab and select the plugin you want to install
Click the Install button

To begin debugging with VisualVM, simply start your Java application, and then run "visualvm" from the command line. Make sure your JDK bin directory is either the current directory or in the path. Once VisualVM starts, a list of local Java VM processes will be listed in the upper left of the display under the header "Local" (see the figure below).

You can also connect and monitor remote applications. To do so, ensure that 'stated' is running on the remote host, then start the application you want to monitor there (the order doesn't matter). Within VisualVM, to explicitly add the remote host, select the Plugins option within the Tools menu, and enter the host information (name or IP address, and label). After the connection is made (check for local firewall issues or typos if it fails), you should see a list of Java processes running on the remote host under the "Remote" header (see the figure above).

You can begin with the dynamic, live-updating monitor screen for your application (see the figure below). This screen provides a cursory overview of overall CPU usage, garbage collection (GC) activity, heap usage, classes loaded and instantiated, and threads that are active.

This is only an overview; to get to the Motts, you need to click on the tabs along the top labeled Threads, Sampler, Provider, and VisualGC.

Inspecting Threads

VisualVM allows you to watch the execution of your application's threads (as well as the JVM's threads) dynamically as the application runs. The result is an easy-to-read, color-coded list of threads that updates as time passes and thread states change (see the figure below). By watching thread states, you can visually note threads that are blocking on events, or objects/locks shared with other threads. This may be normal behavior, or it may yield surprising behavior that you weren't able to capture in any other way. For instance, I've been able to identify unwanted thrashing between threads, needless blocking, multiple threads that were acting as one (sequentially) due to improper synchronization, and thread deadlocks (including the threads deadlocked and the object(s) they were each locked on and waiting for).

You can also create textual thread dumps as your process runs, to create a record of thread activity you can inspect later. I've incorporated these thread dumps into unit tests to ensure my concurrent code is working as designed — something that's hard to prove otherwise (see the figure below).

By using VisualVM as a test tool, as well as a post-bug debugging tool, I've been able to eliminate bugs before they hit production, find them quickly when they do slip by, and then create proactive tests for the future to prevent system problems.

Inspecting the Heap and Memory Usage

So Java eliminates all your memory worries, right? Wrong. To draw an analogy to exercise, most amateur runners try to take their mind off how they feel while in a race. However, when asked about this, Bill Rodgers (four-time winner of the Boston Marathon) said that's *all* he thinks about when he races. Likewise, although Java provides automatic memory management, you should focus more than ever on memory usage, and its affects on the Java GC and runtime.

Fortunately, VisualVM provides plenty of help here. You can watch as objects are created and collected dynamically as your application executes, create snapshots of the Java heap in time and then compare them later, or create heap dumps that you can sort and inspect right down to the root objects within the heap. This allows you to locate pools of objects that potentially grow out of control, the inefficient use of resources (such as IO-related objects, files, and so on), and inefficient maps of data (i.e. those that use and continually create thousands of String objects as a result).

You can create dumps of the Java heap and sort by object type (class), the total number of objects for a specific class, the largest objects, and so on. Further, you can inspect each object and drill down to find the reference(s) to it in case you've identified a memory leak. This can sometimes be a tedious task, but I've found it necessary on many occasions, and I've been grateful VisualVM gives me the ability to get to this level of detail (see the figure below).

Application Profiling

I try to teach new programmers the importance of code profiling under various test conditions. These include idle tests, stress tests, low-memory tests, and everything in between. The result is a list of objects and methods called during your tests, the total number of times each method was called, the total time spent within the sum of those methods, and which methods took the longest to execute alone as well as in total. This is valuable information as it shows you which methods may need to be optimized, tuned, or just rewritten (see the example below).

Remember that over-optimization can lead to needless bugs and overall wasted effort. However, a quick perusal of the VisualVM profile output can pinpoint potential trouble, and outstanding performance issues, with little time or effort spent.

Using VisualGC

The VisualGC plugin for VisualVM can be a valuable tool to some, but may be overwhelming and useless to others. If your software is sensitive to performance and latency issues, then you're probably interested in what goes on inside the Java GC. VisualGC provides graphs (and the documentation explains all of them here is.gd/J1Nifa).

In summary, useful information to watch includes the size ratio between eden space (including survivor spaces S0 and S1) and the old generation (where young and older objects reside, respectively), the overall time spent collecting, and objects that get unloaded.

For instance, if objects get allocated directly within the old generation, it could indicate that your application creates very large objects that could be better broken apart. Also, excessive class unloading indicates your application is getting close to an out-of-memory situation where the JVM is unloading loaded (and compiled) class information to make room. Not only is this a waste of processing time alone, it means those classes may need to be loaded and compiled again in the future.

However, GC tuning is a skill acquired through research and experience. If you're new to this, make sure you use VisualVM in conjunction with other resources on Java GC before you spend too much effort on it.

Happy coding (and debugging)!
—EJB

News

Hosted TFS Server 2012 From Dynamsoft
Forget Cross Platform, Try Massively Cross Platform
Windows Phone 8 Developer Platform Is Here
Zend To Support Mobile First, Cloud First Development

Commentary

Toyota's Kanban Is Still Driving Agile
Splunk Enterprise 5 Arrives
Big Data Was A Data Play, Now It's A Developer Play
Creating and Using Libraries with OpenACC

Most Popular
On the Web

On the Web

Cloud Connect 2012 Speaker List: Mat Ellis Founder and CEO, Cloudability
Real Bonding With Family Around the TV Via Skype
NIST, DHS trying to tame cyber workforce definitions
Automated EMR Search Speeds ED Evaluations

Slideshow
Video

Slideshow

Jolt Awards: Utilities
Dr. Dobb's 2012 Salary Survey

Eric Bruno

Dr. Dobb's Bloggers