Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Java-Laufzeit für Lambda Managed Instances

Für Java-Laufzeiten verwenden Lambda Managed Instances Betriebssystem-Threads für Parallelität. Lambda lädt Ihr Handler-Objekt während der Initialisierung einmal pro Ausführungsumgebung und erstellt dann mehrere Threads. Diese Threads werden parallel ausgeführt und erfordern eine threadsichere Behandlung von Status- und gemeinsam genutzten Ressourcen. Jeder Thread verwendet dasselbe Handler-Objekt und alle statischen Felder.

Konfiguration der Parallelität

Die maximale Anzahl gleichzeitiger Anfragen, die Lambda an jede Ausführungsumgebung sendet, wird durch die PerExecutionEnvironmentMaxConcurrency Einstellung in der Funktionskonfiguration gesteuert. Dies ist eine optionale Einstellung, und der Standardwert variiert je nach Laufzeit. Für Java-Laufzeiten ist die Standardeinstellung 32 gleichzeitige Anfragen pro vCPU, oder Sie können Ihren eigenen Wert konfigurieren. Dieser Wert bestimmt auch die Anzahl der Threads, die von der Java-Laufzeit verwendet werden. Lambda passt die Anzahl der gleichzeitigen Anfragen automatisch bis zum konfigurierten Maximum an, basierend auf der Kapazität jeder Ausführungsumgebung, um diese Anfragen aufzunehmen.

Erstellung von Funktionen für Mehrfachparallelität

Sie sollten bei der Verwendung von Lambda Managed Instances dieselben Thread-Sicherheitspraktiken anwenden wie in jeder anderen Multithread-Umgebung. Da das Handler-Objekt von allen Runtime-Worker-Threads gemeinsam genutzt wird, muss jeder veränderbare Status threadsicher sein. Dazu gehören Sammlungen, Datenbankverbindungen und alle statischen Objekte, die während der Anforderungsverarbeitung geändert werden.

AWS SDK-Clients sind Thread-sicher und erfordern keine besondere Behandlung.

Beispiel: Datenbank-Verbindungspools

Der folgende Code verwendet ein statisches Datenbankverbindungsobjekt, das von Threads gemeinsam genutzt wird. Abhängig von der verwendeten Verbindungsbibliothek ist dies möglicherweise nicht threadsicher.

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();
    }
}

Ein threadsicherer Ansatz besteht darin, einen Verbindungspool zu verwenden. Im folgenden Beispiel ruft der Funktionshandler eine Verbindung aus dem Pool ab. Die Verbindung wird nur im Kontext einer einzelnen Anfrage verwendet.

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();
    }
}

Beispiel: Sammlungen

Standard-Java-Sammlungen sind nicht threadsicher:

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";
    }
}

Verwenden Sie stattdessen Thread-sichere Sammlungen:

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";
    }
}

Gemeinsames /tmp-Verzeichnis

Das /tmp Verzeichnis wird von allen gleichzeitigen Anfragen in der Ausführungsumgebung gemeinsam genutzt. Gleichzeitige Schreibvorgänge in dieselbe Datei können zu Datenbeschädigungen führen, z. B. wenn ein anderer Prozess die Datei überschreibt. Um dieses Problem zu lösen, implementieren Sie entweder Dateisperren für gemeinsam genutzte Dateien oder verwenden Sie eindeutige Dateinamen pro Thread oder pro Anfrage, um Konflikte zu vermeiden. Denken Sie daran, nicht benötigte Dateien zu bereinigen, um zu vermeiden, dass der verfügbare Speicherplatz aufgebraucht wird.

Protokollierung

Das Verschachteln von Protokollen (Protokolleinträge verschiedener Anfragen werden in Protokollen verschachtelt) ist bei Systemen mit mehreren gleichzeitigen Vorgängen normal.

Funktionen, die Lambda Managed Instances verwenden, verwenden immer das strukturierte JSON-Protokollformat, das mit erweiterten Protokollierungssteuerungen eingeführt wurde. Dieses Format beinhaltet dierequestId, sodass Protokolleinträge mit einer einzigen Anfrage korreliert werden können. Wenn Sie das LambdaLogger Objekt aus context.getLogger() verwenden, requestId ist es automatisch in jedem Protokolleintrag enthalten. Weitere Informationen finden Sie unter Erweiterte Lambda-Protokollierungssteuerelemente mit Java verwenden.

Kontext anfordern

Das context Objekt ist an den Anforderungsthread gebunden. context.getAwsRequestId()Die Verwendung ermöglicht einen threadsicheren Zugriff auf die Anforderungs-ID für die aktuelle Anfrage.

Wird verwendetcontext.getXrayTraceId(), um auf die X-Ray-Trace-ID zuzugreifen. Dies ermöglicht einen threadsicheren Zugriff auf die Trace-ID für die aktuelle Anfrage. Lambda unterstützt die _X_AMZN_TRACE_ID Umgebungsvariable bei Lambda Managed Instances nicht. Die X-Ray-Trace-ID wird bei Verwendung des AWS SDK automatisch weitergegeben.

Wenn Sie in Ihrem Programm virtuelle Threads verwenden oder während der Initialisierung Threads erstellen, müssen Sie den erforderlichen Anforderungskontext an diese Threads übergeben.

Initialisierung und Herunterfahren

Die Funktionsinitialisierung erfolgt einmal pro Ausführungsumgebung. Objekte, die während der Initialisierung erstellt wurden, werden von allen Threads gemeinsam genutzt.

Bei Lambda-Funktionen mit Erweiterungen gibt die Ausführungsumgebung beim Herunterfahren ein SIGTERM-Signal aus. Dieses Signal wird von Erweiterungen verwendet, um Bereinigungsaufgaben wie das Leeren von Puffern auszulösen. Sie können SIGTERM-Ereignisse abonnieren, um Aufgaben zur Funktionsbereinigung auszulösen, z. B. das Schließen von Datenbankverbindungen. Weitere Informationen zum Lebenszyklus der Ausführungsumgebung finden Sie unter Grundlegendes zum Lebenszyklus der Lambda-Ausführungsumgebung.

Versionen von Abhängigkeiten

Lambda Managed Instances erfordert die folgenden Mindestpaketversionen:

Powertools für AWS Lambda (Java)

Powertools for AWS Lambda (Java) ist mit Lambda Managed Instances kompatibel und bietet Dienstprogramme für Logging, Tracing, Metriken und mehr. Weitere Informationen finden Sie unter Powertools for AWS Lambda (Java).

Nächste Schritte