How Lalamove Cut 30% of Dead Code: A Practical Code‑Slimming Playbook

Background

Lalamove’s international services accumulated years of iteration, resulting in a codebase where at least 30% of the code was dead and more than 100 database fields were obsolete. This severely degraded code quality and development efficiency.

Slimming Scope

Unreferenced code (classes, methods, fields)

Methods that are referenced but receive no traffic

Useless DB attributes

Invalid Apollo configurations

Tooling Overview

SA Plugin

The Serviceability Agent (SA) plugin combines Spoon’s static code‑parsing with HotSpot VM’s Service Ability (SA) to count method executions at runtime. After a service runs, Spoon provides the full method set, while HotSpot SA supplies the set of methods that actually received traffic. The difference yields dead methods.

HotSpot VM Service Ability

HotSpot VM offers a debugging toolset that can attach to a target JVM and retrieve OS‑level memory data, including per‑method execution counts. These counts are normally used for JIT compilation but can also identify methods that never execute.

The Serviceability Agent is a Sun‑private component in the HotSpot repository that can expose Java objects and HotSpot data structures in running processes or core files. Reference: https://openjdk.org/groups/hotspot/docs/Serviceability.html

Collection Process

We wrap the JDK‑provided sa-jdi.jar into an out‑of‑process SA Agent. When a Kubernetes pod is terminated, the agent attaches to the earliest‑started pod’s JVM, collects method‑execution‑count data, and reports it to the code‑slimming platform.

Cautions

Attach pauses the JVM (STW); trigger it during offline pod termination or deployment shutdown.

The target JVM needs 500 MB–1 GB of free memory for data collection.

The monitored service must have at least two pod instances to avoid single‑point failure.

Implementation Examples

public class CompiledMethodVisitor implements CodeCacheVisitor {
    // ...
    public void visit(CodeBlob codeBlob) {
        if (codeBlob == null || codeBlob.asNMethodOrNull() == null) {
            return;
        }
        final Method method = codeBlob.asNMethodOrNull().getMethod();
        Long methodInvocationCount = method.getInvocationCount();
        // ...
    }
}

public class InvocationCounterVisitor implements SystemDictionary.ClassVisitor {
    // ...
    @Override
    public void visit(Klass klass) {
        if (klass instanceof InstanceKlass) {
            final MethodArray methods = ((InstanceKlass) klass).getMethods();
            for (int i = 0; i < methods.length(); i++) {
                final Method method = methods.at(i);
                if (method.getInvocationCount() > 0) {
                    // ...
                }
            }
        }
    }
}

Advantages

Compared with alternative implementations on execution risk, performance overhead, and complexity, the SA‑based approach performed best.

BigClean Scanner Plugin

The built‑in IDEA unused‑code scanner was unintuitive, so a custom plugin named BigClean Scanner was created. It uses Spoon to collect the full method set and the referenced method set, then computes their difference to list unused classes and methods. Results require manual verification before deletion.

MyBatis Interceptor

For Java developers, a MyBatis interceptor can intercept SQL execution, parse statements, and locate code that accesses deprecated DB fields. Detected fields, interface names, and table names are reported to a monitoring platform to guide cleanup.

Quality Assurance Strategies

Read‑Interface Validation (Traffic Replay)

After removing logic from a read interface (e.g., price‑calculation in an order‑detail query), the internal llrepeater tool records the request, replays it on another pod, and compares responses for consistency.

Write‑Interface Validation (DB Consistency)

If a cleanup accidentally removes code that updates the DB, comparing the DB records of two orders before and after the change reveals inconsistencies.

Write‑Interface Validation (Downstream Parameter Consistency)

Similar to DB checks, this strategy records Kafka bodies, Redis keys/values, and downstream request/response parameters before and after the change, then compares them to detect accidental deletions.

Impact on Read‑Interface After Removing Deprecated DB Fields

When a deprecated DB field X is removed, the team verifies whether the order‑detail read interface still returns correct results. Two DB copies are used: a normal DB (with X) and a shadow DB (without X). Traffic from the default pod is recorded via Kafka, replayed on the shadow pod, and responses are compared.

Deploy default pod (connects to normal DB) and v65708 pod (connects to shadow DB) with identical read‑service code.

Ensure the write service still writes the deprecated field.

Record traffic (req‑A/resp‑A) from the default pod.

Replay the traffic on the shadow pod to obtain resp‑B.

Compare resp‑A and resp‑B; any mismatch indicates the read interface is affected by the field removal.

Shadow DB: A copy of the production DB schema without the deprecated fields; only the data content differs.

Final Remarks

Code slimming removed over 30% of dead code and more than 100 obsolete DB fields, dramatically improving readability and maintainability. Sustained awareness, a solid SOP, and regular supervision are essential to keep code hygiene healthy.