Java Concurrency & Multithreading in Practice

Java's synchronized keyword is the oldest and most straightforward tool for making threads take turns when accessing shared resources. In this lecture, you will take the broken counter from a race condition scenario and fix it by adding synchronized to the increment method, then run the Java program again to see a correct, consistent result printed to the console. You will also explore synchronized blocks that lock on a specific object, giving you finer control over what gets locked and for how long. Understanding how intrinsic locks work in Java — including the fact that they are reentrant — is foundational knowledge that every Java developer working with concurrent code must have.

In Java, a thread might cache a variable's value and never see updates made by another thread — a problem known as a memory visibility issue. In this lecture, you will write a Java program where one thread sets a boolean flag to signal another thread to stop, and you will observe that without the volatile keyword the second thread may loop forever because it never sees the updated value. Adding volatile forces the JVM to read the variable from main memory every time, solving the visibility problem. You will see the difference in console output with and without volatile, and learn why volatile is perfect for simple flags but insufficient for compound operations like incrementing a counter in Java.

Sometimes synchronized feels like bringing a sledgehammer to hang a picture frame — Java's atomic classes in the java.util.concurrent.atomic package offer a lighter, lock-free alternative. In this lecture, you will rewrite a shared counter using AtomicInteger and its methods like incrementAndGet() and compareAndSet(), then run the Java program with multiple threads to verify that the final count is always correct. You will learn that atomic operations use hardware-level compare-and-swap (CAS) instructions under the hood, making them faster than locking in many scenarios. The console output will confirm correctness, and you will understand when to reach for AtomicInteger, AtomicLong, AtomicBoolean, and AtomicReference in your Java programs.

While synchronized is convenient, Java's ReentrantLock from java.util.concurrent.locks gives you superpowers like try-locking, timed locking, and interruptible lock acquisition. In this lecture, you will write a Java program that uses ReentrantLock to protect a shared resource, demonstrating the lock-try-finally pattern that ensures the lock is always released. You will also use tryLock() to attempt acquisition without blocking and print to the console whether the lock was obtained or not. By comparing ReentrantLock with synchronized in terms of flexibility and control, you will learn when the extra power of explicit locks justifies the extra responsibility of managing them manually in Java.

Many real-world Java applications have data that is read frequently but written rarely, and forcing every reader to wait behind a full exclusive lock is wasteful. In this lecture, you will use ReentrantReadWriteLock to allow multiple threads to read a shared value simultaneously while ensuring that writers get exclusive access. Your Java program will launch several reader threads and a writer thread, printing timestamps and thread names to the console so you can observe that readers run in parallel while the writer blocks them. This pattern is a significant performance optimization in Java applications where reads vastly outnumber writes, and understanding it will help you design more efficient concurrent data access strategies.

Creating a new thread for every task in Java is expensive and unscalable — thread pools solve this by reusing a fixed set of threads to execute many tasks. In this lecture, you will use Executors.newFixedThreadPool() to create a thread pool in Java, submit multiple Runnable tasks, and observe in the console output how a small number of threads handles a large number of jobs. You will also learn to shut down the pool gracefully using shutdown() and awaitTermination(). By printing the thread name inside each task, you will clearly see thread reuse in action, understanding why ExecutorService is the standard way to manage concurrency in production Java applications.

Runnable tasks in Java cannot return a value or throw a checked exception, but Callable can do both — and Future lets you retrieve the result when it is ready. In this lecture, you will write a Java program that submits several Callable tasks to an ExecutorService, each performing a computation and returning a result. You will use Future.get() to retrieve each result and print it to the console, observing how get() blocks until the result is available. You will also handle ExecutionException to see what happens when a Callable throws, giving you a complete picture of how Java's Future mechanism bridges the gap between asynchronous execution and synchronous result retrieval.

Sometimes you need a task to run after a delay or repeat at a fixed interval, and Java's ScheduledExecutorService is purpose-built for exactly that. In this lecture, you will write a Java program that schedules a one-time delayed task using schedule(), a fixed-rate repeating task using scheduleAtFixedRate(), and a fixed-delay repeating task using scheduleWithFixedDelay(). By printing timestamps to the console, you will see the precise timing behavior of each scheduling method and understand the subtle but important difference between fixed-rate and fixed-delay in Java. This is the tool you reach for whenever you need periodic execution without resorting to fragile Thread.sleep() loops.

