How Sonic Achieves Near‑Instant Hot Deployment for Java Services

1 Introduction

Sonic is an internal Meituan IDEA plugin for hot deployment. The article explains its implementation details, underlying principles, and practical experience, aiming to help developers, testers, and integrators.

1.1 What is hot deployment

Hot deployment updates a running application without restarting, by replacing Java class files and triggering framework reloads, similar to refueling a fighter jet in flight.

1.2 Why we need hot deployment

Meituan engineers restart services many times daily, costing 3‑8 minutes per local restart and 20‑45 minutes per Cargo deployment. Sonic provides local and remote hot‑deployment, reducing code‑change latency to seconds and improving both self‑test and integration scenarios.

1.2.1 Development self‑test scenario

Before Sonic, developers waited 3‑8 minutes after code changes and manually invoked requests. With Sonic, a single click deploys changes instantly, even for projects that cannot be started locally, via remote hot deployment.

1.2.2 Integration scenario

Previously, developers waited 20‑35 minutes for remote deployment and log checks. Sonic enables remote hot deployment in 2‑3 seconds, saving fragmented time and supporting traffic replay, remote calls, and decompilation.

1.3 What makes hot deployment difficult

Open‑source tools are scarce because hot deployment is not merely hot restart; it requires incremental updates compatible with many middleware versions, deep knowledge of JPDA, Java Agent, ASM, classloaders, Spring, Spring Boot, MyBatis, Meituan’s RPC frameworks, and more.

1.4 What Sonic can do

Sonic is an IDEA plugin that assists low‑code development for local/remote hot deployment, reducing repetitive build cycles and improving developer coding efficiency. It can deploy code changes in 5‑10 seconds, supports multi‑file changes, and handles Spring Bean, Spring XML, and MyBatis hot deployment.

1.5 Sonic promotion practice

Successful internal adoption requires proactive communication, zero‑cost integration, automation scripts, and feedback loops. Sonic achieved over 3000 users and 2000 projects within Meituan, earning the 2020 “Best Efficiency Team” award.

2 Overall Design

2.1 Sonic structure

Sonic consists of four parts: script side (builds launch parameters), IDEA plugin side (provides UI), Agent side (implements hot deployment at runtime), and server side (collects statistics and error reports).

2.2 Inside the Agent

2.2.1 Instrumentation API

public interface Instrumentation {
    // Add a class file transformer
    void addTransformer(ClassFileTransformer transformer, boolean canRetransform);
    void addTransformer(ClassFileTransformer transformer);
    // Remove a transformer
    boolean removeTransformer(ClassFileTransformer transformer);
    // Check capabilities
    boolean isRetransformClassesSupported();
    void retransformClasses(Class<?>... classes) throws UnmodifiableClassException;
    boolean isRedefineClassesSupported();
    void redefineClasses(ClassDefinition... definitions) throws ClassNotFoundException, UnmodifiableClassException;
    Class[] getAllLoadedClasses();
}

2.2.2 Instrument overview

Instrumentation relies on JVMTI, a JVM‑exposed set of extension interfaces. JVMTI agents can be loaded on JVM start (Premain) or attached at runtime (AgentOnAttach), enabling bytecode manipulation.

2.2.3 Agent loading process

3 Sonic Hot‑Deployment Technical Analysis

3.1 Overall architecture model

The runtime consists of the script side, IDEA plugin, Agent, and server, forming a complete product loop.

3.2 Function flow

Sonic uses NIO to watch local file changes, triggering events such as class addition, modification, or Spring Bean reload. The following diagram shows a single‑file hot‑deployment lifecycle.

3.3 File listening

Sonic defines two directories: /var/tmp/sonic/extraClasspath for extended classpath URLs and /var/tmp/sonic/classes for watched files. Changes are deployed via the IDEA plugin, and the Agent picks them up for hot loading.

3.4 JVM Class Reload

New bytecode streams are wrapped in ClassDefinition objects and passed to Instrumentation.redefineClasses. This triggers Spring’s transform registration and reloads the class.

3.5 Spring Bean reload

When a Java class changes, Spring scans for Bean annotations, removes the BeanDefinition, destroys the old bean, and re‑creates it. For hierarchical contexts, parent‑child relationships are maintained, and RPC entry points (Spring MVC, Thrift, Pigeon) are re‑registered.

3.6 Spring XML reload

Modifying Spring XML triggers a full Bean reload, affecting global AOP and processors. Currently only simple Bean additions/modifications are supported.

3.7 MyBatis hot deployment

Sonic tracks MyBatis Configuration paths, maps them to Spring contexts, and reloads the configuration when related classes or XML files change.

4 Summary

4.1 Hot‑deployment feature overview

Sonic supports Spring Bean, Spring MVC, MyBatis, and many other third‑party frameworks, achieving a 99.9 % success rate within Meituan.

4.2 IDE plugin integration

The IDEA plugin provides an immersive development experience, making remote hot deployment convenient.

4.3 Adoption status

As of publication, Sonic has over 3000 users and 2000 projects inside Meituan, earning the “Best Efficiency Team” award in 2020.