Implementation of Java thread monitoring based on JVMTI

With the increasing popularity of multi-core CPUs, more and more Java applications use multithreading parallel computing to give full play to the performance of the whole system. The use of multithreading also poses a huge challenge to application developers, and improper use of multithreading can lead to thread deadlock or resource competition, resulting in system paralysis. Therefore, a Run-time thread monitoring tool is needed to help developers diagnose and track the transitions of Java thread state. JDK 1.5 and subsequent versions provide an interface JVMTI to monitor the state of the virtual machine running.

JVMTI Tool Interface

With the development of multi-core CPU Technology, multithread programming technology is widely used, so as to give full play to the performance of the whole system. The Java language provides language-level support for multithreaded programming, which makes it easy to create, run, and destroy threads. However, the use of multithreading also poses great challenges for application developers, and improper use of multithreading can lead to thread deadlock or resource competition, resulting in system paralysis.

To help Java developers diagnose and track Java thread state transitions, Sun has introduced Java Virtual Machine tool interface (Java Vir in the Java Development Toolkit (JAVA2 Software Development Kit, JDK) 1.5.0 version tual Machine Toolkit INTERFACE,JVMTI), which replaces the Java Virtual machine profiling interface that existed as a test feature in previous JDK versions (Java VPN Machine Profiling, INTERFACE,JVM PI) and the Java Virtual Machine debugging interface (Java Machine debugging Interface,jvmdi). The JVMTI interface allows you to create an agent (agent) to monitor and control Java applications, including profiling, debugging, monitoring, profiling threads, and so on, and its architectural model is shown in Figure 1.

Figure 1. JVMTI Architecture Model

The agent can subscribe to events of interest to a running virtual machine instance, and when these events occur, the agent is activated as an event callback function, and JVMTI provides numerous functional functions to query and control the running state of the Java application. The agent communicates with the virtual machine through the interface provided by JVMTI and monitors the running state of the virtual machine synchronously, which is relatively independent of the running Java application and does not interfere with the normal operation of the program. The Agent can be written in any native language that supports the C language standard and exists as a dynamic link library, which can be loaded when the Java program is started.

The Agent based on the JVMTI interface can easily track the state transitions of Java threads, so that developers can clearly understand the threads of multithreaded applications at runtime, and facilitate debugging and error removal. The next section of this article describes how to build a Java thread switching monitoring agent based on the JVMTI interface.

Java Threading Model

To monitor the switching of Java threads, you must first understand the Java threading model in the JVM. The Java threading model can be described in the Java thread lifecycle shown in Figure 2. The lifecycle of a Java thread consists of creating, ready, running, blocking, and dying 5 states. A Java thread is always in one of these 5 lifecycle States and can be converted between different states under certain conditions.

Figure 2. Java Threading Model

Create status (New Thread)

After a thread is created using the new operator in the Java language, the thread is simply an empty object that has some characteristics of the thread, but the system does not allocate resources for it, and the thread is in the created state.

Ready status (Runnable)

When a thread is started with the start () method, the system assigns the required resource, except the CPU, to the thread to make the thread in the ready state. In addition, if a thread executes the yield () method, the thread is temporarily stripped of the CPU resources and is back into the ready state.