Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Runtime Java per istanze gestite Lambda

Per i runtime Java, le istanze gestite Lambda utilizzano i thread del sistema operativo per la concorrenza. Lambda carica l'oggetto gestore una volta per ambiente di esecuzione durante l'inizializzazione e quindi crea più thread. Questi thread vengono eseguiti in parallelo e richiedono una gestione thread-safe delle risorse statali e condivise. Ogni thread condivide lo stesso oggetto gestore e tutti i campi statici.

Configurazione della concorrenza

Il numero massimo di richieste simultanee che Lambda invia a ciascun ambiente di esecuzione è controllato dall'impostazione nella configurazione PerExecutionEnvironmentMaxConcurrency della funzione. Questa è un'impostazione opzionale e il valore predefinito varia a seconda del runtime. Per i runtime Java, l'impostazione predefinita è 32 richieste simultanee per vCPU, oppure è possibile configurare un valore personalizzato. Questo valore determina anche il numero di thread utilizzati dal runtime Java. Lambda regola automaticamente il numero di richieste simultanee fino al massimo configurato in base alla capacità di ciascun ambiente di esecuzione di assorbire tali richieste.

Creazione di funzioni per la multiconcorrenza

È necessario applicare le stesse pratiche di sicurezza dei thread quando si utilizzano le istanze gestite Lambda come si farebbe in qualsiasi altro ambiente multithread. Poiché l'oggetto handler è condiviso tra tutti i thread di runtime worker, qualsiasi stato mutabile deve essere thread-safe. Ciò include raccolte, connessioni al database e qualsiasi oggetto statico modificato durante l'elaborazione della richiesta.

AWS I client SDK sono thread-safe e non richiedono una gestione speciale.

Esempio: pool di connessioni al database

Il codice seguente utilizza un oggetto di connessione al database statico condiviso tra i thread. A seconda della libreria di connessioni utilizzata, questa potrebbe non essere thread-safe.

public class DBQueryHandler implements RequestHandler<Object, String> {
    // Single connection shared across all threads - NOT SAFE
    private static Connection connection;

    public DBQueryHandler() {
        this.connection = DriverManager.getConnection(jdbcUrl, username, password);
    }

    @Override
    public String handleRequest(Object input, Context context) {
        PreparedStatement stmt = connection.prepareStatement(query);
        ResultSet rs = stmt.executeQuery();
        // Multiple threads using same connection causes issues
        return result.toString();
    }
}

Un approccio thread-safe consiste nell'utilizzare un pool di connessioni. Nell'esempio seguente, il gestore di funzioni recupera una connessione dal pool. La connessione viene utilizzata solo nel contesto di una singola richiesta.

public class DBQueryHandler implements RequestHandler<Object, String> {

    private static HikariDataSource dataSource;

    public DBQueryHandler() {
        HikariConfig config = new HikariConfig();
        config.setJdbcUrl("jdbc:mysql://localhost:3306/your_database");
        dataSource = new HikariDataSource(config); // Create pool once per Lambda container
    }

    @Override
    public String handleRequest(Object input, Context context) {
        String query = "SELECT column_name FROM your_table LIMIT 10";
        StringBuilder result = new StringBuilder("Data:\n");

        // try-with-resources automatically calls close() on the connection,
        // which returns it to the HikariCP pool (does NOT close the physical DB connection)
        try (Connection connection = dataSource.getConnection();
             PreparedStatement stmt = connection.prepareStatement(query);
             ResultSet rs = stmt.executeQuery()) {

            while (rs.next()) {
                result.append(rs.getString("column_name")).append("\n");
            }

        } catch (Exception e) {
            context.getLogger().log("Error: " + e.getMessage());
            return "Error";
        }

        return result.toString();
    }
}

Esempio: collezioni

Le raccolte Java standard non sono thread-safe:

public class Handler implements RequestHandler<Object, String> {
    private static List<String> items = new ArrayList<>();
    private static Map<String, Object> cache = new HashMap<>();

    @Override
    public String handleRequest(Object input, Context context) {
        items.add("list item");  // Not thread-safe
        cache.put("key", input); // Not thread-safe
        return "Success";
    }
}

Utilizza invece raccolte thread-safe:

public class Handler implements RequestHandler<Object, String> {
    private static final List<String> items = 
        Collections.synchronizedList(new ArrayList<>());
    private static final ConcurrentHashMap<String, Object> cache = 
        new ConcurrentHashMap<>();

    @Override
    public String handleRequest(Object input, Context context) {
        items.add("list item");  // Thread-safe
        cache.put("key", input); // Thread-safe
        return "Success";
    }
}

Directory /tmp condivisa

La /tmp directory è condivisa tra tutte le richieste simultanee nell'ambiente di esecuzione. Le scritture simultanee sullo stesso file possono causare il danneggiamento dei dati, ad esempio se un altro processo sovrascrive il file. Per risolvere questo problema, implementate il blocco dei file per i file condivisi o utilizzate nomi di file univoci per thread o per richiesta per evitare conflitti. Ricordati di ripulire i file non necessari per evitare di esaurire lo spazio disponibile.

Registrazione dei log

L'interlacciamento dei log (le voci di registro di diverse richieste vengono interlacciate nei log) è normale nei sistemi multi-concorrenti.

Le funzioni che utilizzano Lambda Managed Instances utilizzano sempre il formato di registro JSON strutturato introdotto con controlli di registrazione avanzati. Questo formato includerequestId, che consente di correlare le voci di registro a una singola richiesta. Quando si utilizza l'LambdaLoggeroggetto, requestId viene incluso automaticamente in ogni voce di registro. context.getLogger() Per ulteriori informazioni, consulta Utilizzo dei controlli di registrazione avanzati Lambda con Java.

Contesto della richiesta

L'contextoggetto è associato al thread di richiesta. Using context.getAwsRequestId() fornisce un accesso thread-safe all'ID della richiesta corrente.

Utilizzare context.getXrayTraceId() per accedere all'ID di traccia X-Ray. Ciò fornisce un accesso thread-safe all'ID di traccia per la richiesta corrente. Lambda non supporta la variabile di _X_AMZN_TRACE_ID ambiente con Lambda Managed Instances. L'ID di traccia X-Ray viene propagato automaticamente quando si utilizza l'SDK. AWS

Se utilizzi thread virtuali nel tuo programma o crei thread durante l'inizializzazione, dovrai passare qualsiasi contesto di richiesta richiesto a questi thread.

Inizializzazione e spegnimento

L'inizializzazione della funzione avviene una volta per ambiente di esecuzione. Gli oggetti creati durante l'inizializzazione vengono condivisi tra i thread.

Per le funzioni Lambda con estensioni, l'ambiente di esecuzione emette un segnale SIGTERM durante lo spegnimento. Questo segnale viene utilizzato dalle estensioni per attivare attività di pulizia, come lo svuotamento dei buffer. È possibile sottoscrivere eventi SIGTERM per attivare attività di pulizia delle funzioni, come la chiusura delle connessioni al database. Per ulteriori informazioni sul ciclo di vita dell'ambiente di esecuzione, consulta Comprendere il ciclo di vita dell'ambiente di esecuzione Lambda.

Versioni di dipendenza

Lambda Managed Instances richiede le seguenti versioni minime del pacchetto:

Utensili elettrici per AWS Lambda (Java)

Powertools for AWS Lambda (Java) è compatibile con Lambda Managed Instances e fornisce utilità per la registrazione, il tracciamento, le metriche e altro ancora. Per ulteriori informazioni, vedere Powertools for AWS Lambda (Java).

Fasi successive