Why MD5 Initialization Slows Your Java API and How to Fix It

What is the requirement

Two interfaces (query and confirm) serve a front‑end page. The query interface returns a data snapshot that combines local data and external calculations, while the confirm interface validates the displayed data against the external service.

Because users may spend a long time between viewing the page and submitting, the data can change, so the confirm step performs a check and prompts a refresh if needed.

How the problem appears

The front‑end must re‑assemble the query response as parameters for the confirm call, and the back‑end re‑aggregates the data to compare it with the submitted values. Two pain points emerged:

The front‑end finds it hard to pass the values due to page complexity.

The back‑end sees a tight coupling between the query and confirm interfaces; any change to confirm forces a change to query, making the code hard to maintain.

The author introduced an MD5 hash of key business attributes to create a data‑snapshot value, hoping to simplify the confirm interface.

Initial implementation

The snapshot hash is generated by concatenating fields from each item and applying MD5.create().digestHex16(builder.toString()). The code looks like:

/**
 * Generate data hash
 */
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());
}

After deployment, the first request to the query interface timed out, while subsequent requests were fast.

Diagnosing the slowdown

Using the Java diagnostic tool Arthas , the author traced method execution times. The generateSnapShotHash method consumed 99.57% of the total latency, and the call to MD5.create() took tens of seconds on the first invocation.

Further tracing revealed that cn.hutool.crypto.digest.MD5:create() loaded a large number of cryptographic algorithms from the BouncyCastle library during its static initialization, which caused the delay.

Root cause

The Hutool MD5 implementation loads many algorithm classes (digest, symmetric, asymmetric, keystore, secure random, etc.) on first use, leading to a heavy class‑loading cost.

Solution

Since Hutool does not provide a switch to skip this initialization, the author replaced it with Google’s lightweight MD5 implementation, rebuilt the service, and the first‑call latency disappeared.

How to reproduce the diagnosis with Arthas

Download arthas-bin.zip and unzip.

Make the jar executable: chmod -777 arthas-boot.jar.

Start it: sudo -u admin -EH java -jar /path/to/arthas-boot.jar.

Run tracing commands such as:

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

and

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

These commands reveal the time spent in MD5 initialization.

Takeaways

Evaluate third‑party libraries carefully; heavy static initialization can impact latency.

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

Listen to QA findings; they often surface hidden problems.