Home on Study Notes

1. AtomicReference - Object Swapping

Fri, 27 Mar 2026 00:00:00 +0000

The Concept: While AtomicInteger works for primitives, AtomicReference<V> allows you to update a reference to an entire object as a single atomic unit. This is the foundation of “Immutable State” updates.

import java.util.concurrent.atomic.AtomicReference;

public class ConfigManager {
    // A shared configuration object that many threads read
    private final AtomicReference<Config> currentConfig = new AtomicReference<>(new Config("v1"));

    public void updateConfig(String newVersion) {
        Config oldConfig;
        Config newConfig = new Config(newVersion);

        do {
            oldConfig = currentConfig.get(); // Snapshot of the pointer
            // We don't modify oldConfig; we create a whole new one!
        } while (!currentConfig.compareAndSet(oldConfig, newConfig));
        
        System.out.println("Config updated to: " + newVersion);
    }
}

class Config {
    final String version;
    Config(String v) { this.version = v; }
}

Explanation:

Asynchronous, Non-Blocking IO - Thread-per-Core

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

In the previous “Thread-per-Task” model, if you have 8 CPU cores, but 1,000 threads, the CPU spends most of its time “Context Switching” (saving the state of Thread 1 to load Thread 2). This is inefficient.

The Thread-per-Core Goal: Create exactly one thread for every physical CPU core. These threads never block. If a thread needs to read from a socket and the data isn’t there, it doesn’t sleep; it moves to the next socket immediately.

Atomic Integers & Lock-Free E-commerce

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

In an e-commerce platform, the “Inventory Count” is the most contested variable.

The Problem with Locks: If 10,000 users try to buy an item, synchronized puts 9,999 threads to sleep while 1 thread works. The overhead of waking them all up is higher than the actual work of subtracting 1 from the inventory.
The Atomic Solution: AtomicInteger uses the CPU’s native ability to “reserve” a memory address for a nanosecond, update it, and release it without ever suspending a thread.

2. Comparison: Synchronized vs. AtomicInteger

Feature	`synchronized int`	`AtomicInteger`
Mechanism	Blocking (Pessimistic).	Lock-Free (Optimistic CAS).
Thread State	Threads become `BLOCKED`.	Threads stay `RUNNABLE` (Spinning).
Performance	High contention = slow.	High contention = fast (until CPU saturation).
Operations	Manual `count++` (3 steps).	Atomic `decrementAndGet()` (1 step).

3. The “Golden” Snippet: High-Traffic Inventory

This example simulates a flash sale where multiple threads attempt to decrease stock. It ensures we never sell more items than we have (Overselling) without using a single synchronized block.

Atomic Operations, Volatile, & Metrics

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

Traditional locking (synchronized) is “heavy.” It involves suspending threads, context switching, and OS overhead. Atomic Operations allow us to perform “Read-Modify-Write” cycles as a single, uninterruptible unit at the hardware level. The volatile keyword ensures that changes made by one thread are immediately visible to others, preventing “stale data” bugs caused by CPU caching.

2. Comparison: Volatile vs. Atomic vs. Synchronized

Feature	`volatile`	`AtomicInteger` / `AtomicLong`	`synchronized`
Visibility	Yes (Guarantees fresh data).	Yes (Guarantees fresh data).	Yes (Guarantees fresh data).
Atomicity	No (Doesn’t fix `count++`).	Yes (Fixes `count++`).	Yes (Fixes `count++`).
Locking	Lock-free.	Lock-free (uses CAS).	Blocking (uses Locks).
Performance	Extremely High.	High.	Medium/Low.

3. The “Golden” Snippet: Performance Metrics

Imagine a high-frequency trading app or a web server. We need to track the number of requests per second without slowing down the app with heavy locks.

Atomic References & Lock-Free Data Structures

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

If you want to update a complex object (like a User profile or a Node in a list) across multiple threads, you usually have to lock the entire object. AtomicReference allows you to swap an entire object reference atomically. It says: “Only change the pointer from Object A to Object B if the pointer is still pointing at Object A.”

