Articles

JVM Startup Time: Cut Cold Start from Seconds to Milliseconds (2026)

April 18, 2026 6 min read

JVM startup time, especially for short-lived, frequently invoked functions, is often a bottleneck that’s surprisingly easy to optimize.

Let’s look at a common scenario: a serverless function written in Java that needs to respond to an API Gateway request.

// Example API Gateway Request
{
  "httpMethod": "GET",
  "path": "/users/123",
  "requestContext": { ... },
  "headers": { ... },
  "queryStringParameters": { ... },
  "body": null,
  "isBase64Encoded": false
}

When this request hits a cold JVM, the entire process — classloading, JIT compilation, initialization — has to happen before the function logic can even begin. This can easily add seconds to the response time.

// Typical flow for a cold start
1. Request received by Lambda/Serverless platform.
2. JVM instance initialized.
3. Application JARs loaded.
4. Classes loaded and linked.
5. Static initializers run.
6. JIT compilation of critical methods begins.
7. Application code executes.
8. Response returned.

The key to reducing this latency lies in pre-warming the JVM and its core components. This means preparing the environment so that when a request actually arrives, the heavy lifting is already done.

Pre-loading Classes

The JVM needs to load all necessary classes. This includes your application classes, framework classes (like Spring Boot or Quarkus), and even standard library classes. The more classes, the longer this takes.

Diagnosis: Use JVM flags like -XX:+PrintGCDetails and -XX:+PrintGCDateStamps to observe garbage collection activity during startup, which often correlates with classloading. More directly, you can use jcmd <pid> VM.native_memory summary to see memory usage broken down by type, including Class for loaded classes.

Fix:

  1. Ahead-of-Time (AOT) Compilation/Native Image: Tools like GraalVM Native Image compile your Java code directly into a native executable, eliminating JVM startup and classloading entirely.
    • Command: native-image --no-server --class-path your-app.jar --output your-app
    • Why it works: This bypasses the JVM’s dynamic classloading and JIT compilation at runtime, replacing it with static compilation.
  2. Early Class Initialization: For frameworks that allow it, configure them to initialize beans or components eagerly during application startup rather than lazily on first use.
    • Spring Boot Example: In your Spring configuration, use @Lazy(false) on beans that are frequently used and critical for initial request processing.
    • Why it works: Beans are instantiated and dependencies injected as soon as the application context is created, avoiding latency when they are first accessed.

JIT Compilation

The Just-In-Time (JIT) compiler translates bytecode into native machine code. While essential for performance, the initial compilation of frequently used methods adds overhead during startup.

Diagnosis: Use -XX:+TieredCompilation (which is usually on by default) and monitor JIT compilation activity with flags like -XX:+PrintCompilation. This will show which methods are being compiled and when.

Fix:

  1. Profile-Guided Optimization (PGO): Capture a profile of typical application execution and use it to guide the JIT compiler.
    • Command: Start the JVM with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder -XX:StartFlightRecording=filename=jit-profile.jfr,settings=profile. Then, run a representative workload. Stop the recording and use jcmd <pid> VM.get_vm_flags to see current flags.
    • Fix: Use the generated jit-profile.jfr file with a tool like jaotc (part of GraalVM) or configure the JVM to use the profile for more aggressive initial compilation. For standard JVMs, this is less direct; the JIT compiler will naturally optimize heavily used methods.
  2. Pre-JIT compilation: Some tools and frameworks can pre-compile critical methods.
    • GraalVM: Using GraalVM’s --compiler=server mode or generating native images can shift compilation earlier.
    • Why it works: By compiling methods before they are actually invoked for the first time in a request, you defer the CPU-intensive compilation work from the request path.

Static Initializers

Code within static initializer blocks (static { ... }) or static field assignments runs when a class is first loaded. If these blocks are complex or perform I/O, they can significantly slow down startup.

Diagnosis: Use -XX:+TraceClassLoading and -XX:+TraceClassInitialization to see when classes are loaded and initialized. You can also use a profiler to pinpoint time spent in static initializers.

Fix:

  1. Defer Initialization: Move logic out of static initializers into methods that are called explicitly when needed, or initialize static fields lazily.
    • Example: Instead of private static final Map<String, String> CONFIG = loadConfig(); where loadConfig is a complex static method, use a private static Map<String, String> CONFIG; and a getAndInitializeConfig() method that checks if CONFIG is null and initializes it on first call.
    • Why it works: This ensures that initialization only happens when the class is actually used, and that the initialization logic is performed within the context of a specific request or application lifecycle event, not during the general class loading phase.
  2. Optimize Static Logic: If static initialization is unavoidable, ensure it’s as fast as possible. Avoid network calls, disk I/O, or heavy computation.

JVM Tuning Flags

Certain JVM flags can impact startup performance, often by enabling or disabling features that trade startup time for runtime performance or memory usage.

Diagnosis: Examine your java command line. Look for flags related to compilation, garbage collection, and class data sharing.

Fix:

  1. AppCDS (Application Class-Data Sharing): This feature allows you to share common class metadata between JVM invocations, reducing classloading time.
    • Steps:
      1. Run with -Xshare:dump to create a class data archive.
      2. Start subsequent JVMs with -Xshare:on.
    • Why it works: The JVM pre-parses and stores class metadata, reducing the work needed for each JVM instance to load classes.
  2. Tiered Compilation: While often beneficial for overall throughput, in some very short-lived scenarios, disabling tiered compilation (-XX:-TieredCompilation) might reduce initial startup overhead by focusing on a single compilation tier. This is rare and usually detrimental to long-running applications.
    • Why it works: It simplifies the JIT compilation process, potentially making the initial compilation of a few critical methods faster, at the cost of overall peak performance.

Dependency Injection Frameworks

Frameworks like Spring Boot, Quarkus, or Micronaut have their own startup overhead. Their configuration, bean scanning, and initialization processes add to the JVM startup time.

Diagnosis: Profile your application startup. Tools like Spring Boot’s spring-boot-devtools can show startup times, and more advanced profilers can pinpoint framework-specific delays.

Fix:

  1. Quarkus/Micronaut: These frameworks are designed for fast startup and low memory footprint, often by using ahead-of-time (AOT) compilation and generating code at compile time.
    • Configuration: Ensure you are using their native image support or optimized build modes.
    • Why it works: They shift much of the framework’s initialization and configuration work from runtime to compile time.
  2. Spring Boot:
    • Lazy Initialization: Configure Spring to lazily initialize beans where appropriate, but eagerly initialize critical beans for your request path.
    • Native Images: Spring Native (and now Spring Boot 3 with GraalVM) can compile Spring applications into native executables.
    • Why it works: Optimizing the DI container’s startup sequence directly reduces the time before your application code is ready.

Container/Environment Overhead

If your JVM is running inside a container (like Docker) or on a platform with its own startup sequence (e.g., AWS Lambda), the overhead of the environment itself can contribute to perceived startup time.

Diagnosis: Measure the time from when the container/environment starts to when the JVM process is fully initialized and ready to accept requests.

Fix:

  1. Optimized Base Images: Use minimal, optimized base container images.
  2. Platform-Specific Optimizations: For serverless platforms, leverage features like provisioned concurrency (AWS Lambda) to keep JVM instances warm.
    • Why it works: Reducing the environmental setup and keeping instances warm means the JVM is already running and ready when a request arrives.

The next hurdle you’ll likely face is managing the memory footprint of a fully initialized, pre-warmed JVM instance, especially in resource-constrained environments.

Want structured learning?

Take the full Jvm course →