Debugging multithreaded Applications with Java Debug Interface (JDI)

Debugging in a multithreaded environment is a problem for developers to get headaches. Debugging a program in the IDE by adding breakpoints often misses the execution of other threads because it stops at a breakpoint on one thread, and scheduling between threads is often unpredictable and because breakpoints affect the actual thread execution order. As a result, when debugging multithreaded routines, developers often choose to print Trace Log to help with debugging.

The problem with using Log to help debug is that developers are often unable to anticipate which key points need to be recorded, so in the process of debugging the entire program, the need to constantly add Log calls, compiled to build executable program and deployment, which for large size software development project is a nightmare, will directly affect the development efficiency.

Is there a way to be able to bind to programs and get key information during the run, independent of program code? More importantly, this approach should be customizable, and developers can achieve specific debugging goals with a small amount of effort. The answer is yes. By using the Java Debug Interface (JDI), developers can quickly develop custom thread Profiling tools that apply to them. Such tools are independent of the main program and can be highly customizable. In the following article, we will describe how to implement the tool.

Know JPDA and JDI

Starting with J2SE 1.3, Java started providing a set of architectures called the Java Platform Debugger Architecture (JPDA), which developers can use to develop debugging programs. This architecture is widely used by the mainstream Java IDE (such as Eclipse, NetBeans, etc.).

Specifically, JPDA is not just a combination of APIs, it's not a specific tool. The architecture provides a definition of the target program, the debugging information protocol between the two parties, and the structure calls for developers to use. In J2SE 5.0, it consists of three parts:

Java Virtual Machine Tools Interface (JVMTI) is a low level of native interface. It defines the service interfaces that Java virtual machines must provide for debugging. The predecessor of JVMTI before Java 5.0 was Jvmdi (jave Virtual Machine Debug Interface).

Java Debug Wire Protocol (JDWP) defines the text format for debugging both information and requests.

Java Debuger Interface (JDI), which defines a code-level debugging interface.

From a developer's point of view, the development of debugging tools can be based on either JVMTI or JDI. JVMTI is a native interface that is relatively complex to use and requires the base of C language, so in this article we'll explain how to develop Java debuggers using the JDI top-level approach.

Demand analysis

In the next section, we'll explain how to use JDI to develop a tool for debugging multithreaded threads. Before we begin, let's list the features that the tool needs to meet:

Independent of the target application.

It should be simple enough, and can be done with a small number of code changes to complete the centralized configuration, this is to help developers do not have to pay too much effort to start debugging their own multithreaded programs.

Can crawl enough information, such as the information of the exception, the program called the value of the variables in the process, and so on.

The generated log should be clear enough to separate the records by different threads, rather than generating each record in the order of time, otherwise it would be inconvenient to debug.

Realize

In the final sample code of the article, we present a typical JDI debugging tool logic and use it to profile the execution of a simple multithreaded process. According to the requirements mentioned above, the code shows the functions of line Cheng Broker's storehouses snapshot, method invocation entry parameter value collection, exception filtering customization, class filtering configuration, thread log logging and so on. In specific terms:

Independent of the target program

The Profiling tools can be started in the following ways:

Java Trace Options Class args

Supported Options Parameters:

-output FileName: The path of the Log that the tool generates

Class is the entry type of the target program, args is the input parameter of the target program.