2. Comparison: Synchronized Object vs. AtomicReference

Feature	`synchronized (obj)`	`AtomicReference<T>`
Safety	Prevents multiple threads from entering.	Prevents “stale” updates via CAS.
Blocking	Yes (Threads sleep).	No (Threads “spin” and retry).
Granularity	Locks the whole block of code.	Only protects the reference (the pointer).
Performance	High overhead for small updates.	Extremely fast for “pointer swapping.”

3. The “Golden” Snippet: A Lock-Free Stack

A standard Stack uses synchronized on push and pop. In this high-performance version, we use AtomicReference to manage the “Head” of the stack without any locks.

Condition Variables - Inter-Thread Communication

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

Sometimes a thread has the lock but cannot proceed because the data isn’t ready (e.g., a Consumer finds an empty queue).

The Problem: If the thread just loops (while(queue.isEmpty());), it wastes 100% of the CPU.
The Solution: The thread “waits” on a condition. This releases the lock and puts the thread to sleep. When another thread makes the condition true, it “signals” (notifies) the sleeping thread to wake up and try again.

2. Comparison: `wait/notify` vs. `Condition` Object

Feature	`Object.wait/notify`	`java.util.concurrent.Condition`
Association	Every Java Object has one.	Associated with a `ReentrantLock`.
Capability	Only one “wait set” per object.	Multiple conditions per lock (e.g., `notFull` and `notEmpty`).
Control	Standard `synchronized` blocks.	Precision control with `signal()` and `await()`.
Analogy	A single waiting room for a whole office.	Multiple specific waiting rooms (e.g., “Radiology” vs “ER”).

3. The “Golden” Snippet: Multi-Condition Producer-Consumer

Using Condition objects with ReentrantLock allows us to be very specific about which threads we wake up.

Critical Section & Synchronization

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

We need a way to make a sequence of operations Atomic (all-or-nothing). Since the CPU can interrupt a thread at any micro-instruction, we use Mutual Exclusion (Mutex). This ensures that if Thread A is halfway through an update, Thread B is physically blocked from starting that same update until Thread A finishes.

2. Visual Logic: The Monitor/Lock Concept

In Java, every Object has a built-in “Monitor” (or Intrinsic Lock). Think of it like a bathroom with a single key:

Deep Dive- Synchronization in Action

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

We use synchronization to prevent Data Corruption. Without it, two threads can “read” the same initial value, perform an operation, and “write” back their results, effectively overwriting each other. Synchronization forces these operations to happen one after the other (Sequentially) rather than at the same time (Concurrently).

2. Detailed Code Explanation

Let’s look at a common pattern: The Thread-Safe Counter.

public class Counter {
    private int count = 0;

    // The 'synchronized' keyword tells Java: 
    // "Only one thread can enter this method at a time using this specific object's lock."
    public synchronized void increment() {
        // Step 1: Read 'count' from Memory
        // Step 2: Add 1
        // Step 3: Write 'count' back to Memory
        this.count++; 
    }

    public synchronized int getCount() {
        return this.count;
    }
}

How the JVM executes this:

The Lock Acquisition: When Thread A calls increment(), it looks at the Counter object. Every object in Java has a Monitor. Thread A “grabs” the monitor.
The Exclusion: While Thread A is inside increment(), Thread B tries to call increment(). The JVM sees that Thread A holds the monitor. Thread B is put into a BLOCKED state (it stops executing and waits).
The Memory Barrier: When Thread A finishes, it “releases” the monitor. Crucially, it also flushes its changes to the Main Memory (Heap) so other threads can see the updated value.
The Hand-off: The JVM wakes up Thread B. Thread B now acquires the monitor and sees the updated value left by Thread A.

3. Finer-Grained Synchronization (The Block)

