Java 21 to 25: 22.7% increase in throughput (RPS) and a 20.1% reduction in average latency.

22.7% increase in throughput (RPS) and a 20.1% reduction in average latency.

If you are looking for a way to optimise memory usages for your JVM based applications, this article might help you. In this article, I am sharing the story of the International Payment team with Java 25 (LTS) experimentation.

The leap to Java 25 (LTS) is more than just a version bump — it is a massive optimization for high-throughput environments. Even before leveraging specific language features or new compilation flags, the runtime improvements alone deliver immediate value.

Below is a deep dive into our recent performance benchmarking results, comparing the new LTS to the previous standard.

Summary

The transition to the Java 25 (LTS) Runtime has yielded significant improvements in throughput and latency stability. We observed a 22.7% increase in throughput (RPS) and a 20.1% reduction in average latency.

Most notably, memory management is more efficient; Java 25 maintains a lower and more stable Resident Set Size (RSS) footprint even under heavy peak loads.

Problem Statement

In the International payment team, we use Java for service development. As the traffic grows, sometimes we have to increase the memory usage in order to support the traffic.

We found an automated way via dynamic resource allocation.

It was working fine until all services got onboarded and all of them had to allocate extra memory due to demand of traffic. This sometimes even led to taking extensive measures to find and close low priority service in-order to make space for high priority services.

So together with other teams, we discussed the approach to solve this so that the overall memory usage remains under limit.

Solutions

Since this is a broader problem, we discovered many solutions. One of them was to use Java 25 LTS, with object header compression.

We will discuss only Java 25 LTS solution in this article.

Approach

In order to use Java 25, first we needed to learn the data in order to make sure the solution is effective for resources and cost.

We ran benchmarking as mentioned below…

Base line

We utilized Docker to enforce strict resource quotas, preventing “noisy neighbor” interference and ensuring both versions had exactly the same overhead

• Base Image: https://hub.docker.com/_/openjdk (Publicly available image under OpenJDK licensing)
• CPU Limit: 2.0 Cores
• Memory Limit: 2GB RAM
• Architecture: Intel / Apple Silicon (M1)
• Monitoring: Native Memory Tracking (NMT) enabled via summary mode.

Deployment Commands:

# Java 21 Baseline
docker run -d - name app-v21 -p 8022:8080 \
 - memory="2g" - cpus="2.0" \
-e JAVA_OPTS="-XX:NativeMemoryTracking=summary" \
demoapp:v21
# Java 25 Target
docker run -d - name app-v25 -p 8021:8080 \
 - memory="2g" - cpus="2.0" \
-e JAVA_OPTS="-XX:NativeMemoryTracking=summary" \
demoapp:v25

Throughput & Latency Analysis

Handling the Pressure

When pushed to its limits, Java 25 handles concurrency significantly better than its predecessor. While Java 21’s P99 latency ballooned to nearly 13 seconds under pressure, Java 25 kept the P99 at approximately 7 seconds — a massive win for system reliability and user experience.

Analysis: The slight increase in Max Response Time is considered a statistical outlier in this test cycle, likely due to cold-start warmup during the initial burst.

Resource Efficiency (I/O & Memory)

Using podman stats to monitor the environment over the test duration, we identified three key areas where Java 25 outshines Java 21 in resource utilization:

Lower Memory Footprint

Java 25 consistently operated with 63MB — 120MB less RAM than Java 21 during identical load intervals.

• Startup: 687MB (v25) vs 750MB (v21)
• Peak Load: 1.04GB (v25) vs 1.18GB (v21)

Improved Network Efficiency

V25 processed the same volume of requests but with 50% less total data overhead (795 MB vs 1.44 GB). This suggests more efficient serialization or leaner response handling within the new runtime’s core libraries.

CPU Instruction Efficiency

While V25 showed a slightly higher total CPU time (17m vs 15m), this translated into much higher RPS. This indicates higher instruction efficiency — the JVM is doing more meaningful work per clock cycle rather than idling or battling GC overhead.

Final Verdict

The data is conclusive: The Java 25 JVM provides a superior execution environment. Its reduced memory pressure, improved P99 latencies, and higher resource efficiency make it a high-priority upgrade for production services facing scaling challenges.

Post implementation, we have seen ~10% reduction in the memory usages.

Further Learning during the migration phase

Switching the runtime image:

At the International Payment team, we encountered issues when relying solely on runtime image switching, as it failed to optimize the runtime class and data layout, leading us to redesign our migration process. You may observe slight uplift in GC performance, though. Also adding -XX:+UseCompactObjectHeaders is needed as it is not enabled by default.

Gradle compatibility :

If you are using gradle v8.4 with Java-21, then make sure to switch to v9.1 or above. As gradle 9.1 and lower versions do not fully support Java-25. This is another hurdle, as major build version upgrades also come with their own challenges. But since this is one time, we accepted this challenge and made the migration to gradle 9.1 too.

Can AI help in this upgrade?

At Trendyol Tech, we experimented with AI agents to automate migration across applications using similar build tools and versions. Using AI agent worked well and reduce time for making upgrades.

Want to work in this team? Be a part of something great! Trendyol is currently hiring. Visit the pages below for more information and to apply. Have a look at the roles we’re looking for!