Use smaller basic images such as eclipse-temurin:17-jre-alpine or -slim to reduce volume; 2. Use multi-stage construction to separate compilation and run environments to avoid throwing the build tools and source code into the final image; 3. Optimize the JAR package itself, remove useless dependencies, enable compression, and consider Spring Boot hierarchical JAR; 4. Enable class data sharing (CDS) to reduce startup time and memory usage; 5. Adjust JVM containerization parameters such as -XX: UseContainerSupport and -XX:MaxRAMPercentage to adapt to container resource limitations; 6. GraalVM native mirroring can be used in scenarios with extremely high startup speed requirements, which significantly improves performance but increases construction complexity; combined use of the first five items can achieve good optimization results at low complexity, and native mirroring is suitable for cloud-native applications that are sensitive to cold start.

Optimizing Java Docker images isn't just about shrinking file sizes—it's about faster deployments, reduced attack surface, and quicker startup times, especially in cloud and serverless environments. Here's how to make your Java Docker images lender and more efficient.

1. Use a Smaller Base Image

The base image you choose has a massive impact on size. Traditional openjdk:17-jdk or openjdk:17 images are based on full Linux distributions like Debian and can be over 500MB.

Better options:

• eclipse-temurin:17-jre-alpine – Alpine Linux is tiny (~5MB base), and JRE-only reduces footprint.
• eclipse-temurin:17-jre-slim – Debian-based but stripped down. More compatible than Alpine, still much smaller than full JDK.

 # instead of:
# FROM openjdk:17
# Use:
FROM eclipse-temurin:17-jre-alpine

?? Note: Alpine uses musl instead of glibc , which can cause compatibility issues with some native libraries. If you hit issues, go with -slim instead.

2. Build and Run in Separate Stages (Multi-Stage Builds)

Avoid bundling build tools, source code, and dependencies into your final image.

 # Multi-stage: build with full JDK, run with JRE
FROM eclipse-temurin:17-jdk-alpine AS builder
WORKDIR /app
COPY . .
RUN ./gradlew build -x test

FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY --from=builder /app/build/libs/app.jar app.jar
CMD ["java", "-jar", "app.jar"]

This keeps the runtime image minimum—no Gradle, source files, or dev tools.

3. Optimize the JAR Itself

A fat JAR (uber-jar) with all dependencies included is convenient but can be bloated.

Tips:

• Remove unused dependencies – Use tools like dependency-check or manual review.
• Use Spring Boot's thin JAR (if applicable) – Offload dependencies to a shared layer.
• Enable JAR compression – Most build tools do this by default, but verify.

Pro tip: If using Spring Boot, consider Spring Boot 3.2 with container image support that layers JAR content for better Docker layer caching.

4. Enable Class Data Sharing (CDS)

Class Data Sharing allows the JVM to preload and memory-map core classes, reducing startup time and memory usage.

Generate a CDS archive during image build:

 FROM eclipse-temurin:17-jre-alpine
COPY app.jar /app.jar

# Generate CDS archive
RUN java -Xshare:dump -XX:ArchiveClassesAtExit=/app.jsa -jar /app.jar
# Or if you know the main class:
# RUN java -cp app.jar -Xshare:dump -XX:ArchiveClassesAtExit=/app.jsa com.example.Main

# Use CDS at runtime
ENTRYPOINT ["java", "-Xshare:auto", "-XX:SharedArchiveFile=/app.jsa", "-jar", "app.jar"]

This can cut startup time by 10–30%, especially for apps with many dependencies.

5. Tune JVM Settings for Containers

By default, the JVM may not respect container memory limits.

Add these flags:

 ENTRYPOINT ["java", \
  "-XX: UseContainerSupport", \
  "-XX:MaxRAMPercentage=75.0", \
  "-XshowSettings:vm", \
  "-jar", "app.jar"]

• UseContainerSupport lets JVM detect container limits.
• MaxRAMPercentage avoids over-allocating heap.

This prevents OOM kills and improves startup prediction.

6. Consider Native Images (GraalVM) for Extreme Optimization

For the fastest startup and smallest footprint, compile your Java app to a native binary using GraalVM Native Image .

Pros:

• Startup in million seconds.
• Smaller memory footprint.
• Smaller image (no JVM needed).

Cons:

• Longer build time.
• Limited reflection/dynamic classloading (requires configuration).
• Larger build image.

Example:

 # Build stage with GraalVM
FROM ghcr.io/graalvm/graalvm-jdk:17 AS builder
RUN gu install native-image
COPY . .
RUN native-image -jar app.jar

# Final stage
FROM alpine:latest
COPY --from=builder app /app
ENTRYPOINT ["./app"]

Best for microservices, serverless, or CLI tools where fast startup is critical.

Summary of Gains

Pick the right combo based on your needs. For most apps, slim base multi-stage CDS gives excellent results without complexity. For cloud-native services, GraalVM native is worth the investment.

Basically, don't ship a data center's worth of JDK just to run one JAR.

The above is the detailed content of Optimizing Java Docker Images for Smaller Size and Faster Startup. For more information, please follow other related articles on the PHP Chinese website!