Sometimes, synchronizing an entire method is overkill. If your method is 100 lines long, but only 1 line touches the shared variable, you should use a Synchronized Block.

High-Performance IO with Virtual Threads

Fri, 27 Mar 2026 00:00:00 +0000

This section is the culmination of everything we’ve learned about IO. It explains how Virtual Threads allow us to write code that looks like the old “Thread-per-Request” model but performs like the “Asynchronous/NIO” model.

1. The “Why”

In the previous NIO (Non-Blocking) models, we had to break our logic into “callbacks” or “promises.” This made error handling and stack traces a nightmare. Virtual Threads change the game:

The Magic: When a Virtual Thread performs a blocking IO operation (like socket.read() or jdbc.executeQuery()), the underlying JVM unmounts the virtual thread from the physical OS thread (Carrier Thread).
The Result: The physical OS thread is now free to run another Virtual Thread while the first one waits for the network. No OS-level context switching occurs.

2. Comparison: NIO (Selectors) vs. Virtual Threads

Feature	NIO / Netty / Event Loop	Virtual Threads (Loom)
Code Style	Asynchronous / Reactive.	Synchronous / Procedural.
Stack Traces	Often fragmented and useless.	Complete and readable.
Debugging	Difficult (Step-through is hard).	Easy (Standard debugger works).
Scalability	High (Millions of connections).	High (Millions of connections).
Resource Usage	Low.	Low.

3. The “Golden” Snippet: The “Simple” High-Scale Server

This code looks exactly like a basic blocking server from 20 years ago, but it can handle 1,000,000 concurrent connections on a standard server.

Introduction to Blocking IO

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

Blocking IO is the “classic” way of handling data. When a thread asks the Operating System (OS) for data (like reading a 1GB file or waiting for a network packet), the OS puts that thread to sleep. The thread cannot do any other work until the data arrives.

The Problem: If you have 1,000 users and each requires a blocking thread, you need 1,000 threads. Threads are expensive—they consume memory (Stack) and cause “Context Switching” overhead.

2. Comparison: Blocking IO vs. Non-Blocking IO (NIO)

Feature	Blocking IO (BIO)	Non-Blocking IO (NIO)
Thread Behavior	Thread “stops” and waits for data.	Thread “asks” and moves on if data isn’t ready.
Efficiency	High for single, long-lived connections.	High for thousands of concurrent connections.
Complexity	Simple (Sequential code).	High (Requires Event Loops/Callbacks).
Scalability	Limited by Thread Count / Memory.	Limited by CPU / Network Bandwidth.

3. The “Golden” Snippet: The Standard Blocking Server

This is a classic “One Thread Per Connection” model. It works fine for a few users, but it scales poorly.

Introduction to Non-Blocking & Lock-Free Operations

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

Traditional locks (synchronized, ReentrantLock) have major downsides:

Deadlocks: Threads waiting for each other forever.
Priority Inversion: A low-priority thread holding a lock prevents a high-priority thread from running.
Performance Overhead: Suspending and resuming a thread (context switching) is expensive for the OS.

Lock-Free operations use hardware-level atomic instructions to ensure that at least one thread always makes progress, even if others are interrupted or fail.

2. Comparison: Blocking vs. Lock-Free (Non-Blocking)

Feature	Blocking (Locks)	Lock-Free (Non-Blocking)
Philosophy	“Pessimistic” - Assume trouble and lock the door.	“Optimistic” - Assume success and retry if failed.
Hardware Tool	Mutex / Monitors.	CAS (Compare-And-Swap) instructions.
Deadlock Risk	High.	Zero.
Throughput	Limited by lock contention.	High (Scales better with more CPU cores).
Complexity	Simple to write and reason about.	Extremely difficult to design correctly.

3. The “Golden” Snippet: Atomic Compare-And-Swap (CAS)

The heart of every lock-free algorithm is the CAS operation. It is a single CPU instruction that says: “If the value in memory is X, change it to Y. If it’s not X anymore, don’t do anything and tell me I failed.”

