Why Spring Boot’s War‑to‑Jar Deployment Slows Down Feign Calls and How to Fix It

The team received a performance complaint: after upgrading the internal framework, the UAT environment’s API throughput fell dramatically (53.9 requests/s → 6.4 requests/s) and CPU usage spiked, while SkyWalking showed Feign calls taking ~390 ms despite downstream services responding in ~3 ms.

Root‑cause investigation with Arthas

Arthas (v3.4.3) was uploaded to the target machine and the profiler start -d 30 -f /tmp/arthas/1.txt command was run to collect a 30‑second CPU profile. The top stack frames revealed heavy CPU consumption in Spring’s HttpMessageConverters initialization, especially around Feign‑related classes such as com.zhangmen.xxx.DefaultFeignConfig.

Using trace com.zhangmen.xxx.DefaultFeignConfig '*#cost>200' -n 3 highlighted the constructor of HttpMessageConverters as a hotspot (≈600 ms). Further tracing pinpointed org.springframework.util.ClassUtils.forName() throwing and catching ClassNotFoundException during each Feign encode/decode cycle.

First fix – add jackson‑datatype‑joda

Introducing the jackson-datatype-joda dependency prevented repeated attempts to load com.fasterxml.jackson.datatype.joda.JodaModule and its inner class, reducing the Feign encoder/decoder overhead. After redeploying, throughput rose to 69.3 requests/s, surpassing the pre‑upgrade level.

Deeper analysis – War‑to‑Jar classloader impact

Even with the Joda fix, a discrepancy remained: the upgraded version still lagged when the dependency was absent. Investigation showed that the Spring Boot executable JAR’s custom classloader ( LaunchedURLClassLoader) performed expensive package definition and resource scanning for every missing class, especially under the BOOT-INF/lib/ and BOOT-INF/classes/ directories.

Flame‑graph comparison of the upgraded vs. non‑upgraded builds revealed additional stack frames in org/springframework/boot/loader/LaunchedURLClassLoader. Tracing definePackageIfNecessary exposed a ~165 ms cost for each call, caused by iterating over all nested JARs to locate resources.

Second fix – avoid default HttpMessageConverters

Because the custom Feign codec only needs a FastJson converter, the default HttpMessageConverters initialization can be disabled:

ObjectFactory<HttpMessageConverters> objectFactory = () -> new HttpMessageConverters(false,
    new HttpMessageConverter[] { (HttpMessageConverter) fastJsonHttpMessageConverter });

Alternatively, modify DefaultFeignConfig to reuse a single HttpMessageConverters instance instead of creating a new one on every request.

Result verification

After applying both fixes and retesting in a FAT environment with JMeter, the upgraded version achieved 160.4 requests/s, matching or exceeding the original performance. Additional benchmarks showed that when class‑loader resource look‑ups are infrequent, all three deployment modes (war, jar‑launcher, exploded jar) perform similarly.

Practical takeaways

Avoid repeated initialization of HttpMessageConverters when using custom Feign encoders/decoders.

Be aware that Spring Boot’s executable JAR classloader adds overhead during frequent missing‑resource scans.

Use jackson-datatype-joda (or similar) to prevent costly class‑loading loops.

Combine SkyWalking for end‑to‑end tracing with Arthas for low‑level JVM diagnostics.

These steps eliminated the performance regression caused by the framework upgrade and clarified the root cause of the War‑to‑Jar classloader slowdown.