Archive | May 2013

Analyzing deadlocks in Java applications with thread dumps

Recently I was given the task to analyze a problem with some multi-threaded Java application that got stuck if you run that application within a batch script again and again. On some invocations the application just did nothing (no CPU utilization, no exceptions). So how to analyze what the application is doing right now?
In cases like this, jstack enables you to create a thread dump for a running java application and gives a look inside. First you have to look up the id of the running application with jps and then provide its PID as the first argument to jstack:

884 org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar
2344 Jps
5188 ThreadA

C:\Users>jstack 5188 > stack.txt

As I opened the text file stack.txt, I found something like the following (reconstructed here with a simple example):

	- waiting to lock <0x00000000ec102070> (a java.lang.Object)
	- waiting to lock <0x00000000ec103b68> (a java.lang.Object)
	- locked <0x00000000ec102070> (a java.lang.Object)
	- waiting to lock <0x00000000ec102070> (a java.lang.Object)
	- locked <0x00000000ec103b68> (a java.lang.Object)

As you can see, Thread-18 is waiting to lock 0x00000000ec102070, which is already locked by Thread-0. Thread-0 on the other hand is waiting to lock 0x00000000ec103b68, which again is already locked (by Thread-15). And Thread-15 is also waiting to lock 0x00000000ec102070. Thus, we have a classic deadlock situation.

Using interfaces to subdivide enums into smaller semantic units

Recently I stumbled upon a huge enum with a lot of values. While working with this enum I realized, that in some situations you only needed a few enum values while in other situations you needed other values. This clearly indicated that the enum subsumed values from different semantic fields.
But how can you subdivide such a enum into separate units?
A first thought was to establish some kind of inheritance. But Java does not support inheritance for enums. The reason why is shown in the following example:

 enum First {One, Two}   
 enum Second extends First {Three, Four}   

 First a = Second.Four;   // clearly illegal 

But instead of using inheritance one could create separate enums and define a common interface for them:

interface Os {

enum WindowsOs implements Os {
enum UnixOs implements Os {

Now you can write methods, that only accept operating systems of type WindowsOs or UnixOs or any Os:

	private boolean isWindowsOs(Os os) {
		return (os instanceof WindowsOs);

	private void rebootAfterInstallation(WindowsOs windowsOs) {

Even if you want to refine the UnixOs enum, you could create one more interface (e.g. UnixOs that extends Os) and create enums like LinuxOs and SolarisOs that implement the new interface:

interface UnixOs extends Os {

enum LinuxOs implements UnixOs {