Lektionen

Wie man Objekte erstellt und Klassen „on the fly“ verwaltet: warum Class.newInstance() veraltet ist, wie man getConstructor/ getDeclaredConstructor und Constructor.newInstance korrekt verwendet, Methoden über Method.invoke aufruft und Felder über Field liest/ändert. Wir betrachten typische Ausnahmen ( ReflectiveOperationException u. a.), Einschränkungen des Modulsystems, hilfreiche Praktiken und ein Mini‑Tool für dynamische Instanziierung. Plus – ein anschauliches Schema des gesamten Prozesses.

In dieser Vorlesung behandeln wir die Praxis der Reflection in Java: wie man über Class, Field und Method private Felder liest ( setAccessible( true)) und einen einfachen Serializer baut; wie DI-Container Abhängigkeiten anhand von Annotationen ( @Inject, @Autowired) über Konstruktoren und Felder injizieren; wie dynamische Proxys auf Basis von Proxy und InvocationHandler Aufrufe abfangen; wo das in der Praxis eingesetzt wird ( Spring, JUnit, Jackson) und welche Einschränkungen und Fehler auftreten.

Warum Anwendungen Logs benötigen und warum ein simples System.out.println im Produktivbetrieb nicht hilft. Wir besprechen die Level ERROR/ WARN/ INFO/ DEBUG/ TRACE, die eingebaute java.util.logging-API und die Konfigurationsdatei logging.properties, lernen Log4j 2, Logback und die Fassade SLF4J kennen. Wir vergleichen mit der Konsolenausgabe, binden Abhängigkeiten ein und analysieren typische Fehler bei Konfiguration und Verwendung.

Wir zerlegen, woraus eine gute Log‑Nachricht besteht (Zeit, Level INFO/ ERROR, Logger‑Name, Text, Stack), wie man Einträge korrekt über SLF4J/Log4j2‑Platzhalter formatiert ( "{}" statt Konkatenation), wie man Exceptions loggt ( logger.error(..., ex)), wann man die Level ERROR/ WARN/ INFO/ DEBUG/ TRACE verwendet, sowie Best Practices: keine sensiblen Daten, verständliche Nachrichten, korrelationsfähige IDs ( orderId, userId) und eine saubere Konfiguration log4j2.xml.

Wie man Logs in Nebenläufigkeit und im Web zuverlässig macht: Thread-Sicherheit der fertigen Bibliotheken ( Logback, Log4j 2, java.util.logging), der MDC-Kontext mit Übergabe von requestId, Integration mit Spring-Filtern und Fehler-Handlern, der Unterschied zu System.out, Besonderheiten von Thread-Pools und Tracing in Microservices (traceId, OpenTelemetry). Wir besprechen praxisnahe Beispiele und typische Fehler und verwenden SLF4J und Logger als static- final-Feld.

Diese Vorlesung ist ein praktischer Leitfaden zum Monitoring der JVM: wie man Standardmetriken über JMX und JConsole ausliest, wie man Speicher, Threads visuell beobachtet und Methoden in VisualVM profiliert (einschließlich heap dump und thread dump) sowie wie man die „Black Box“ mit Java Flight Recorder aufzeichnet und sie in JDK Mission Control auswertet. Wir zeigen Startkommandos ( -XX:StartFlightRecording), besprechen typische Analyse-Szenarien für GC/Threads und häufige Fehler.

Wir klären, worin sich Profiling von Monitoring unterscheidet, welche Metriken wichtig sind (Laufzeit von Methoden, Speicher, Threads, Sperren) und welche Tools man verwendet: VisualVM, Java Flight Recorder sowie kommerzielle Profiler. In der Praxis untersuchen wir einen „langsamen“ Rechner, lernen, „Hotspots“ zu finden, einen heap dump zu analysieren und Engpässe durch Algorithmuswechsel, weniger Allokationen und Caching zu beseitigen. Wir schließen mit einem visuellen Schema des Optimierungsprozesses und der Besprechung typischer Fehler.

Wohin gelangen lokale Variablen, Objekte und Klassen‑Metadaten im JVM‑Prozess: Wir schauen uns den Thread‑Stack, den Heap und die Evolution von PermGen → MetaSpace an. Wir sprechen darüber, wie der GC arbeitet, welche Speicherfehler es gibt ( StackOverflowError, OutOfMemoryError) und wie Start‑Flags ( -Xss, -Xmx, -XX:MaxMetaspaceSize) sich auswirken. Schaubilder, ein Mermaid‑Diagramm und ein lauffähiges Beispiel liegen bei.

In der Vorlesung besprechen wir, wie der Garbage Collector ( GC) in der JVM funktioniert, worin sich die klassischen Serial/ Parallel/ CMS von den modernen G1, ZGC und Shenandoah unterscheiden, was junge und alte Generation sind, warum Stop-the-World-Pausen auftreten und wie man sie minimiert. In der Praxis sehen wir uns an, wie man verschiedene GC per Flags aktiviert ( -XX:+UseG1GC, -XX:+UseZGC, -XX:+UseShenandoahGC), Pausen einstellt ( -XX:MaxGCPauseMillis) und die Heap‑Größe festlegt ( -Xms/ -Xmx), Logs liest ( -Xlog:gc*) und typische Fehler vermeidet (zum Beispiel erzwungener Aufruf von System.gc()).

Aus der Vorlesung erfahren Sie, wo lokale Variablen leben (Stack des Threads) und wie er sich vom Heap unterscheidet, warum in Java trotz GC doch Speicherlecks möglich sind und wie man sie vermeidet. Wir analysieren reale Szenarien: „ewige“ static-Collections, nicht abgemeldete Listener und Caches. Wir lernen die Referenzfamilie kennen: SoftReference, WeakReference, PhantomReference sowie den Container WeakHashMap. Wir üben, Lecks zu beheben, und besprechen, warum der Aufruf System.gc() – das ist nur ein Hinweis für die JVM und kein Befehl – und womit ein OutOfMemoryError enden kann.

Praktischer Leitfaden zur Diagnose von Speicherproblemen in der JVM: Wir erstellen einen Heap-Dump ( heap dump) mit dem Tool jmap, lesen Übersichten über -heap und -histo, untersuchen die Anwendung in jvisualvm (Tabs Monitor, Heap Dump, Threads, Profiler), analysieren ein Leak an einem Beispiel und machen uns mit Eclipse MAT und jconsole vertraut. Am Ende – häufige Fehler und Tipps.

Praxisnahe Analyse, warum eine Java-Anwendung „leakt“ und ausbremst: vergessene Listener ( addActionListener/ removeActionListener), ewige statische Collections, nicht geschlossene Ressourcen (Tipp: try-with-resources), anonyme/innere Klassen, die Referenzen halten, und Missbrauch von System.gc(). Wir lernen, GC-Logs zu lesen ( -Xlog:gc*, -XX:+PrintGCDetails), den passenden Collector zu wählen, Caches auf WeakHashMap zu bauen, zu monitoren ( jvisualvm, jconsole), Heap-Dumps zu analysieren und -Xmx/ -Xms richtig zu konfigurieren. Am Ende – reale Beispiele für Leaks und deren Behebung.