AWS lambda 和 Java 并发

Question

It is known that AWS lambda may reuse early created objects of handlers, and it really does it (see FAQ ):

Q: Will AWS Lambda reuse function instances?

To improve performance, AWS Lambda may choose to retain an instance of your function and reuse it to serve a subsequent request, rather than creating a new copy. Your code should not assume that this will always happen.

---

The question is regarding Java concurrency. If I have a class for a handler, say:

public class MyHandler {
    private Foo foo;
    public void handler(Map<String,String> request, Context context) {
       ...
    }
}

so, will it be thread-safe to access and work with the object variable foo here or not?

In other words: may AWS lambda use the same object concurrently for different calls?

EDIT My function is processed on an event based source, particularly it is invoked by an API Gateway method.

EDIT-2 Such kind of question rises when you want to implement some kind of connection pool to external resources, so I want to keep the connection to the external resource as an object variable. It actually works as desired, but I'm afraid of concurrency problems.

EDIT-3 More specifically I'm wondering: can instances of handlers of AWS lambda share common heap (memory) or not ? I have to specify this additional detail in order to prevent answers with listing of obvious and common-known things about java thread-safe objects.

Answer 1

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 the container for some time in anticipation of another Lambda function invocation. In effect, the service freezes the container after a Lambda function completes, and thaws the container for reuse, if AWS Lambda chooses to reuse the container when the Lambda function is invoked again. This container reuse approach has the following implications:

• 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 database connection, instead of reestablishing the connection, the original connection is used in subsequent invocations. You can add logic in your code to check if a connection already exists before creating one.

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

• Background processes or callbacks initiated by your Lambda function that did not complete when the function ended resume if AWS Lambda chooses to reuse the container. You should make sure any background processes or callbacks (in case of Node.js) in your code are complete before 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!".

Answer 2

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.

Answer 3

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.