When you need multiple Java threads to complete their work before a main thread proceeds, CountDownLatch provides an elegant coordination mechanism. In this lecture, you will write a Java program where several worker threads each perform a task and call countDown() when finished, while the main thread calls await() and blocks until the latch reaches zero. The console output will show each worker announcing its completion followed by the main thread proceeding only after all workers are done. CountDownLatch is a one-shot synchronization aid in Java — once the count reaches zero it cannot be reset — making it ideal for initialization gates, startup coordination, and fan-out-then-collect patterns.

Unlike CountDownLatch, Java's CyclicBarrier can be reused across multiple rounds, making it perfect for algorithms where threads must synchronize at the end of each phase before moving to the next. In this lecture, you will write a Java program that simulates a multi-phase computation where several threads do work, wait at the barrier, and then proceed together to the next phase. The console output will show each thread arriving at the barrier and the barrier tripping once all threads have arrived, repeating across phases. You will also provide a barrier action — a Runnable that executes each time the barrier trips — demonstrating how CyclicBarrier in Java enables clean, phased concurrent processing.

Unlike CountDownLatch, Java's CyclicBarrier can be reused across multiple rounds, making it perfect for algorithms where threads must synchronize at the end of each phase before moving to the next. In this lecture, you will write a Java program that simulates a multi-phase computation where several threads do work, wait at the barrier, and then proceed together to the next phase. The console output will show each thread arriving at the barrier and the barrier tripping once all threads have arrived, repeating across phases. You will also provide a barrier action — a Runnable that executes each time the barrier trips — demonstrating how CyclicBarrier in Java enables clean, phased concurrent processing.

Java's CompletableFuture takes asynchronous programming to an entirely new level by letting you chain, combine, and compose async tasks into expressive pipelines without blocking. In this lecture, you will write a Java program that uses supplyAsync() to kick off an asynchronous computation, thenApply() to transform the result, thenCombine() to merge results from two independent futures, and exceptionally() to handle errors — all printing intermediate and final results to the console. You will see how CompletableFuture in Java enables a fluent, callback-driven style of concurrency that is more readable and composable than manually juggling Future.get() calls, giving you a powerful tool for building responsive and efficient Java applications.

This lecture explains how Java started with java.lang.Thread and the synchronized keyword as its basic concurrency model, showing how threads are created, how synchronized blocks and methods enforce mutual exclusion, and the typical pitfalls developers faced with race conditions, deadlocks, and contention in early Java applications.

This lecture explores the operational and programming challenges of the thread-per-request approach, covering thread lifecycle cost, scalability limits, thread contention, debugging difficulty, and how these issues manifested in server-side and desktop Java before higher-level abstractions arrived.

This lecture outlines the JSR-133 overhaul of the Java Memory Model, describing happens-before semantics, visibility, atomicity guarantees, and how the new model clarified correct use of volatile, final, and synchronization to avoid subtle concurrency bugs across modern JVMs.

This lecture introduces core java.util.concurrent abstractions such as Locks, Atomic variables, CountDownLatch, Semaphore, and concurrent collections, explaining what problems each primitive solves and when to prefer these fine-grained tools over low-level synchronized code.

This lecture covers the Executor framework and various thread pool implementations, describing how executors decouple task submission from thread management, explain sizing strategies, task queues, rejection policies, and why controlled pooling improves throughput and resource use.

This lecture presents the ForkJoin framework and work-stealing algorithm, showing how divide-and-conquer tasks are expressed via RecursiveAction/RecursiveTask, when fork/join yields performance wins, and the trade-offs compared to fixed thread pools.

This lecture examines parallel streams in the Streams API, explaining how data-parallel operations use the common ForkJoinPool, what makes stream pipelines safe to parallelize (associativity, statelessness), and common gotchas like shared mutable state and ordering costs.

This lecture explores CompletableFuture for building nonblocking asynchronous flows, describing thenApply/thenCompose/handle, combining futures, performance and exception handling patterns, and how CompletableFuture enables callback-style composition without raw threads.

This lecture introduces the Reactive Streams ideas embodied by java.util.concurrent.Flow, explaining the Publisher-Subscriber-Subscription model, how backpressure protects consumers, and why streaming, nonblocking APIs became important for building resilient I/O-heavy systems.

This lecture walks through Project Loom’s virtual threads and structured concurrency proposals, describing how virtual threads make thread-per-request cheap, how structured scopes simplify lifecycle and cancellation, and what these changes mean for writing simpler, scalable concurrent Java code in cloud environments.

This lecture clears up the often-confused distinction between concurrency and parallelism by using everyday mental models: concurrency as structuring programs to manage multiple tasks (interleaving, coordination, responsiveness) and parallelism as actually executing multiple operations simultaneously on hardware; you’ll get intuitive examples of each and understand why a design can be concurrent without being parallel and vice versa.

