Lessons

Behavioral pattern “Observer”: roles Subject and Observer, subscribe/unsubscribe via addObserver/ removeObserver, and notification broadcasting with notifyObservers. We examine its connection to Java’s event model: button. addActionListener( listener) ; → call to actionPerformed(). Hands-on examples (thermometer and air conditioner, mini counter and lambdas), and also why java.util.Observable/ Observer are deprecated and what modern approaches exist.

In this lecture, we break down what the UI event-processing thread — EDT in Swing and its counterpart JavaFX Application Thread — is, why UI components are not thread-safe, and why the window “freezes” during heavy tasks. We will show the correct techniques: offloading computations to the background via new Thread(...), updating the UI using SwingUtilities.invokeLater and Platform.runLater, as well as using high-level tools like SwingWorker<T, V> and Task<V>/ Service<V> for progress, cancellation, and error handling.

Why programs need threads and parallelism: from a responsive interface to saturating all CPU cores. We’ll cover the difference between processes and threads, the role of the main thread main in the JVM, practical cases (UI, servers, file processing), and risks: race condition, deadlock, as well as basic synchronization tools like synchronized. We’ll show a simple example with Thread and running two tasks in parallel.

In this lecture, we examine starting threads in Java: we get to know the Thread class and the Runnable interface, learn to call start() correctly and not confuse it with run(), use anonymous classes and lambda expressions, start multiple threads, and look at the lifecycle ( NEW → RUNNABLE → TERMINATED). We’ll discuss methods like Thread.currentThread(), getName(), waiting via join(), and common mistakes such as IllegalThreadStateException.

We break down the thread lifecycle in Java: from Thread.State (

NEW

,

RUNNABLE

,

BLOCKED

,

WAITING

,

TIMED_WAITING

,

TERMINATED

) to the transitions between them. Learn to manage threads using Thread.sleep(...), join(), interrupt(), diagnose state via isAlive() and getState(), as well as avoid deprecated methods like stop()/ suspend()/ resume(). Finally — practical tips and common pitfalls.

How to safely pass parameters to threads via the constructor of a class that implements Runnable, when lambda expressions are appropriate, and why it’s better to make fields final. We examine thread priorities: methods setPriority/ getPriority, constants Thread.MIN_PRIORITY, Thread.NORM_PRIORITY, Thread.MAX_PRIORITY and their effect on the scheduler. Plus—naming threads via the constructor, setName/ getName, a practical example, and common mistakes (shared Runnable, setters, relying on priorities).

In this lecture, we break down what a race condition is: when multiple threads simultaneously access shared data and the result depends on scheduling order. Using the increment counter ++ as an example, we show why the operation is not atomic and how increments get lost. We examine a practical bank-account case, production consequences, and protection approaches: synchronized, atomic types from java.util.concurrent.atomic (for example, AtomicInteger), as well as immutability. We wrap up with a “Common mistakes” section explaining why Thread bugs are rarely caught by tests and why trying to “cure” them with Thread. sleep( 1) is pointless.

This lecture is about what a shared resource is in multithreaded applications, why race conditions and “lost updates” occur, and how to protect data using synchronized. We will cover basic synchronization techniques (methods and blocks), talk about modern tools from java.util.concurrent ( Lock, ReentrantLock, Semaphore, etc.), and look at practical examples with incrementing a counter and typical mistakes (non-atomic i ++, wrong lock object, myths about volatile).

A practical lecture on multithreading: we examine how the synchronized keyword works (blocks and methods, the object monitor, and class-level locking via ClassName.class), how visibility via volatile differs from operation atomicity, why it’s convenient to make boolean flags volatile, and why incrementing count ++ requires synchronization. We’ll compare when to choose synchronized and when — volatile, and go through common mistakes.

A practical comparison of classic synchronization via synchronized with more flexible primitives from the java.util.concurrent.locks package: ReentrantLock and ReadWriteLock. We will break down how to manage locks explicitly ( lock()/ unlock(), tryLock() with a timeout), how to scale reads using ReentrantReadWriteLock, what “fairness” ( fair mode) is, where each tool fits, and which mistakes are most common.

In this lecture, we will examine the key synchronization primitives in Java: how to protect critical sections using synchronized and the ReentrantLock class (methods lock()/ unlock(), the try- finally pattern), and how to limit parallelism with Semaphore (methods acquire()/ release()). We will compare a mutex and a semaphore in a table, look at practical cases (a bank, a server with a connection limit), and typical mistakes that lead to deadlock and performance loss.

A hands-on breakdown of common Java concurrency mistakes: forgetting unlock()/ release() with ReentrantLock and Semaphore (fixed via try- finally), choosing the wrong monitor for synchronized, deadlocks and lock acquisition order, over-synchronization, plus the limits of volatile and switching to AtomicInteger. Examples, tips, and clear analogies—so your code doesn’t grind to a halt.