💡 1. Transaktionssicherheit & Deadlock-Prävention
In verteilten Kernbankensystemen müssen Geldtransfers atomar und thread-sicher sein. Um Deadlocks zu vermeiden, müssen Kontosperren in deterministischer Reihenfolge gesetzt werden:
public class BankingService {
public boolean transferiere(Konto von, Konto nach, BigDecimal betrag) {
// Deadlock-Prävention durch konsistente Sperr-Reihenfolge (nach IBAN sortiert):
Konto ersteSperre = von.getIban().compareTo(nach.getIban()) < 0 ? von : nach;
Konto zweiteSperre = von.getIban().compareTo(nach.getIban()) < 0 ? nach : von;
synchronized (ersteSperre) {
synchronized (zweiteSperre) {
if (von.getSaldo().compareTo(betrag) < 0) return false;
von.abbuchen(betrag);
nach.einzahlen(betrag);
return true;
}
}
}
}Ein Immobilienkauf scheitert, wenn der Verkäufer das Geld nimmt, aber das Grundbuch nicht überschreibt. Das Bankensystem garantiert als unparteiischer Notar: Entweder wechseln Geld und Buchung gemeinsam den Besitzer, oder gar nichts passiert!
⚡ 2. Quick-Cheat-Sheet
| Anforderung | Lösungsmuster | Verhinderte Gefahr |
|---|---|---|
| Exakte Cent-Beträge | BigDecimal statt double | Gleitkomma-Rundungsfehler |
| Atomarer Transfer | Geschachtelte Sperren | Geldverlust bei Zwischenabsturz |
| Deadlock-Freiheit | Sortierte Lock-Hierarchie | System-Freeze bei Kreuzüberweisungen |
| Auditierbarkeit | Unveränderliche Transaktions-Records | Nachträgliche Datenmanipulation |
⚠️ 3. Häufige Stolperfallen (Gotchas & Anti-Patterns)
Verwende niemals double für Währungen! 0.1 + 0.2 ergibt 0.30000000000000004.
Sperrt Thread 1 Konto A dann B, und Thread 2 Konto B dann A, entsteht ein unlösbarer Deadlock. Sortiere Locks immer nach ID!
🧠 4. Diagnostischer Selbst-Check
Überprüfe dein Verständnis von Sprach-Features, Speicherverwaltung und Enterprise-Architektur, bevor du den Code in der Web-IDE schreibst.