Introduction to Performance & Optimization for Latency in Threads

Fri, 27 Mar 2026 00:00:00 +0000

Introduction to Performance & Optimization for Latency

1. The “Why”

In a single-threaded environment, tasks are executed sequentially, meaning the total time is the sum of all tasks. We use multithreading for Latency Optimization to break a single intensive task into smaller sub-tasks that run in parallel, reducing the wall-clock time the user has to wait for a result.

2. Visual Logic

The goal is to move from a “Serial” execution to a “Parallel” execution. If a task can be decomposed, we distribute the workload across multiple CPU cores.

Introduction to Virtual Threads (Project Loom)

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

Until now, we had two choices:

Platform Threads (BIO): Easy to write, but expensive. 1,000 threads = 1GB RAM. You run out of memory quickly.
Asynchronous (NIO): Scales to millions, but “Callback Hell” makes it incredibly hard to write, debug, and read.

Virtual Threads give you the best of both worlds: You write simple, blocking code (like in the 90s), but the JVM magically handles it like a high-performance Asynchronous system under the hood.

Locking Strategies & Deadlocks

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

As applications grow, a single lock (like synchronized(this)) becomes a bottleneck. To improve performance, we use Fine-Grained Locking (multiple locks for different resources). However, the moment you have more than one lock, the Order of Acquisition matters. If two threads try to acquire the same two locks in a different order, they can end up in a Deadlock.

2. Comparison: Coarse-Grained vs. Fine-Grained Locking

Feature	Coarse-Grained	Fine-Grained
Simplicity	High (One lock for everything).	Low (Many locks to manage).
Performance	Low (Threads queue up unnecessarily).	High (Threads only block if using the same resource).
Risk of Deadlock	Zero (You can’t deadlock with one lock).	High (Requires strict discipline).
Example	`synchronized(database)`	`lockTableA`, `lockTableB`

3. The “Golden” Snippet: The Deadlock Trap

In this example, two threads are trying to transfer money between two accounts. Each account has its own lock.

Objects as Condition Variables - wait, notify, & notifyAll

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

Every Java object has an Intrinsic Lock (the monitor). Along with that lock, every object maintains a Wait Set—a list of threads that are suspended and waiting for a signal related to that object. This allows threads to communicate without using complex external libraries, using only the objects they are already synchronizing on.

2. Comparison: `wait/notify` vs. `Condition` Objects

Feature	`wait()` / `notify()`	`Condition` (`await/signal`)
Origin	Part of `java.lang.Object` (Available since JDK 1.0).	Part of `java.util.concurrent` (Added in JDK 1.5).
Locking	Works with `synchronized` blocks.	Works with `ReentrantLock`.
Wait Sets	Only one per object.	Multiple per lock (e.g., `notFull`, `notEmpty`).
Efficiency	`notifyAll()` wakes everyone, even if they can’t proceed.	`signal()` can target specific groups of threads.

3. The “Golden” Snippet: Classic Producer-Consumer

In this version, we don’t need a ReentrantLock. We use the synchronized keyword and the shared object itself to coordinate.

Parallel Streams & ForkJoinPool

Fri, 27 Mar 2026 00:00:00 +0000

This section transitions from IO-bound concurrency (waiting for databases or networks) back to CPU-bound efficiency. If you have a massive dataset—like 10 million rows of sales data—and you need to calculate the total tax, you don’t want to use one CPU core while the other 15 sit idle.

1. The “Why”

Modern CPUs are “Multi-core.” A standard for loop or a sequential Stream in Java only uses one thread. To use all your hardware’s power, you need to split the data into chunks, process them simultaneously, and then merge the results.

Race Conditions vs. Data Races

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

A Race Condition is a flaw in the timing or ordering of events that leads to incorrect program behavior. A Data Race is a technical memory issue where two threads access the same memory location concurrently, and at least one access is a write, without any synchronization.

