Speed Up Existing Deployments with the Right JVM Features

In today’s tech landscape, Java applications face a critical challenge. Organizations need to meet growing performance demands while keeping infrastructure costs under control, without costly redevelopment efforts.

This challenge has intensified with cloud computing adoption. Every millisecond of latency and every megabyte of memory now directly impacts ongoing expenses. The numbers are striking: based on my experience, poorly configured JVMs typically can increase cloud costs by 30-50%. For large enterprises, this represents millions in avoidable expenses.

Common Optimization Mistakes

Despite the clear financial impact, most organizations approach JVM optimization ineffectively. We observe these four common mistakes repeatedly:

1. Accepting Default Settings: Many teams simply use out-of-the-box JVM configurations. These default settings favor compatibility rather than performance, resulting in inefficient heap utilization, non-ideal garbage collection patterns, and resource-consuming startup and warmup phases.
2. Copying Random Configurations: When teams do attempt optimization, they often use settings from blogs or forums. These settings, designed for different workloads or JVM versions, frequently make performance worse.
3. Throwing Resources at Problems: Instead of fixing core issues, many organizations just add more CPU, memory, and machines. This creates a cycle of growing costs without addressing the root causes.
4. Focusing on the Wrong Optimizations: Even dedicated performance work often targets the wrong areas. Teams might spend weeks fine-tuning garbage collection while ignoring simple configuration changes with much bigger impact.

These patterns persist because many teams don’t fully understand modern JVM performance characteristics and the readily available optimization opportunities.

Understanding the New Reality

Before exploring the quick wins available to us, we need to recognize the fundamental shifts that have created today’s JVM landscape:

1. Containerization: Most Java applications now run in containers. This creates new challenges in how the JVM interacts with resource limits, but also new optimization opportunities.
2. Advanced JVM Features: Modern JVMs include powerful performance features that most deployments don’t use. From sophisticated garbage collectors to startup acceleration technologies, these capabilities offer major benefits with minimal implementation effort.
3. Cloud Economics: As applications moved to the cloud, performance became directly tied to operating costs. Optimization is no longer just about user experience – it’s a cost control necessity.

These changes call for a fresh approach to JVM performance, one that leverages modern capabilities to address the specific challenges of containerized, cloud-native deployments.

Throughout this article, we’ll explore progressively more sophisticated optimization techniques that can dramatically improve performance with minimal effort.

***

Let’s start our journey into JVM performance wins with the foundation: proper container configuration. No application changes required – just smart Dockerfile construction and JVM settings that unlock immediate performance gains. These quick wins for Java applications are your first step toward eliminating performance debt with minimal effort and risk.

Easy Performance Wins with Container Optimization

The container revolution has fundamentally transformed how we package and deploy Java applications. Yet many organizations fail to realize that container configuration itself represents a critical performance optimization opportunity. Even before considering sophisticated JVM tuning, the way we construct our container images and configure their runtime environments can deliver substantial performance improvements.

Tip 1: The Base Image Matters

The starting point for any containerized Java application is selecting the appropriate base image. This seemingly simple decision has cascading effects on everything from startup time to memory consumption.

Most developers default to general-purpose Linux distributions as their base images. These distributions typically range around 300MB in size and include hundreds of utilities, libraries, and services irrelevant to Java application execution. Some providers offer lightweight versions of their OS, like Red Hat’s UBI Minimal (80-100MB) or Debian Slim. This is already a step forward; however, it can be improved even further. 

Musl-based Linux distributions are significantly smaller in size than those with glibs. Recognizing this opportunity, in 2019 BellSoft contributed the Alpine Linux port (JEP 386) to the OpenJDK project, creating proper musl libc support. This innovation brought dramatic image size reductions for Java applications.

Taking base image optimization even further, Alpaquita is a Linux distribution specifically optimized for Java workloads. It offers a small image size and choice between musl and glibc variants, along with runtime optimizations tailored for JVM workloads, which we will discuss further in this article.

Alternatively, opt for production-ready Java images, e.g., Liberica Runtime Container. It comes with Alpaquita Linux and Liberica JDK Lite, a minimized version of an OpenJDK build. This combination helps save up to 30% of RAM and disk space for cloud deployments, all without any manual tuning. 

Another simple optimization is using the “JRE” instead of the full JDK in production containers. This distinction becomes significant in microservice architectures with dozens or hundreds of instances, reducing memory footprint by 15-25% with no performance penalty.

