Multithreaded Applications Without Fear and Deadlocks
Resolve Thread Issues In A Fraction Of The Time Using Enerjy Thread Profiler
This article is geared towards developers who are interested in developing multithreaded applications with Java. The author explains the basic terminology used in a multithreaded environment and how thread development can be greatly enhanced and simplified with Enerjy Thread Profiler.
Introduction
After six months of development, and a deadline looming, your Swing application is still not ready for prime time. You have been diligent about unit testing and it has met all functional requirements, yet there are some issues you have trouble pinning down. For one, certain parts of the application remain sluggish even after all optimization. You have spun off the Network I/O onto a different thread. QA has reported numerous lock-ups, but are not able to reproduce them with any consistency.
Knowing that even one-second delays can turn users off and can cause confusion, you attempt to re-evaluate the application. Have you spun out too many threads? Are your thread blocking times too long? Would you get better performance from a thread pool?
Multithreaded applications offer a better user experience, generally run faster, and allow better encapsulation. Threads make all this possible by making a single Java Virtual Machine (JVM) look like many machines, running at the same time. Interactive applications benefit from this greatly because they can continue to be responsive to the user even when part of the application is performing an intensive operation. Furthermore, in an age when multi-processor machines are common, and dual core chips are just around the corner, single-threaded applications will not be able to take advantage of the added horsepower.
Unfortunately, threading dramatically increases the complexity of an application. Since all threads inside the same JVM share the same address space, it must be ensured that one thread does not impinge on the work of another thread. When two threads try to access the same resource at the same time, it results in a 'Race Condition', the nastiest form of which is the deadlock, usually grinding your application to a halt. Developers often grapple with when to use synchronized methods and blocks, and find themselves with race conditions or even deadlocked applications.
Furthermore, beyond the API and Javadoc, Java does little to help the developer with thread issues. So they are often compelled to sort the entanglement (of threads) by inserting logging statements or calls to System.out() when a thread enters a particular state.
In such situations, a thread profiler can prove to be of immense help. Introducing Enerjy Thread Profiler
Enerjy Thread Profiler monitors the program as it runs and collects detailed information about all thread-related events, such as entering a synchronized method or waiting on an object. In addition to immediately highlighting thread deadlocks, it gives you an easy-to-understand, graphical view of the threads in your program, showing where they were blocked and which objects they were blocking on. This gives you the information required to diagnose thread-related bugs and performance problems. Best of all, Enerjy Thread Profiler keeps you inside the Integrated Development Environment (IDE), linked directly to the source code. There are no pop-up or separate shell-out processes; all pieces of the tool are designed to look like a natural extension to your IDE. Configuration
The profiler can be launched in a few simple steps. If the application can be compiled and executed in the IDE, it is ready to be profiled. Enerjy Thread Profiler uses the existing IDE launch configuration; there are no separate configurations or wizards to deal with. Go to the Run menu and select Profile Configuration, Thread, and the application you wish to profile (Figure 1).
Figure 1: Launching Enerjy Thread Profiler Within Your IDE
As the application starts up the Enerjy Thread Profiler Status view should appear. This view acts as the control centre for the profiler while the application runs (Figure 2). It provides a standard heap graph to help determine the status of the application, and a quick view of the threads running in the JVM. In the upper right hand corner of the status view, you will find pause, play, and stop buttons giving you complete control over all the threads running in the application. With the heap view and graphical status of all threads running in clear view you might be content to start your analysis, but click the Take Snapshot button and watch the tool go to work.
Figure 2: The Status View
Terminology
Each Java object in memory has a monitor and only one thread at a time has access to that monitor. When more than one thread wants access to an object's monitor, they must wait until the last thread releases that monitor. Thread objects themselves do not implement or control monitors, rather every Java object has its own independent one. When analyzing thread usage in an application, sometimes it is best to look at which threads are spending the most time waiting for a monitor. Another approach is to look at the picture in terms of monitors, that is, which and how many threads are attached to each monitor. Enerjy Thread Profiler satisfies both. The Threads over Monitors view helps you to determine quickly which threads in the application are spending too much time acquiring a monitor or waiting for a monitor to be notified. The Monitors over Threads view enables you to see which monitors are highly contended within the application.
Enerjy Thread Profiler displays the chronology of each thread or monitor as a timeline in the Graph pane (Figure 3). You are given control to zoom in and out of the graph by the buttons in the upper left hand corner. Beyond this, you can click and drag across the graph to select a moment in time to inspect. If you require further detail about a thread, click the "plus" sign next to the thread and each corresponding monitor will be displayed beneath it.
Figure 3: The Graph Pane
As you can see, the threads in the table, shown in Figure 3, have exciting names like Thread-3:7? Stop neglecting your threads and give them a name! A quick call to super("HappyNamedThread"); in the object's constructor will not only make this log more meaningful, but will also keep your code more reusable.
The timeline for each thread (or monitor) has five possible states (see Figure 4):
- Deadlock (Dark blue): two or more threads are waiting indefinitely for an event that can only be caused by one of the waiting processes
- Hold/Locked (Light blue): thread successfully acquired a lock on a monitor
- Running (Green): the threads code is being actively executed by a processor and will run until it is swapped out, becomes blocked, is told to sleep, or finishes
- Block (Red): the thread is being blocked from another monitor and must wait until the resource is released before it can proceed
- Wait (Yellow): thread called wait() on a monitor
Figure 4: Thread States
Beneath the Graph Pane, Enerjy Thread Profiler gives you a tabular analysis of every thread or monitor that was running when your snapshot was taken. Want to know the total amount of time a thread spent waiting to acquire locks or waiting for notification? How about number of objects locked by the thread? All of the data you will need is here, and if it is not, right click on the table and you can add the column you are looking for.
Each snapshot you take is stored in the project directory for future reference. Enerjy Thread Profiler also gives you the ability to save all tabular data to a comma or tab delimited file for importing into a spreadsheet or reporting tool.
To quickly diagnose a potential problem double click on a bar on the Graph Pane (Figure 3). This will immediately bring up the detailed Event Log at exactly the point in the application where the event occurred. The Event Log will tell you when a Monitor is entered and exited, and even when a thread is attempting to acquire a lock. Right click on Event in the event log and select Goto Source. You are taken directly into the source code where the event occurred.
Think back to the last time you had a deadlock issue to solve! Fixing the problem may not have taken that long, but how much time did you spend trying to track it down? Using Enerjy Thread Profiler, once the deadlock has occurred and been reported, you can get straight to the code in seconds!
Once you have fixed your deadlocks and the application is running, the blocking time in percentage of the threads over the lifetime of the application can be quickly determined (see Figure 5). This is useful as creating too many threads will lead to the CPU spending more time creating/controlling the threads than actually doing the work. Historically trial and error methods using java.lang.currentTimeMillis() to time the threads would give the developer the tedious task of fine-tuning the threads within the application. Once this figure exceeds 50% a lower number of threads should be contemplated for increased efficiency and throughput.
Figure 5: Determining the percentage of time threads are spending blocking resources throughout the application.
Remote Profiling
Enerjy Thread Profiler can easily be configured to communicate with profiling sessions that do not originate from within your IDE. These profiling sessions can be external processes run on the same machine, or processes launched from any network-accessible computer. To profile an external JVM simply download the Remote Profiling Module and install it on your server or other external computer. When starting the remote process you must include a one-line argument to the JVM (the IP address of the machine that is running your IDE, and a port number for a socket to communicate on). In the case of an application server this argument is passed in as a JVM Environmental Variable. Once the external application is started, the full complement of the Enerjy Thread Profiler features can be used to profile these remote applications. Conclusion
Java applications benefit from the ability to perform multiple processes at the same time, but multithreading can sometimes be difficult to implement effectively. Enerjy Thread Profiler greatly reduces this complexity by presenting thread and monitor information in a clear, concise manner. Detecting threading issues without such a tool can use up long hours of your development time, and, without blocking times or monitor information, you may end up with inaccurate and misleading data. Since the Enerjy Software tools seamlessly plug into the IDEs you use, you'll find there is little to no learning curve associated with the products. After a simple installation and a quick menu selection, you will be taking snapshots and accessing the graphical and statistical information required to solve your thread problems. IDE Support
Enerjy Thread Profiler currently supports the following IDEs:
- Eclipse (by eclipse.org), Release 2.x or 3.x
- WebSphere Studio Application Developer (by IBM), Release 5.x
- Rational Application Developer (by IBM), Release 6.x
- JBuilder (by Borland), Release 7, 8, 9 , X or JBuilder 2005
About Enerjy Software
Our Tools: Enerjy's suite of Java tools strives to provide tactical, comprehensive, andat their heartuseful solutions for the everyday Java developer. Our tools keep you inside your IDE, where you spend eight (ten?) hours a day, and get you back to your curly braces and semicolons, where the work really matters. You'll get simple-to-read tables and easily recognized graphs, and you'll always be a double-click away from your code.
Our Company: You'll find that we're a little different from other software tools companies. Instead of trying to sell you everything, an all-encompassing development solution, we're maniacally focused on giving you just the help you need, when you need it, and then getting out of your way. And we won't charge you an arm and a leg for our tools. We've built the company from the ground up with a view to keeping costs under control and passing those savings on to you.
About the Author
Brian Deeley: Brian Deeley is a Java Sales Engineer for Enerjy Software. He previously worked for GE Medical Systems in the diagnostic imaging group before joining Matrix Consultants as a Java Architect. Brian holds a bachelors degree in Engineering from the University of Massachusetts, USA. References
