Lessons

How to create objects and manage classes on the fly: why Class.newInstance() is deprecated, how to correctly use getConstructor/ getDeclaredConstructor and Constructor.newInstance, invoke methods via Method.invoke, and read/modify fields via Field. We’ll cover typical exceptions ( ReflectiveOperationException and others), module system limitations, useful practices, and a small utility for dynamic instantiation. Plus — a visual diagram of the whole process.

In this lecture we examine practical reflection in Java: how to use Class, Field and Method to read private fields ( setAccessible( true)) and build a simple serializer; how DI containers inject dependencies by annotations ( @Inject, @Autowired) through constructors and fields; how dynamic proxies based on Proxy and InvocationHandler intercept calls; where this is used in practice ( Spring, JUnit, Jackson) and what limitations and errors you may encounter.

Why applications need logs, and why simply using System.out.println doesn’t save you in production. We’ll break down the levels ERROR/ WARN/ INFO/ DEBUG/ TRACE, the built-in stack java.util.logging and the settings file logging.properties, get acquainted with Log4j 2, Logback and the facade SLF4J. We’ll compare with console output, add dependencies, and dissect common configuration and usage mistakes.

We break down what makes a good log message (timestamp, level INFO/ ERROR, logger name, text, stack), how to format entries correctly using SLF4J/Log4j2 templates ( "{}" instead of concatenation), how to log exceptions ( logger.error(..., ex)), when to use levels ERROR/ WARN/ INFO/ DEBUG/ TRACE, as well as best practices: no sensitive data, clear messages, correlation IDs ( orderId, userId) and a solid log4j2.xml configuration.

How to make logs reliable in multithreading and on the web: thread safety of mature libraries ( Logback, Log4j 2, java.util.logging), MDC context with requestId propagation, integration with Spring filters and error handlers, how it differs from System.out, nuances of thread pools, and tracing in microservices (traceId, OpenTelemetry). We break down practical examples and common mistakes, using SLF4J and Logger as a static final field.

This lecture is a practical guide to monitoring the JVM: how to read standard metrics via JMX and JConsole, how to visually observe memory, threads, and profile methods in VisualVM (including heap dump and thread dump), and how to record a “black box” with Java Flight Recorder and analyze it in JDK Mission Control. We’ll show launch commands ( -XX:StartFlightRecording), walk through typical analysis scenarios for GC/threads, and common mistakes.

We explain how profiling differs from monitoring, which metrics matter (method execution time, memory, threads, locks), and which tools to use: VisualVM, Java Flight Recorder, as well as commercial profilers. In practice, we examine a “slow” calculator, learn to find hot spots, analyze a heap dump, and remove bottlenecks by replacing algorithms, reducing allocations, and caching. We wrap up with a visual diagram of the optimization process and an overview of common pitfalls.

Where local variables, objects, and class metadata go during JVM execution: we break down thread stacks, the heap, and the evolution from PermGen → Metaspace. We’ll talk about how GC works, what memory errors occur ( StackOverflowError, OutOfMemoryError), and how startup flags affect things ( -Xss, -Xmx, -XX:MaxMetaspaceSize). Diagrams, a Mermaid chart, and a working example are included.

In this lecture, we explore how the garbage collector ( GC) in the JVM works, how classic Serial/ Parallel/ CMS differ from modern G1, ZGC, and Shenandoah, what young and old generations are, why Stop-the-World pauses happen, and how to minimise them. In practice, we’ll see how to enable different GCs with flags ( -XX:+UseG1GC, -XX:+UseZGC, -XX:+UseShenandoahGC), tune pauses ( -XX:MaxGCPauseMillis) and heap sizes ( -Xms/ -Xmx), read logs ( -Xlog:gc*), and avoid common mistakes (for example, forcing a call to System.gc()).

From this lecture you’ll learn where local variables live (the thread stack) and how it differs from the heap, why memory leaks are still possible in Java despite the GC, and how to avoid them. We’ll break down real scenarios: “eternal” static-collections, unremoved listeners, and caches. We’ll get to know the reference family: SoftReference, WeakReference, PhantomReference, as well as the WeakHashMap container. We’ll practice fixing leaks and discuss why calling System.gc() is merely a hint to the JVM, not a command, and how it can end with an OutOfMemoryError.

A practical guide to diagnosing memory issues in the JVM: take a heap dump with jmap, read summaries via -heap and -histo, explore the application in jvisualvm (tabs Monitor, Heap Dump, Threads, Profiler), dissect a leak example, and get acquainted with Eclipse MAT and jconsole. In the end — common mistakes and tips.

A practical breakdown of why a Java application can leak memory and slow down: forgotten listeners ( addActionListener/ removeActionListener), everlasting static collections, unclosed resources (tip: try-with-resources), anonymous/inner classes retaining references, and abuse of System.gc(). We will learn to read GC logs ( -Xlog:gc*, -XX:+PrintGCDetails), choose a collector, build caches on WeakHashMap, monitor ( jvisualvm, jconsole), analyze a heap dump, and properly tune -Xmx/ -Xms. We’ll finish with real-world leak examples and their fixes.