This lecture contrasts latency (how fast a single request completes) with throughput (how many requests complete per unit time), explaining how optimization choices that reduce latency can harm throughput and how workloads like interactive services and batch processing require different trade-offs and priorities.

This lecture explores task granularity and the hidden costs of parallelism — task creation, scheduling, context switching, and communication overhead — and shows how small, fine-grained tasks can squander parallelism because overheads dominate useful work while coarse-grained tasks can leave resources underutilized.

This lecture examines contention and coordination costs from locks to cache coherence, describing how synchronization creates serialization, how shared-state contention limits scalability, and why phenomena like false sharing and convoying can dramatically reduce parallel speedups even when work is evenly distributed.

This lecture presents Amdahl’s Law and Gustafson’s Law as complementary ways to bound speedups: Amdahl’s highlights the limiting effect of the serial fraction on strong scaling, while Gustafson’s reframes scalability for growing problems, helping you reason about realistic expectations for parallel gains.

This lecture focuses on analyzing a workload as a graph of dependencies, showing how critical-path length, available parallel slack, and communication patterns determine achievable speedup and how different dependency shapes (embarrassingly parallel vs highly dependent) lead to radically different scaling behavior.

This lecture surveys high-level strategies for exploiting concurrency and parallelism — data parallelism, task parallelism, pipelining, and asynchronous concurrency — and explains how to match those approaches to the workload’s dependency profile, latency/throughput goals, and expected overheads.

This lecture breaks down what a modern CPU actually is: physical cores versus logical (SMT/hyper-threaded) contexts, how instruction pipelines and out-of-order execution extract instruction-level parallelism, and why a “core” is not the same as a single unit of work — you’ll learn how these hardware realities shape how many threads can run effectively at once and why raw core counts don’t tell the whole performance story.

This lecture explains the multi-level cache hierarchy (L1, L2, L3), the central role of fixed-size cache lines and alignment, and how caches bridge CPU and memory speed differences; you’ll get clear examples of how cache hits and misses affect latency and throughput and why careful data layout matters for performance even in high-level languages.

This lecture introduces cache coherence protocols like MESI and shows how they maintain a single, consistent view of memory across cores, describing the mechanics of state transitions and why coherence traffic can become a bottleneck under shared-memory contention.

This lecture focuses on false sharing and ping-ponging effects: how unrelated variables placed on the same cache line can cause excessive coherence traffic, degrade scalability, and produce counterintuitive slowdowns, with concrete scenarios that make the phenomenon easy to recognize in profiling output.

This lecture covers the DRAM side of performance: the difference between memory latency and bandwidth, how hardware prefetchers and access patterns influence throughput, and why sequential versus random access patterns lead to dramatically different performance characteristics for large datasets.

This lecture explains Non-Uniform Memory Access (NUMA) architectures: how CPU sockets have preferred local memory, how remote memory accesses incur higher latency and lower bandwidth, and why thread-to-memory locality and allocation policies can make or break performance at multicore and multi-socket scale.

This lecture unpacks the OS scheduler’s role: how threads are scheduled, what happens during a context switch and why it’s costly, how time slicing shapes latency and responsiveness, and the performance implications of frequent preemption and excessive runnable threads on throughput and cache locality.

This lecture explores tricky interactions between scheduling and concurrency: what priority inversion is and how it can stall critical work, what CPU affinity and thread pinning try to solve and the trade-offs they introduce, and how low-level synchronization primitives, atomics, and memory fences map to hardware operations that impact scalability.

This lecture gives a clear, high-level picture of the Java Memory Model: what problems it solves when threads interact through shared memory, the key concepts you’ll encounter (program order, synchronization order, and the model’s intent to define allowed behaviors), and how thinking in terms of formally defined guarantees prevents mistaken assumptions about what reads and writes will do on real JVMs and CPUs.

This lecture walks through the concrete happens-before edges you can rely on — program order, monitor lock release/acquire, volatile write/read, thread start/join, and transitivity — explaining how each edge creates a visibility guarantee between actions in different threads and why chaining these edges is the only safe way to reason about cross-thread communication.

This lecture separates the two often-confused properties of memory actions: visibility (when one thread’s write can be seen by another) and atomicity (whether an action happens indivisibly), showing examples where a read can see a stale value even though single reads/writes are atomic, and why compound operations like increment are not atomic without explicit synchronization or atomic classes.

This lecture unpacks volatile variables: what the language guarantees about visibility and ordering for volatile reads and writes, how those guarantees map to acquire/release style fences under the hood, and the practical limits of volatile (it is not a lock and does not make compound actions atomic), illustrated with clear examples of correct and incorrect uses.

