AWS lambda and Java concurrency

May AWS lambda use same object concurrently for different calls?

Can instances of handlers of AWS lambda share common heap (memory) or not?

A strong, definite NO. Instances of handlers of AWS Lambda cannot even share files (in /tmp).

An AWS Lambda container may not be reused for two or more concurrently existing invocations of a Lambda function, since that would break the isolation requirement:

Q: How does AWS Lambda isolate my code?

Each AWS Lambda function runs in its own isolated environment, with its own resources and file system view.

The section "How Does AWS Lambda Run My Code? The Container Model" in the official description of how lambda functions work states:

After a Lambda function is executed, AWS Lambda maintains thecontainer for some time in anticipation of another Lambda functioninvocation. In effect, the service freezes the container after aLambda function completes, and thaws the container for reuse, if AWSLambda chooses to reuse the container when the Lambda function isinvoked again. This container reuse approach has the followingimplications:

• Any declarations in your Lambda function code remains initialized,providing additional optimization when the function is invoked again.For example, if your Lambda function establishes a databaseconnection, instead of reestablishing the connection, the originalconnection is used in subsequent invocations. You can add logic inyour code to check if a connection already exists before creating one.

• Each container provides some disk space in the /tmp directory. Thedirectory content remains when the container is frozen, providingtransient cache that can be used for multiple invocations. You can addextra code to check if the cache has the data that you stored.

• Background processes or callbacks initiated by your Lambda functionthat did not complete when the function ended resume if AWS Lambdachooses to reuse the container. You should make sure any backgroundprocesses or callbacks (in case of Node.js) in your code are completebefore the code exits.

As you can see, there is absolutely no warning about race conditions between multiple concurrent invocations of a Lambda function when trying to take advantage of container reuse. The only note is "don't rely on it!".

Taking advantage of the execution context reuse is definitely a practice when working with AWS Lambda (See AWS Lambda Best Practices). But this does not apply to concurrent executions as for concurrent execution a new container is created and thus new context. In short, for concurrent executions if one handler changes the value other won't get the new value.

As I see there is no concurrency issues related to Lambda. Only a single invocation "owns" the container. The second invocation will get an another container (or possible have to wait until the first one become free).

BUT I didn't find any guarantee the Java memory visibility issues cannot happen. In this case changes done by the first invocation could stay invisible for the second one. Or the changes of the first invocation will be written to RAM after the changes done by the second invocation.

In the most cases visibility issues are handled in the same way as concurrency issues. Therefore I would suggest to develop Lambda function thread-safe (or synchronized). At least as long as AWS won't give us a guarantee, that they do something on their side to flush CPU state to the memory after every invocation.