Java was built with a notion of running a server all the time. With serverless computing like AWS Lambda, that is not the case anymore, as they offer ephemeral compute. Therefore, we see some churn when running Java applications on Serverless.

In AWS Lambda, when a request comes in, the service checks if an execution environment is ready and available. If available, the service assigns the request to that execution environment and the code in the Lambda function handler gets executed. This is termed as a "Warm Start" as the execution environment was already available and warm. However, if an execution environment is not available, for example, the first request coming in, the service allocates a new execution environment. This involves downloading the Lambda function code to the execution environment, starting the runtime, initializing the function code, and then executing the code. This results in longer than normal response time and is termed as a “Cold Start.”

Java frameworks like Spring Boot often perform expensive operations during initial JVM startup time. Therefore, we witness a longer cold start time than any other Lambda runtime.

A Lambda execution environment supports only one request at a time. An execution environment processes a single request at the same time. While a single execution environment is processing a request, it cannot process other requests. Therefore, for another request a new execution environment will be needed, and therefore going through the initialization process again.

There are some interesting projects like Project CRaC and Project Leyden that you can follow which aims to address some of those challenges.

Meanwhile, there are best practices and built-in capabilities which AWS Lambda provides that you can incorporate to reduce cold start times compared to running on server-based compute options.