Senior Java Backend — Java-Backend-Interviewfragen

Wie würdest du ein Memory Leak in einem langlaufenden JVM-Service diagnostizieren?

Zuerst bestätigen, dass es überhaupt ein Leak ist: den Heap über Stunden nach vollständigen GCs beobachten, denn ein Sägezahn, der zur Baseline zurückkehrt, ist kein Leak. Dann einen Heap Dump ziehen und ihn in MAT öffnen, das den Dominator Tree zeigt — die Objekte mit dem meisten retained Memory und wer sie referenziert. Die üblichen Antworten sind ein unbegrenzter Cache, ein ThreadLocal, das auf einem gepoolten Thread nie geleert wird, oder Listener, die sich registrieren und nie wieder abmelden.

Wann würdest du eine Saga einer verteilten Transaktion vorziehen?

Fast immer, weil Two-Phase-Commit voraussetzt, dass jeder Teilnehmer es unterstützt, und Locks über das Netzwerk hinweg hält, was die Verfügbarkeit aller Services an den langsamsten koppelt. Eine Saga reiht lokale Transaktionen mit kompensierenden Aktionen aneinander, sodass jeder Service unabhängig committet und ein Fehler ein Undo auslöst. Der Preis ist, dass man die Kompensationen entwerfen muss, und es gibt Zustände, in denen ein Außenstehender eine teilweise Ausführung beobachten kann.

Was ändert Project Loom daran, wie man nebenläufigen Code schreibt?

Virtuelle Threads machen Blocking billig: Ein auf I/O wartender Thread belegt keinen OS-Thread mehr, sodass sich das Thread-pro-Request-Modell ohne reaktive Infrastruktur skalieren lässt. Die praktische Folge ist, dass CompletableFuture-Ketten und reaktive Stacks, die nur zur Vermeidung von Blocking eingeführt wurden, ihre Daseinsberechtigung verlieren. Was sich nicht ändert: synchronized-Blöcke können einen virtuellen Thread pinnen, und Thread-Pools, die für OS-Threads dimensioniert sind, werden zur falschen Abstraktion.

Wie entscheidest du zwischen GC-Tuning und dem Beheben von Allokationen?

Zuerst die Allokationsrate messen. Allokiert die Anwendung Gigabytes pro Sekunde, rettet keine Collector-Einstellung das, und der Fix gehört in den Code — Objekt-Churn in einer heißen Schleife, Boxing, defensive Kopien. GC-Tuning ist der richtige Hebel, wenn die Allokation angemessen ist, die Pausen aber das Latenzziel verfehlen; dann fällt die Wahl meist auf G1 mit einem Pausenziel oder auf ZGC, wenn der Heap so groß ist, dass selbst G1 nicht mehr mithält.

Ein Team will den Monolithen in Microservices aufteilen. Was fragst du, bevor du zustimmst?

Welches Problem das löst, das eine Modulgrenze nicht lösen kann. Unabhängige Deployments und unabhängige Skalierung sind echte Antworten, „Microservices sind modern" ist keine. Dann, ob das Team mit verteilten Daten umgehen kann — keine Joins über Services hinweg, Eventual Consistency und eine Saga für alles, was vorher eine einzige Transaktion war. Und ob der Betrieb das stemmen kann, denn zehn Services mit einer einzigen Pipeline und ohne Tracing sind schlimmer als der Monolith.

Wie hältst du eine große Java-Codebasis über LTS-Versionen hinweg upgradefähig?

Abhängigkeiten fortlaufend nah am aktuellen Stand halten statt in einem großen Projekt alle paar Jahre — die Kosten wachsen überlinear mit dem Rückstand. Reflection auf JDK-Internals vermeiden, denn genau das bricht bei der Module-Encapsulation. Eine Testsuite haben, der man genug vertraut, um einem grünen Lauf zu glauben, und auf einem Branch upgraden, der gegen beide Versionen baut, damit die Migration review-fähig ist statt ein Sprung ins Ungewisse.