You can have a Race Condition without a Data Race, and a Data Race without a Race Condition. You want to avoid both.

Recursive Task

Fri, 27 Mar 2026 00:00:00 +0000

While Parallel Streams are the “automatic transmission” of the ForkJoinPool, RecursiveTask is the “manual transmission.” It gives you full control over how a large problem is sliced into smaller pieces and how those pieces are joined back together.

It is the core class you extend to implement the Divide and Conquer strategy for tasks that return a result.

1. The “Why”

Sometimes your data doesn’t fit into a simple Stream. For example, if you are:

ReentrantLock - tryLock & Interruptibility

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

ReentrantLock is a manual alternative to synchronized. We use it when we need to break Coffman’s Conditions for deadlocks. Specifically:

Breaking “No Preemption”: With tryLock(), if a thread can’t get the lock, it can walk away instead of hanging.
Breaking “Uninterruptible Wait”: With lockInterruptibly(), we can stop a waiting thread externally using thread.interrupt().

2. Comparison: `synchronized` vs. `ReentrantLock`

Feature	`synchronized`	`ReentrantLock`
Flexibility	Low (Block-scoped only).	High (Can start lock in one method, end in another).
Fairness	No (Random thread gets the lock).	Optional (Can grant lock to the longest-waiting thread).
Timeout Support	No (Waits forever).	Yes (`tryLock`).
Interruptibility	No (Cannot be interrupted while waiting).	Yes (`lockInterruptibly`).
Syntax	Simple (Automatic cleanup).	Complex (Requires manual `unlock()` in a `finally` block).

3. The “Golden” Snippet: The Safe Transfer (No Deadlock)

This snippet uses tryLock() to attempt to acquire two locks. If it fails to get the second one, it “preempts” itself by releasing the first one and trying again later.

ReentrantLock - UI Application Example

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

In a UI application, responsiveness is king. If a background thread is performing a heavy database update or image processing, we don’t want the UI to “hang” while waiting for that data. ReentrantLock with tryLock() allows the UI thread to check: “Is the data ready? No? Okay, I’ll keep the loading spinner spinning and try again in the next frame.”

2. Comparison: Blocking vs. Non-Blocking UI

Feature	`synchronized` (Blocking)	`ReentrantLock.tryLock()`
User Experience	App freezes (Not Responding) until lock is free.	App remains responsive; can show a “Busy” message.
Thread Behavior	UI Thread is suspended by the OS.	UI Thread continues its loop, handling other clicks.
Timeout Support	None.	Can try for $X$ milliseconds and then give up.

3. The “Golden” Snippet: The Responsive UI

Imagine a Dashboard that updates every second. If the “Database Thread” is currently writing to the shared PriceData object, the UI thread shouldn’t wait; it should just skip this update or show the old data.

ReentrantReadWriteLock & Database Implementation

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

Standard locks (synchronized, ReentrantLock) are Mutual Exclusion locks—they don’t care if a thread is reading or writing; they block everyone else. ReentrantReadWriteLock recognizes that multiple threads reading the same data simultaneously is perfectly safe. It only enforces “Mutual Exclusion” when a thread needs to write (modify) the data.

2. Comparison: ReentrantLock vs. ReadWriteLock

Feature	`ReentrantLock`	`ReentrantReadWriteLock`
Read/Read	Blocking (One at a time).	Non-Blocking (Infinite simultaneous readers).
Read/Write	Blocking.	Blocking (Reader waits for Writer).
Write/Write	Blocking.	Blocking (Only one Writer at a time).
Best Use Case	General purpose, frequent updates.	Databases, Caches, “Read-Heavy” metadata.

3. The “Golden” Snippet: A Simple Database

In this example, we create a SimpleDatabase where many threads can query prices at the same time, but an update thread can safely modify them without causing data races.

Resource Sharing & Critical Sections (Deep Dive)

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