This lecture explains the special semantics around final fields and why properly constructed immutable state can be safely published without synchronization, the “freeze” guarantees that prevent seeing partially constructed final fields, and the important caveat that escaping an object during construction can break these guarantees.

This lecture surveys the lower-level memory-ordering primitives available today — acquire/release semantics, full fences, and the VarHandle-style operations — describing conceptually how each fence type constrains compiler, JIT, and CPU reorderings and when you would think in terms of acquire/release versus a full barrier.

This lecture clarifies what kinds of compiler and CPU reorderings the Java Memory Model permits, gives intuitive examples of how reordering can produce surprising interleavings, and explains why the JMM must forbid “out-of-thin-air” reads even as it allows many reorderings, keeping the model usable but safe from nonsensical values.

This lecture highlights recurring concurrency mistakes tied to memory-model misunderstandings—check-then-act races, improper publication of mutable objects, incorrect double-checked locking prior to final-field fixes, and misuse of volatile—and shows how to recognize symptoms of these bugs and the mental checks to decide whether a piece of code is actually safe under the JMM.

This lecture walks through Java’s built-in monitor-based synchronization provided by the synchronized keyword and the JVM’s monitorenter/monitorexit mechanics, explaining reentrancy, mutual exclusion, the semantics of wait/notify, and the visibility guarantees synchronized blocks provide so you can read synchronized code with a clear mental model of what threads and monitors are doing.

This lecture examines java.util.concurrent.locks.ReentrantLock: how it differs from intrinsic locks, its reentrancy behavior, the fairness option and its throughput/latency trade-offs, tryLock and lockInterruptibly semantics, and when explicit locks expose control and diagnostics that synchronized does not.

This lecture compares monitor wait/notify with Condition objects exposed by explicit locks, detailing how condition queues work, the semantics of await/signal/signalAll, spurious wakeups and timed waits, and how explicit condition objects let you manage multiple waiting queues for finer-grained coordination.

This lecture explains ReadWriteLock semantics: how separate read and write modes enable greater concurrency for many-read, few-write workloads, how reentrancy and upgrade/downgrade policies behave, the fairness/ordering considerations, and the scenarios where read-write locking yields clear throughput wins or hidden pitfalls.

This lecture introduces StampedLock’s modes — write, read, and optimistic read — showing how optimistic reads provide low-overhead, speculative access with validation stamps, how stamped operations differ from traditional locks in usage and guarantees, and the correctness caveats that come with optimistic, stamp-based approaches.

This lecture peels back the JVM’s lock implementation: biased locking for uncontested fast paths, thin (stack) locks for lightweight synchronization, and inflation into heavy-weight monitors under contention, explaining what each state buys you in latency and where transitions can introduce unexpected pauses or costs.

This lecture explores how threads wait: busy spinning and adaptive spinning to avoid context switches versus parking (blocking) with LockSupport, the costs of context switches and cache warming, and how the runtime balances spinning and parking to trade CPU cycles for lower latency under different contention patterns.

This lecture surveys JIT and JVM optimizations that affect synchronization: lock elision via escape analysis, lock coarsening that merges adjacent locks for throughput, and other compiler-driven transforms that remove or alter synchronization, clarifying why some synchronized blocks disappear at runtime and what that implies for performance reasoning.

This lecture presents high-level strategies for reducing contention: partitioning and striping shared state, preferring immutable or thread-local data, using optimistic or read-biased approaches where appropriate, and recognizing when lock-free or lower-contention designs are better choices based on expected access patterns and scalability goals.

This lecture introduces compare-and-swap (CAS) as the atomic building block for lock-free algorithms, explaining how CAS replaces mutual exclusion by retrying on contention, what success/failure semantics look like, and why CAS-based loops are the natural mental model when reasoning about concurrent updates without locks.

This lecture explains the memory-ordering constraints that make lock-free algorithms correct: acquire/release semantics, full fences, and how fences prevent harmful compiler/CPU reorderings; you’ll learn which visibility guarantees are required around CAS and volatile reads/writes so that concurrent algorithms don’t observe stale or inconsistent state.

This lecture clarifies the formal progress properties used to classify concurrent algorithms—what it means for an operation to be wait-free, lock-free, or obstruction-free, the practical implications of each guarantee for latency and throughput, and how these guarantees influence algorithm choice under different contention profiles.

This lecture surveys java.util.concurrent.atomic primitives (AtomicInteger/Long/Reference, AtomicReferenceFieldUpdater), their semantics and typical idioms, and common performance pitfalls (hot counters, CAS hotspots) that motivate higher-level constructions instead of naive atomic updates.

