Why Does My First MD5 Call Take Seconds? Debugging Java Hashing Slowness with Arthas

Requirement Overview

Two APIs – a query API and a confirm API – serve a front‑end page. The query API returns a data snapshot that combines local data with results from an external service. The confirm API sends the snapshot back to the external service for verification. Because users may spend a long time on the page, the data can change between the initial query and the final confirm, so a check is performed on submit to detect changes and prompt a refresh.

MD5 Integration

To create a compact representation of the snapshot, the team concatenated key fields from each item in the query result and generated an MD5 hash using MD5.create().digestHex16(builder.toString()). The MD5 utility comes from the Hutool library, which internally loads the BouncyCastle cryptographic provider.

private String generateSnapShotHash(AcceptListQueryWrapResultDTO wrapResultDTO) {
    StringBuilder builder = new StringBuilder();
    for (AcceptListQueryResultDTO item : wrapResultDTO.getAllList()) {
        builder.append(item.getQuotationId())
               .append(item.getOperateType())
               .append(item.getPriceTypeCN());
    }
    return MD5.create().digestHex16(builder.toString());
}

Performance Problem

After deployment, the first request to the query API timed out for dozens of seconds, while subsequent requests returned instantly. The issue persisted across test, pre‑release, and production environments, suggesting a code‑level cause rather than network or gateway problems.

Debugging with Arthas

The team used the open‑source Java diagnostic tool Arthas to trace method execution times. After starting arthas-boot.jar, they ran:

trace --skipJDKMethod false com.jd.universal.inquiry.service.protocol.jsf.AcceptListWebErpServiceImpl queryList

The trace showed that generateSnapShotHash consumed 99.57% of the total latency. A second trace on the same method confirmed that the MD5 call itself was the hotspot.

trace --skipJDKMethod false com.jd.universal.inquiry.service.protocol.jsf.AcceptListWebErpServiceImpl generateSnapShotHash

The detailed trace revealed the following line taking almost the entire duration:

[99.99% 36562.318173ms] cn.hutool.crypto.digest.MD5:create() #103

Root Cause Analysis

Inspecting the Hutool source showed that MD5.create() triggers static initialization of the BouncyCastle provider, which loads a large number of cryptographic algorithms. The initialization involves scanning many JAR entries and registering algorithms, leading to a one‑time cost of tens of seconds.

private void setup() {
    loadAlgorithms(DIGEST_PACKAGE, DIGESTS);
    loadAlgorithms(SYMMETRIC_PACKAGE, SYMMETRIC_GENERIC);
    // ... many other loadAlgorithms calls ...
    //省略
}

This heavy initialization explains why the first MD5 call is extremely slow, while subsequent calls are fast.

Solution

Because Hutool’s MD5 wrapper does not expose a way to disable the BouncyCastle loading, the team replaced it with the standard JDK MessageDigest implementation (or Google’s MD5 utility). After rebuilding and redeploying, the first request completed instantly.

Takeaways

Evaluate third‑party libraries carefully; they may introduce hidden initialization costs.

When performance anomalies appear in test environments, investigate thoroughly before blaming mocks or gateways.

Heed QA findings; they can surface critical issues early.