In multithreading, a Critical Section is any segment of code that accesses a shared resource (like a variable, a file, or a database connection) where at least one thread is performing a write operation.

The problem is that most high-level operations (like count++) are not atomic. To the CPU, count++ is actually three distinct steps:

Load: Move the value from the Main Memory (Heap) into a CPU Register.
Increment: Add 1 to the value inside the Register.
Store: Move the new value from the Register back to Main Memory.

If Thread A is “paused” (context-switched) after Step 2, and Thread B performs all three steps, Thread A will eventually wake up and overwrite Thread B’s work with an outdated value. This is a Race Condition.

Semaphore - Scalable Producer-Consumer

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

A standard Mutex or synchronized block only allows one thread at a time. A Semaphore, however, maintains a set of permits.

It is used to limit the number of concurrent threads accessing a specific resource (e.g., only 5 database connections allowed).
In a Producer-Consumer scenario, we use it to signal when “Space is Available” (for the producer) and when “Items are Available” (for the consumer).

2. Comparison: Mutex vs. Semaphore

Feature	Mutex (or Binary Semaphore)	Counting Semaphore
Permit Count	Exactly 1.	$N$ (User-defined).
Ownership	Only the thread that locked it can unlock it.	No ownership. Any thread can release a permit.
Primary Use	Protecting a Critical Section (Safety).	Signalling and Resource Throttling (Coordination).
Analogy	A bathroom with one key.	A parking lot with $N$ spots.

3. The “Golden” Snippet: Semaphore-Based Producer-Consumer

This implementation uses two semaphores to coordinate a shared buffer. One tracks “Full” slots and the other tracks “Empty” slots.

Stack vs. Heap Memory Regions

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

In a multithreaded application, we need to know where data lives to understand its visibility. If data is on the Stack, it is private and safe. If data is on the Heap, it is shared and potentially dangerous. This distinction determines whether we need synchronization (locks/mutexes) or if the code is “thread-safe” by design.

2. Visual Logic

Every thread gets its own private Stack, but all threads share a single, massive Heap.

The 4 Conditions for Deadlock (Coffman’s Conditions)

Fri, 27 Mar 2026 00:00:00 +0000

1. Mutual Exclusion

Only one thread can have exclusive access to a resource at any given time. If a second thread tries to access that resource, it must wait until the first thread releases it.

The Problem: If resources were sharable (like a Read-Only file), there would be no waiting and no deadlock.

2. Hold and Wait

A thread is already holding at least one resource and is waiting to acquire additional resources that are currently being held by other threads.

Thread Per Task / Thread Per Request Model

Fri, 27 Mar 2026 00:00:00 +0000

1. The “Why”

In a standard web application, a “task” is usually a single HTTP request.

The Goal: Isolate users from each other. If User A’s request takes 10 seconds to process a heavy database query, User B should still get their response in 100ms on a different thread.
The Implementation: The server maintains a “Thread Pool.” When a request arrives, the “Boss” thread grabs a “Worker” thread from the pool, hands it the socket, and says, “Call me when you’re done.”

2. Comparison: One Thread vs. Thread Pool (Thread-Per-Task)

Feature	Single Threaded	Thread-Per-Task (Pool)
Concurrency	None (One at a time).	High (N tasks at a time).
Isolation	One crash kills the server.	One crash only kills that thread.
Throughput	Very Low.	High (Parallel processing).
Blocking	One slow DB call stops everyone.	Only that specific worker thread is blocked.

3. The “Golden” Snippet: Executor-Based Web Server

Instead of creating a new Thread() every time (which is slow), we use a FixedThreadPool to reuse existing threads.

UseCase Scenario For Reentrant & ReentrantReadWrite Lock

Fri, 27 Mar 2026 00:00:00 +0000

The choice between a standard ReentrantLock and a ReentrantReadWriteLock usually comes down to one metric: the Read-to-Write ratio.

If your threads are mostly looking at data without changing it, a standard lock creates a massive, unnecessary bottleneck. If your threads are constantly updating data, the overhead of a ReadWriteLock actually makes it slower than a simple lock.

