Community Blog Optimizing Java Agent on Dragonwell

Optimizing Java Agent on Dragonwell

The article discusses the issue of Java Agent being loaded in all JVMs in a container, causing wastage of resources and affecting troubleshooting.

By Bubi

This is the third article of the Java in Container series. You are welcome to follow the series. 😊


As more cloud-native micro-application are deployed on a large scale, the demand for microservice governance capabilities is getting bigger.

Java Agent technology enables businesses to focus on business logic. Middleware supports non-intrusive modification of program behavior through Java Agent, providing microservice governance capabilities.

In addition, Java Agent supports injection through environment variables. Middleware and cloud product teams can support this by setting environment variables.

Therefore, cloud-native observability and microservice governance capabilities based on Java Agent are increasingly used. For example, open-source Skywalking, OpenTelemetry, and commercialized Alibaba Cloud Microservice Engine (MSE) support Java Agent access.

The Issue

Let’s use the MSE demo below as an example:


Install the ack-onepilot in a Kubernetes cluster and deploy the preceding demo.

First, you can access the gateway in the demo and verify that it can work normally.


You can seek the help of the MSE documentation to experience the microservice governance capabilities of end-to-end canary release.

We can see the injected agent when we log on to the container.


However, the result is that all JVMs in the container mount Agent.

For example, java –version:


For example, jstack:


  1. Java, jps, jstack, jcmd, and other JDK troubleshooting tools will load Java Agent from environment variables.
  2. Java Agent is loaded at the beginning of the JVM, so it takes 6-7s to load the agent logic first.
  3. As a JDK tool, it does not have any business logic and does not require microservice governance capabilities. You do not need to load Java Agent.

Let's imagine this scenario: there is a problem with the online application. The O&M students want to jstack to pull the stacktrace information.

As a result, Java Agent must be loaded first, which wastes CPU and memory and makes it easier to miss the scene of troubleshooting.

However, Java Agent should be injected non-intrusively through environment variables while not injecting in some processes. Is there no way out?

MSE Has Combined with Dragonwell to Make Microservice Governance More Friendly

First of all, JVM determines whether to inject Java Agent or not. We only need to modify the JVM.

The Dragonwell team has a lot of experience.

Second, let's look at the behavior of the JVM. The existing open-source behavior is listed below:

  • JDK-related commands all load Java Agent from the JAVA_TOOL_OPTIONS.
  • After OpenJDK9, JDK_JAVA_OPTIONS was introduced. This environment variable will only be used by Java commands. Commands (such as jps/jstack) are not loaded.
  • Some JDK vendors have their extended environment variables. For example, IBM can read IBM_JAVA_OPTIONS. OpenJ9 starts to use OPENJ9_JAVA_OPTIONS after open-sourcing, and Oracle/OpenJDK uses _JAVA_OPTIONS.

Originally, JDK_JAVA_OPTIONS was introduced to meet the demand very well, but stability comes first, so Java 8 must be supported.

After discussion with Dragonwell, the following amendments were determined.

  • Dragonwell_JAVA_OPTIONS, similar to IBM_JAVA_OPTIONS, sets certain Java parameters that are only used for Dragonwell.

If DRAGONWELL_JAVA_TOOL_OPTIONS_JDK_ONLY=true, the JAVA_TOOL_OPTIONS will only be loaded by the Java command. jps/jstack does not load environment variables and Java Agents.

After the preceding transformation, you can only load Java Agent to the business Java process. It does not affect the O&M commands provided by JDK (such as jps and jstack).

As an open-source project, the overall discussion of Dragonwell is completed on GitHub Issue. You are welcome to participate.


Final Effect

Let's use the latest Dragonwell version to run a business application and simulate the operation and maintenance scenario.


As you can see, the JDK O&M tool does not load the Java Agent.

The business process is loaded with the Java Agent (you can also see the application in the MSE governance console). This prevents Java Agent from affecting O&M scripts (such as java –version).

MSE Brings Powerful Microservice Governance Capabilities

Alibaba Cloud Microservice Engine (MSE) provides zero-cost, non-intrusive, and full-lifecycle microservice governance capabilities using Java Agent, SDK, and Service Mesh.


0 2 1
Share on

You may also like


Related Products

  • Microservices Engine (MSE)

    MSE provides a fully managed registration and configuration center, and gateway and microservices governance capabilities.

    Learn More
  • Cloud-Native Applications Management Solution

    Accelerate and secure the development, deployment, and management of containerized applications cost-effectively.

    Learn More
  • Function Compute

    Alibaba Cloud Function Compute is a fully-managed event-driven compute service. It allows you to focus on writing and uploading code without the need to manage infrastructure such as servers.

    Learn More
  • Lindorm

    Lindorm is an elastic cloud-native database service that supports multiple data models. It is capable of processing various types of data and is compatible with multiple database engine, such as Apache HBase®, Apache Cassandra®, and OpenTSDB.

    Learn More