Using VisualVm to find a thread leak

A leak is when a application does not release references to a thread object properly. Due to this some Threads do not get garbage collected and the number of unused threads grow with time. Thread leak can often cause serious issues on a Java application since over a period of time too many threads will be created but not released and may cause applications to respond slow or hang.

In this article I am going to show how to perform a routine inspection of an application to find a thread leak. The first thing we will need is some sort of tool that could help us monitor the virtual machine of the running application.  There is a very widely used tool, called VisualVm. It comes with the JDK but also can be downloaded separately in any OS.


Java visual vm is a profiling tool that comes with the jdk and can be used to monitor your running applications. But in order to be able to connect to your app using visualVm, you will have to include a few parameters to your start script.

java

-Dcom.sun.management.jmxremote 

-Dcom.sun.management.jmxremote.port=8333 

-Dcom.sun.management.jmxremote.local.only=false 

-Dcom.sun.management.jmxremote.authenticate=false 

-Dcom.sun.management.jmxremote.ssl=false 

-jar myApp.jar

So if the app is configured and running, all you have to do is use visualVm to remotely connect to the correct host and port.

Once you connect to your application via visualVm, you can browse the diferent tabs and look for relevant information related to the VM and the threads. It will be very useful to also install a plugin for visual vm, called thread inspector which will allow you to examine in depth the running threads. You will be able to find the plugin in Tools>Plugins>Search for Thread Inspector

When there is a thread leak, often we will see an unusual large amounts one same type of thread visualVm's threads tab. If we double click in any of those threads, the plugin will show us more details about the class creating that thread.

Go to your source codes and place a break point in the class constructor.

Now run your debugger in one of your acceptance tests and observe. The frames tab will highlight a bit brighter the methods in your source codes that are creating the thread.

Hopefully the debugger will help you pinpoint the cause of the issue so you can fix it.
In the given example, the cause of this leak was that a Jersey DI configured to create some instances of a pool per request and this was consuming the resources. The solution is either to make that injection Singleton or not do it at all if it is not needed(which hapen to be the case).

Finally, you could run visualVm again in your local running app to verify that there is no leakage before release. Running the acceptance test is probably not enough because you want to see if the  leakage is there, so best is to run the app in a local or test environment.

For further reading and more detailed usage instructions see:

https://visualvm.java.net/gettingstarted.html

Helping methods indentify their calling threads with ThreadLocal class

In multi threaded applications in occasions we want to identify the thread that called certain method.
We could pass some additional parameter for that purpose to the method we are calling, but that wouldn't be very elegant.
The class ThreadLocal allows us to manage an object within the current Thread scope.

Let's have a look at an example...

The class below called sample Thread, uses some service and that service has interest in knowing who called it.
So What we do is create some context with come kind of unique identifier(e.g ThreadName,UUID...) and then we give that context to the class ThreadLocal to handle it(We will create an special wrapper class to hold ThreadLocal).

 public class SampleThread extends Thread {  
   @Override  
   public void run() {  
     ThreadContext threadContext = new ThreadContext();  
     threadContext.setId(getName());  
     ContextManager.set(threadContext);  
     new BussinessService().bussinessMethod();  
     ContextManager.unset();  
   }  
 }  

The context could be anything we want, but in this example I will be using the Thread name.

 public class ThreadContext {  
   private String id = null;  
   public String getId() {  
     return id;  
   }  
   public void setId(String id) {  
     this.id = id;  
   }  
 }  

The class ContextManager will act as a container that will allow us to access and modify the context of the Thread.

 public class ContextManager {  
   public static final ThreadLocal threadLocal = new ThreadLocal();  
   public static void set(ThreadContext context) {  
     threadLocal.set(context);  
   }  
   public static void unset() {  
     threadLocal.remove();  
   }  
   public static ThreadContext get() {  
     return (ThreadContext) threadLocal.get();  
   }  
 }  

With this infrastructure in place, the Service can identify the calling thread.

 public class BussinessService {  
     public void bussinessMethod() {  
       ThreadContext threadContext = ContextManager.get();  
       System.out.println(threadContext.getId());  
     }  
 }  

Finally just to demo the concept we could just create a couple of Threads and run them to see how they are identified by the services via their context.

 public class Main {  
   public static void main(String args[]) {  
     SampleThread threadOne = new SampleThread();  
     threadOne.start();  
     SampleThread threadTwo = new SampleThread();  
     threadTwo.start();  
   }  
 }