1. Scenario A: High-Contention Updates (Use `ReentrantLock`)

Scenario: A Counter or a Bank Account where every single thread that enters is there to modify the value (e.g., increment() or deposit()).

Virtual Threads - Best Practices

Fri, 27 Mar 2026 00:00:00 +0000

1. Don’t Pool Virtual Threads

The Old Rule: Threads are expensive; create a FixedThreadPool and reuse them. The New Rule: Virtual threads are disposable objects. Create a new one for every single task.

Why? A pool’s purpose is to limit resource usage and avoid the cost of thread creation. Since Virtual Threads cost almost nothing to create and take up very little memory, pooling them just adds unnecessary complexity and contention.

// DO THIS (New for every task)
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> doWork());
}

// DON'T DO THIS (Pooling virtual threads is an anti-pattern)
// ExecutorService pool = Executors.newFixedThreadPool(100);

2. Avoid “Pinning” (Replace `synchronized`)

As we discussed, Pinning happens when a Virtual Thread cannot be “unmounted” from its Carrier Thread during a blocking operation. This usually happens inside synchronized blocks.

Virtual Threads - Deep Dive

Fri, 27 Mar 2026 00:00:00 +0000

To understand what Virtual Threads do under the hood, we have to look at the “Magic” that happens between the Java code you write and the Operating System (OS) that actually executes it.

Before Java 21, a Java Thread was just a thin wrapper around an OS Thread. If you created 1,000 Java threads, the OS had to manage 1,000 stacks, which is why your memory would spike.

1. The Architecture: M:N Scheduling

Virtual Threads introduce a “layered” approach. Instead of a 1:1 relationship with the OS, we now have an M:N relationship.

Joining Threads

Thu, 26 Mar 2026 00:00:00 +0000

Thread Coordination - Part 2: Joining Threads

1. The Problem: The “Race” to the Finish

When you start a thread, it runs independently. If the main thread needs the result of Thread-A to perform a calculation, main might finish before Thread-A even starts, leading to null results or crashes.

2. The Solution: `thread.join()`

The join() method allows the calling thread (e.g., main) to go into a Waiting state until the target thread finishes its execution.

Thread Inheritance

Thu, 26 Mar 2026 00:00:00 +0000

Thread Creation - Part 2: Thread Inheritance

1. The Concept: Extending the Thread Class

Instead of passing a Runnable object to a new Thread instance, we create a specialized class that is a Thread. This is done using the extends keyword.

Mechanism: Create a subclass of Thread and override the run() method.
Usage: You instantiate your subclass and call .start().

2. The “Golden” Snippet (Inheritance Pattern)

This approach encapsulates the thread logic and the data it needs into a single object.

Thread Introduction

Thu, 26 Mar 2026 00:00:00 +0000

Thread Creation Part 1 Capabilites & Debugging

1. Core Concept: Thread vs. Process

Before diving into code, it is vital to understand the “Container” relationship:

Process: An instance of a running program. It has its own memory space (Heap, Stack, etc.).
Thread: A unit of execution within a process. Multiple threads share the same Heap but have their own Stack.

2. Thread Capabilities

Threads allow us to perform multiple tasks concurrently. Key capabilities include:

Thread Termination & Daemon Threads

Thu, 26 Mar 2026 00:00:00 +0000

Thread Termination & Daemon Threads

1. Why is Termination Tricky?

Threads consume resources (Memory, CPU, File Handles). If a thread finishes its task but stays alive, it’s a Resource Leak.

We cannot use the stop() method (it is deprecated and dangerous).
We must use Cooperative Termination.

2. Method 1: The Interrupt Signal

Interrupting is a way for one thread to signal another: “Please stop what you are doing.”

Scenario A: Thread is Blocking (Sleeping/Waiting)

If a thread is executing a method like Thread.sleep() or wait(), it will throw an InterruptedException when interrupted.