These optimizations aren’t merely about reducing image size—though that alone improves deployment times and reduces network traffic. More importantly, purpose-built Java base images often include performance-oriented configurations and support for performance features that general-purpose images lack.

Tip 2: Application Layer Separation

Container image layering, while seemingly a technical implementation detail, represents another opportunity for performance optimization.

Instead of bundling everything into a single layer, separate components based on how frequently they change:

# Inefficient approach - single layer for all dependencies
COPY ./target/application.jar app.jar

# Optimized approach - separating layers by change frequency
COPY --from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY --from=build ${DEPENDENCY}/META-INF /app/META-INF
COPY --from=build ${DEPENDENCY}/BOOT-INF/classes /app

This approach leverages Docker’s caching mechanisms to rebuild and transfer only what has changed. When updating a microservice, you might transfer just 10KB of modified code instead of the entire 200MB+ image. Across hundreds of containers and frequent deployments, this can reduce network traffic by orders of magnitude.

Tip 3: JVM Memory Configuration

The single most impactful container optimization is proper JVM memory configuration. By default, older JVMs don’t recognize container memory limits, leading to either out-of-memory errors or underutilized resources. 

The simple solution is explicit memory configuration: 

MaxRAMPercentage=80: Use 80% of container memory (adjust based on application type)

# Common mistake - no memory settings 
ENTRYPOINT ["java", "-jar", "app.jar"] 


# Optimal approach - percentage-based settings 
ENTRYPOINT ["java", \ 
"-XX:MaxRAMPercentage=80", \ 
"-jar", "app.jar"]

These simple changes properly align JVM resource usage with container boundaries, often improving throughput by 20-40% without any code modifications.

***

These container optimizations represent the first set of quick wins for enhancing Java application performance. From base image selection to memory configuration, each step delivers significant gains with minimal effort, making these optimizations accessible to teams regardless of their expertise level.

Next, we’ll tackle another critical performance challenge: startup time optimization. By understanding and addressing the resource-intensive initialization phase of Java applications, we can achieve further substantial improvements in deployment efficiency and resource utilization.

Achieving Near-Zero Startup Time

Java applications exhibit a resource consumption pattern that creates significant scaling challenges. Rather than maintaining consistent resource usage throughout their lifecycle, they display a distinctive “peak-then-plateau” pattern where resource usage is initially very high during startup and then decreases significantly for normal operation.

This resource consumption profile creates a fundamental scaling inefficiency. Horizontal scaling becomes problematic because each new Java instance requires this intensive initialization phase. Adding more instances can actually reduce overall system performance temporarily. Why? Because your resources get consumed by startup processes instead of handling actual requests.

Let’s look at real performance data from our tests with a typical Spring Boot application:

• CPU usage: Peaks at 400% (4 cores) during startup, settles to ~100% during steady-state
• Memory usage: Begins high as heap initializes, stabilizes after several garbage collection cycles
• Response time: First requests take 5-10x longer than steady-state responses
• Startup duration: 41 seconds to become fully operational at 1000 requests/second (in testing conditions)  

In production environments with more complex initialization requirements, this startup time can extend to 15-20 minutes. During this startup period, response times can be 5-10x slower than normal, and error rates often spike as connection pools and caches initialize. This creates a critical scaling problem: you can’t simply double resources to get double the performance. Unoptimized Java applications inevitably lead to resource underutilization and higher cloud bills, while still delivering inconsistent user experiences during scaling events.

4 Ways to Reduce Startup Time

The Java ecosystem offers several powerful quick wins for addressing startup time challenges. Each represents a progressively more sophisticated approach to solving the initialization bottleneck:

Level 0: Client VM – The Simple Switch

The simplest approach leverages the often-overlooked Client VM, which prioritizes startup performance over long-term throughput optimization:

ENTRYPOINT ["java", "-client", "-jar", “app.jar"]

Note: You need a JDK bundle that actually includes a client VM. 

Testing with a standard Spring Boot application shows:

• Startup time: Reduced by 15-25%
• CPU consumption: Lower initial peak, generally requiring 1-2 cores during initialization rather than 3-4
• Memory footprint: Approximately 10MB smaller
• Trade-off: Potentially lower peak throughput during sustained high loads  

This optimization is particularly valuable for serverless deployments, short-lived processes, and applications with moderate throughput requirements. AWS Lambda, for instance, recommends setting -XX:TieredStopAtLevel=1, which makes the Server VM perform compilation similar to Client VM, significantly reducing cold start times while maintaining reasonable performance for serverless functions

Level 1: Class Data Sharing (CDS) – Reusing Loaded Classes

Class Data Sharing (CDS) addresses one of the most resource-intensive aspects of Java startup: class loading. By creating memory-mapped archives of loaded classes, CDS significantly reduces startup time and memory usage:

#First Stage: create a shared archive
java -XX:ArchiveClassesAtExit=./application.jsa -jar target/app.jar

#Start the application and use the shared archive: 
java -XX:SharedArchiveFile=application.jsa -jar target/app.jar

For Spring Boot applications, this optimization can be even simpler with built-in support:

#Create an executable JAR
FROM bellsoft/liberica-runtime-container:jdk-23-stream-musl as builder

WORKDIR /home
ADD app /home/app
RUN cd app && ./mvnw clean package

#Create a layered JAR
FROM bellsoft/liberica-runtime-container:jdk-23-cds-slim-musl as optimizer

WORKDIR /app
COPY --from=builder /home/app/target/*.jar app.jar
RUN java -Djarmode=tools -jar app.jar extract --layers --launcher

#Copy application layers to the fresh base image and create the archive 
FROM bellsoft/liberica-runtime-container:jdk-23-cds-slim-musl

COPY --from=optimizer /app/app/dependencies/ ./
COPY --from=optimizer /app/app/spring-boot-loader/ ./
COPY --from=optimizer /app/app/snapshot-dependencies/ ./
COPY --from=optimizer /app/app/application/ ./

#Run the application in container to create the archive. The app will exit automatically. Enable Spring AOT.
RUN java -Dspring.aot.enabled=true \
  -XX:ArchiveClassesAtExit=./application.jsa \
  -Dspring.context.exit=onRefresh \
  org.springframework.boot.loader.launch.JarLauncher

#Run the application with Spring AOT enabled and using the shared archive
ENTRYPOINT ["java", \
  "-Dspring.aot.enabled=true", \
  "-XX:SharedArchiveFile=application.jsa", \
  "org.springframework.boot.loader.launch.JarLauncher"]

Testing shows CDS typically delivers:

• Startup time: 30-40% reduction
• Memory savings: 5-15% lower memory usage due to shared metaspace
• CPU reduction: Less pronounced initial CPU spike
• Compatibility: Works with virtually all Java applications without code changes 

Level 2: Native Image – Compiled from the Start

GraalVM Native Image takes a more radical approach, compiling Java applications ahead of time into standalone native executables:

# Build stage using GraalVM CE-based Liberica Native Image Kit
FROM bellsoft/liberica-native-image-kit-container:jdk-21-nik-23.1-stream-musl
WORKDIR /home/myapp
COPY Demo.java /home/myapp/
RUN javac Demo.java
RUN native-image Demo

# Run stage
FROM bellsoft/alpaquita-linux-base:stream-musl
WORKDIR /home/myapp
COPY --from=0 /home/myapp/demo.
CMD [“./demo”]

For Spring Boot applications, the native image process is simplified with built-in support: ./mvnw -Pnative spring-boot:build-image.

Native Image delivers dramatic startup improvements:

• Startup time: 10-100x faster (milliseconds instead of seconds)
• Memory footprint: Often 50% smaller
• Trade-offs: Some reflection limitations, potentially lower peak throughput  

Level 3: Checkpoint/Restore (CRaC) – Freezing a Running Application

The most advanced approach uses Coordinated Restore at Checkpoint (CRaC), an OpenJDK project. CRaC works like taking a snapshot of your fully initialized, running Java application and then “freezing” it. Later, you can instantly “thaw” and restore this snapshot, bypassing the entire startup and warmup phase:

#Build the container image, start and exit the application in a container to create a file with a checkpointed application
FROM bellsoft/liberica-runtime-container:jdk-21-crac-musl as builder
WORKDIR /home
ADD app /home/app
RUN cd app && ./mvnw clean package
 
FROM bellsoft/liberica-runtime-container:jre-21-crac-slim-musl as optimizer

WORKDIR /app
COPY --from=builder /home/app/target/app.jar /app/app.jar

RUN java -Djarmode=tools -jar app.jar extract --layers --launcher

FROM bellsoft/liberica-runtime-container:jre-21-crac-slim-musl

# We stay root in a container to use CRaC
VOLUME /tmp
EXPOSE 8080

COPY --from=optimizer /app/app/dependencies/ ./
COPY --from=optimizer /app/app/spring-boot-loader/ ./
COPY --from=optimizer /app/app/snapshot-dependencies/ ./
COPY --from=optimizer /app/app/application/ ./

ENTRYPOINT ["java", "-Dspring.context.checkpoint=onRefresh", "-XX:CRaCCheckpointTo=/checkpoint", "-XX:MaxRAMPercentage=80.0", "org.springframework.boot.loader.launch.JarLauncher"]

Here’s the complete workflow for implementing CRaC in your deployment pipeline—from container initialization to creating the checkpoint and finally launching applications from the preserved state:

#Build the container image
docker build . -t app-crac-checkpoint -f Dockerfile-crac

#Start the container image
docker run --cap-add CHECKPOINT_RESTORE --cap-add SYS_PTRACE --name app-crac app-crac-checkpoint

#Transfer the contents of the image into a new image and change the entry point to restart the application from the file:
docker commit --change='ENTRYPOINT ["java", "-XX:CRaCRestoreFrom=/checkpoint"]' app-crac app-crac-restore

#Remove the first container:
docker rm -f app-crac

#Run the second image with the checkpointed application:
docker run -it --rm -p 8080:8080 --cap-add CHECKPOINT_RESTORE --cap-add SYS_PTRACE --name app-crac app-crac-restore

CRaC delivers the ultimate in startup optimization:

• Startup time: Near-instantaneous (milliseconds)
• Memory efficiency: Pre-initialized heap without early garbage collection turbulence
• CPU savings: Eliminates almost all initialization CPU spikes
• Requirements: Needs CRaC-compatible JVM (e.g., Liberica JDK CRaC) and application changes for secure and clean checkpoint/restore 

The Future: Project Leyden

Project Leyden represents the natural evolution of the optimization techniques we’ve discussed. Rather than being a distant future technology, it’s actively being developed to go beyond AppCDS capabilities within OpenJDK. Building upon AppCDS, Leyden aims to create a unified cache that preserves not only loaded classes but also compiled code, method profiles, and linked classes. Leyden will work across all supported Java platforms and provide stateless operation after an initial training run. This comprehensive approach promises to combine the startup benefits of AOT compilation with the runtime performance of a fully warmed-up JVM, without the limitations of current solutions.

Choosing the Right Startup Approach

Each startup optimization approach offers different trade-offs. For most applications, a progressive implementation approach works best:

• Start with Client VM and/or CDS for immediate benefits with minimal risk
• Evaluate Native Image or CRaC for applications with critical startup requirements

By selecting the right startup optimization approach, organizations can dramatically improve resource utilization, enabling more efficient scaling and significantly reducing cloud costs.

Garbage Collection: Choosing the Right Collector is Key

Garbage collection (GC) is the automatic process of reclaiming unused memory in Java applications. While it eliminates the need for manual memory management, improper GC configuration can lead to frequent or long pauses that affect application responsiveness and throughput.

Garbage collection has long been considered the most complex aspect of JVM tuning. Many teams spend weeks fine-tuning GC parameters, often with marginal returns. However, modern JVMs offer a simpler, more effective approach: selecting the right garbage collector based on your application’s specific requirements.

Application Type	Collector Switch	Typical Improvement
Latency-sensitive API	G1 → ZGC	90-99% reduction in max pause times
Batch processing	G1 → Parallel	10-15% throughput improvement
Memory-constrained	G1 → Serial	5-10% memory footprint reduction

The performance improvements from simply selecting the appropriate collector can be dramatic. Even more impressively, these improvements require only a single configuration change—unlike traditional GC tuning that might involve dozens of parameters. Therefore, rather than attempting to master dozens of complex tuning parameters, the most impactful quick win for GC optimization is simply choosing the appropriate collector for your performance goals.

• For Low-Latency Applications: ZGC and Shenandoah. They deliver sub-millisecond pauses regardless of heap size (even 100GB+), with predictable performance under memory pressure, though at a slight cost to throughput.
• For Maximum Throughput: Parallel GC. It provides 10-15% higher throughput for batch processing and CPU-intensive applications, with the trade-off of longer pause times.
• For Balanced Concerns: G1 GC. G1 offers a good balance for general-purpose applications, with configurable pause goals and reasonable throughput.
• For Constrained Environments: Serial GC. It reduces memory overhead and CPU contention in small containers, making it efficient for limited resource environments.
• The Next Generation: Generational ZGC and Shenandoah. These newer implementations retain ultra-low pauses while reducing memory usage by 10-25% and better handling short-lived objects, effectively eliminating traditional trade-offs.

The Future: Project Lilliput

Beyond collector selection, another emerging quick win for memory efficiency is Project Lilliput, which reduces Java object header sizes:

# Enable Lilliput for reduced object header size (JDK 24+ experimental)

ENTRYPOINT ["java", "-XX:+UnlockExperimentalVMOptions", "-XX:+UseCompactObjectHeaders", "-jar", "app.jar"]

Lilliput can reduce heap memory requirements by 10-20% in object-heavy applications without any code changes. This project targets one of Java’s long-standing memory inefficiencies, where object headers consumed disproportionate amounts of heap space.

Hands-on Strategy for GC Tuning

The modern approach to GC optimization involves a progression from simple to advanced techniques:

1. Start with collector selection based on your primary performance goal
2. Add memory sizing appropriate for your container environment
3. Consider experimental features like Lilliput for advanced optimization
4. Only then consider detailed parameter tuning if necessary

This approach represents a dramatic simplification from traditional GC tuning, with far higher return on investment. The days of needing to be a GC expert to achieve excellent Java performance are effectively over.

Legacy Applications: All Hope Is Not Lost

The optimization techniques we’ve discussed so far deliver their full benefits on modern JVMs—primarily Java 17 and newer. However, the reality of enterprise Java deployments presents a significant challenge: most production workloads still run on older versions.

According to various sources (New Relic’s 2024 State of the Java Ecosystem or JetBrains’s 2023 Dev Ecosystem Report), 29-50% of respondents continue to use Java 8, while 32-38% rely on Java 11. In BellSoft’s Java Developer Survey, two-thirds of respondents admitted to still running applications on Java 11 or earlier versions.

These statistics reflect a common enterprise reality: migrating legacy applications to newer Java versions often presents significant technical and business challenges. The result is a performance and efficiency gap, where organizations running older Java versions miss out on critical optimizations available in newer JDKs.

Fused JDKs: Modern Performance for Legacy Applications

Fortunately, a powerful quick win exists for legacy Java applications: Fused JDKs. These specialized distributions combine the API compatibility of older Java versions with the performance improvements of modern or custom JVM implementations.

Liberica JDK Performance Edition represents a fully open-source example of this approach. It maintains a clear separation between the Java API (what your application code interacts with) and the JVM implementation (the runtime engine that executes your code):

• API Layer: Remains 100% compatible with the target Java version (8 or 11)
• JVM Layer: Incorporates optimizations from newer JVM versions

This architecture allows applications to benefit from modern JVM optimizations without any code changes or compatibility risks. Your application continues to use the Java 8 or 11 APIs it was designed for, while the underlying JVM leverages modern performance improvements:

1. Modern Garbage Collection: Legacy applications can access ZGC and other low-latency collectors, delivering up to 90% reduction in pause times without application changes.
2. Runtime Optimizations: Java 8 and 11 applications benefit from newer JIT compiler improvements, optimized string handling, and enhanced intrinsics, delivering 10-30% better throughput for many workloads.
3. Memory Efficiency: Memory optimizations from newer JVMs reduce footprint and improve garbage collection efficiency for legacy applications.
4. Container Awareness: Legacy applications gain container-aware resource management that wasn’t available in the original Java 8 or 11 releases.

Performance testing with standard Java benchmarks shows the tangible benefits:

• Spring Boot 2.7.x applications on Java 8: 15-20% throughput improvement
• Java 8 web applications: Up to 70% reduction in GC pause times
• Java 11 batch processing: 10-15% faster execution time 

More importantly, these improvements require no application code changes, no complex migration projects, and minimal operational changes—simply switching to a Fused JDK distribution delivers immediate benefits.

***

When considering a vendor of a Fused JDK, it’s important to test the distribution on your own application. Different builds can bring different performance benefits to different workloads. Another important thing to consider is vendor lock-in. Many Fused JDKs feature custom JVMs. This can be an obstacle when switching to the given JDK, but also when upgrading to newer versions of JDK when you decide to. Keep that in mind—we recommend sticking to fully open-source solutions as it gives you flexibility to adjust your stack in the future.

All in all, by leveraging Fused JDKs, organizations can extend the viable lifespan of legacy Java applications while significantly improving their performance and resource efficiency—truly a “legal dope” for the significant portion of enterprise Java that continues to run on older JDK versions.

Buildpacks: The Ultimate Alternative to Dockerfiles

While manually optimizing Dockerfiles and JVM settings yields significant benefits, Buildpacks offer even greater advantages with less effort. This technology eliminates the need to write Dockerfiles entirely, transforming your application source code directly into optimized container images.

Buildpacks streamline the process of building containerized applications while incorporating sophisticated JVM customizations and optimizations. They provide out-of-the-box support for advanced features like AppCDS and Native Images that would otherwise require significant expertise to implement.

Instead of writing and maintaining complex Dockerfiles, you can use the build system of your project, Maven or Gradle, and build a container image with a single command:

# A single command replaces your entire Dockerfile

mvn spring-boot:build-image

Or

gradle bootBuildImage

This simple command triggers a sophisticated workflow:

1. Detection Phase: The buildpack analyzes your codebase to identify the application type. It determines requirements and provisions for running the application.
2. Build Phase: The buildpack fulfills the contract by creating an optimized container image.

Zero-Configuration Performance Benefits

In most cases, buildpacks work without any configuration. By default, they use the latest version of optimized base images, automatically bringing performance improvements. For Spring Boot applications, Paketo buildpacks automatically create layered JARs with optimized structures for faster startup and reduced memory consumption. We discussed this earlier in this article. 

Buildpacks provide several quick fixes that you can easily leverage for immediate performance enhancements:

1. Automated Resource Calculation: One of the biggest advantages of buildpacks is their ability to properly calculate resources based on actual application needs.
2. Patch OS-Level Vulnerabilities Quickly: Buildpacks integrate seamlessly with modern CI/CD systems. Quickly rebuild your apps without advanced customization of your build tooling. With buildpacks in your CI, you can patch the OS layer of your app images without rebuilding your source code.
3. Standardized Optimization Approaches: Buildpacks enforce consistent optimization across your application portfolio. All applications receive the same level of optimization, while developers focus on code, not container configuration. As new JVM optimizations emerge, buildpacks incorporate them automatically.

Advanced Performance Tuning Made Simple

The true power of buildpacks becomes apparent when you need to take performance to the next level. Rather than learning dozens of JVM optimization flags, you can leverage buildpack capabilities through simple configuration. Here are a few examples: 

1/Optimize for Fast Startup:

# Enable AppCDS for faster startups
BP_JVM_CDS_ENABLED=true

2/ Switch to Native Image for Near-Zero Startup:

# For Spring Boot 3.x applications

./mvnw -Pnative spring-boot:build-image

***

While Dockerfiles remain the most common approach to containerization, buildpacks represent a more sophisticated, Java-aware solution. They embody years of JVM optimization expertise in an easy-to-use tool that consistently produces better results than manually created containers.

For most Java applications, the shift from Dockerfiles to buildpacks delivers immediate performance benefits with less effort, representing perhaps the simplest yet most effective quick wins available to teams today.

Building a Sustainable Optimization Strategy

Throughout this article, we’ve explored powerful quick wins for enhancing Java application performance without code changes. These optimizations create a virtuous cycle: improved performance yields resource savings, which can fund further optimization efforts and eventual modernization.

The optimal optimization approach depends on your current Java version:

JDK Version	First Tier	Second Tier	Third Tier	Migration Path
JDK 8	Fused JDKs (Liberica JDK Performance Edition) or Liberica JDK Lite	Container optimization		Test with Java 11
JDK 11	Fused JDKs (Liberica JDK Performance Edition) or Liberica JDK Lite	Container optimization	AppCDS	Validate with Java 17
JDK 17+	Container optimization, Generational ZGC/Shenandoah	CRaC, GraalVM or AppCDS	Project Lilliput, Buildpacks, Virtual Threads (JDK 21+)	Stay current with updates

Optimization vs. Alternatives

When facing performance challenges, organizations typically consider three approaches:

• Just Add Resources: Quick, but creates unsustainable cost escalation and masks real issues.
• Complete Rewrite: Addresses technical debt but involves high cost, risk, and time investment.
• Strategic Optimization: Delivers immediate benefits with lower cost and risk; creates breathing room for planned modernization.

The Sustainable Path Forward

The most effective and sustainable Java optimization strategy follows these principles:

1. Stay Current When Possible: Newer JDK versions include performance improvements by default
2. Optimize Before Scaling: Fix efficiency issues before adding more resources
3. Automate Optimization: Use buildpacks to democratize performance expertise
4. Measure Everything: Base decisions on data, not assumptions
5. Progressive Improvement: View optimization as a continuous journey

By applying these quick wins, even legacy Java applications can achieve dramatic performance improvements without the risk and cost of rewriting. This sustainable approach balances immediate performance needs with long-term architectural health, transforming your applications through evolution rather than revolution.