This lecture unpacks the design of LongAdder and LongAccumulator: how striping and cell arrays reduce CAS contention on hot counters, how accumulation and read operations trade exactness for scalability, and when a patched, sharded counter is preferable to a single atomic variable in high-concurrency scenarios.

This lecture introduces VarHandle as the flexible, low-level memory-access API: how it exposes get/set/compareAndSet with programmable memory semantics, the different access modes (plain, opaque, acquire/release, volatile), and why VarHandle is the right tool when you need fine-grained control over ordering and atomicity beyond the higher-level atomics.

This lecture explains the ABA hazard that can foil CAS-based algorithms, shows why simple CAS can be fooled by value recycling, and describes common mitigations—tagged pointers, sequence numbers, hazard pointers, and epoch-based reclamation—so you can recognize when ABA might corrupt correctness and how to address it conceptually.

This lecture teaches linearizability as the standard correctness criterion for concurrent objects: how to identify linearization points, reason about histories and atomicity of operations, and use those concepts to argue that a lock-free or wait-free implementation preserves the illusion of atomic operations to callers.

This lecture traces the key design changes in ConcurrentHashMap—segmented locking to CAS-based binning, treeification to avoid degeneration, and lock-free reads with minimal synchronization—highlighting the core ideas that made concurrent maps both scalable and practical for real-world JVM workloads.

This lecture explores single-producer/single-consumer and multi-producer/single-consumer queue designs, the efficiency of circular ring buffers for cache-friendly handoffs, and the principles behind Disruptor-style patterns that minimize allocations and synchronization to deliver ultra-low-latency inter-thread messaging.

This lecture teaches you how ThreadPoolExecutor’s corePoolSize, maximumPoolSize, keepAliveTime, and the choice of work queue interact to determine throughput and latency; you’ll learn the trade-offs between bounded vs unbounded queues, how different RejectedExecutionHandler policies behave under overload, why thread factories matter for naming and uncaught exceptions, and practical sizing heuristics for CPU-bound versus I/O-bound tasks so you can reason about pool behavior without running experiments.

This lecture explains how ForkJoinPool implements work-stealing to maximize CPU utilization for divide-and-conquer tasks, what RecursiveTask/RecursiveAction lifecycles look like, how the common pool is used by default, and why blocking inside ForkJoin threads is dangerous unless you use ManagedBlocker; you’ll come away understanding when work-stealing delivers big gains and the runtime behaviors that can limit it.

This lecture shows how parallel streams use spliterators and the ForkJoin common pool to convert stream pipelines into parallel tasks, clarifies which stream operations are safe to parallelize (associative, stateless) versus those that introduce ordering or shared-state hazards, and highlights common gotchas—like hidden blocking, shared mutable reductions, and reliance on the common pool—that can make parallel streams backfire in production.

This lecture walks through composing asynchronous workflows with CompletableFuture: the difference between thenApply, thenCompose, and their async variants, how combining futures (allOf/anyOf) and exception-handling methods work, what executor choices the async overloads use by default, and how to reason about completion ordering, resource usage, and cancellation in composed nonblocking pipelines.

his lecture introduces the Publisher–Subscriber–Subscription model and backpressure semantics that Flow/Reactive Streams rely on, explaining request(n) driven consumption, how operators can propagate demand, the difference between hot and cold sources, and why backpressure is essential to prevent unbounded buffering and to design resilient streaming systems that adapt to consumer speed.

This lecture contrasts blocking thread-per-request designs with nonblocking and event-driven models, describing how blocking I/O consumes thread resources, why nonblocking I/O requires careful callback or reactive wiring, and how workload characteristics (latency sensitivity, I/O ratios, connection counts) determine whether a blocking, async, or hybrid approach will give the best resource-efficiency and simplicity trade-off.

This lecture explores how virtual threads make blocking operations cheap by decoupling user-visible threads from OS threads, how structured concurrency scopes provide lifetimes and coordinated cancellation for groups of tasks, and why treating virtual threads as lightweight, composable units can let you write simpler, imperative code for high-concurrency I/O workloads without the boilerplate of callbacks or reactive plumbing.

This lecture helps you spot and avoid frequent mistakes when mixing execution models: blocking work accidentally running on the ForkJoin common pool, CompletableFuture.async using an undersized pool, reactive pipelines that ignore backpressure, and virtual-thread assumptions violated by legacy thread-local or blocking primitives; you’ll learn diagnostic signals to watch for and conceptual checks to ensure composed systems behave predictably.