Mon, 01 Jan 0001 00:00:00 +0000

Home on Study Notes

1. AtomicReference - Object Swapping

Asynchronous, Non-Blocking IO - Thread-per-Core

1. The “Why”

Atomic Integers & Lock-Free E-commerce

1. The “Why”

2. Comparison: Synchronized vs. AtomicInteger

3. The “Golden” Snippet: High-Traffic Inventory

Atomic Operations, Volatile, & Metrics

1. The “Why”

2. Comparison: Volatile vs. Atomic vs. Synchronized

3. The “Golden” Snippet: Performance Metrics

Atomic References & Lock-Free Data Structures

1. The “Why”

2. Comparison: Synchronized Object vs. AtomicReference

3. The “Golden” Snippet: A Lock-Free Stack

Condition Variables - Inter-Thread Communication

1. The “Why”

2. Comparison: wait/notify vs. Condition Object

3. The “Golden” Snippet: Multi-Condition Producer-Consumer

Critical Section & Synchronization

1. The “Why”

2. Visual Logic: The Monitor/Lock Concept

Deep Dive- Synchronization in Action

1. The “Why”

2. Detailed Code Explanation

How the JVM executes this:

3. Finer-Grained Synchronization (The Block)

High-Performance IO with Virtual Threads

1. The “Why”

2. Comparison: NIO (Selectors) vs. Virtual Threads

3. The “Golden” Snippet: The “Simple” High-Scale Server

Introduction to Blocking IO

1. The “Why”

2. Comparison: Blocking IO vs. Non-Blocking IO (NIO)

3. The “Golden” Snippet: The Standard Blocking Server

Introduction to Non-Blocking & Lock-Free Operations

1. The “Why”

2. Comparison: Blocking vs. Lock-Free (Non-Blocking)

3. The “Golden” Snippet: Atomic Compare-And-Swap (CAS)

Introduction to Performance & Optimization for Latency in Threads

Introduction to Performance & Optimization for Latency

1. The “Why”

2. Visual Logic

Introduction to Virtual Threads (Project Loom)

1. The “Why”

Locking Strategies & Deadlocks

1. The “Why”

2. Comparison: Coarse-Grained vs. Fine-Grained Locking

3. The “Golden” Snippet: The Deadlock Trap

Objects as Condition Variables - wait, notify, & notifyAll

1. The “Why”

2. Comparison: wait/notify vs. Condition Objects

3. The “Golden” Snippet: Classic Producer-Consumer

Parallel Streams & ForkJoinPool

1. The “Why”

Race Conditions vs. Data Races

1. The “Why”

Recursive Task

1. The “Why”

ReentrantLock - tryLock & Interruptibility

1. The “Why”

2. Comparison: synchronized vs. ReentrantLock

3. The “Golden” Snippet: The Safe Transfer (No Deadlock)

ReentrantLock - UI Application Example

1. The “Why”

2. Comparison: Blocking vs. Non-Blocking UI

3. The “Golden” Snippet: The Responsive UI

ReentrantReadWriteLock & Database Implementation

1. The “Why”

2. Comparison: ReentrantLock vs. ReadWriteLock

3. The “Golden” Snippet: A Simple Database

Resource Sharing & Critical Sections (Deep Dive)

1. The “Why”

Semaphore - Scalable Producer-Consumer

1. The “Why”

2. Comparison: Mutex vs. Semaphore

3. The “Golden” Snippet: Semaphore-Based Producer-Consumer

Stack vs. Heap Memory Regions

1. The “Why”

2. Comparison: `wait/notify` vs. `Condition` Object

2. Comparison: `wait/notify` vs. `Condition` Objects

2. Comparison: `synchronized` vs. `ReentrantLock`

1. Scenario A: High-Contention Updates (Use `ReentrantLock`)

2. Avoid “Pinning” (Replace `synchronized`)

2. The Solution: `thread.join()`