DEV Community: Vishal Aggarwal

Your Virtual Threads Are Leaking: Why ScopedValue is the Only Way Forward

Vishal Aggarwal — Thu, 23 Apr 2026 21:13:57 +0000

Your Virtual Threads Are Leaking: Why ScopedValue is the Only Way Forward.

If you're spinning up millions of Virtual Threads but still clinging to ThreadLocal, you're building a memory bomb. Java 21 changed the game, and if you haven't migrated to ScopedValue yet, you're missing the actual point of lightweight concurrency.

Why Most Developers Get This Wrong

The Scalability Trap: Treating Virtual Threads like Platform Threads. Thinking millions of ThreadLocal maps won't wreck your heap is a rookie mistake; the per-thread overhead adds up fast when you scale to 100k+ concurrent tasks.
The Mutability Nightmare: Using ThreadLocal.set() creates unpredictable side effects in deep call stacks. In a world of massive concurrency, mutable global state is a debugging death sentence.
Manual Cleanup Failures: Relying on try-finally to .remove() locals. It inevitably fails during unhandled exceptions or complex async handoffs, leading to "ghost" data bleeding between requests.

The Right Way

Shift from long-lived, mutable thread-bound state to scoped, immutable context propagation.

Use ScopedValue.where(...) to define strict, readable boundaries for your data (like Tenant IDs or User principals).
Embrace Structured Concurrency: use StructuredTaskScope to ensure context propagates automatically and safely to child threads.
Treat context as strictly immutable; if you need to change a value, you re-bind it in a nested scope rather than mutating the current one.
Optimize for memory: ScopedValue is designed to be lightweight, often stored in a single internal array rather than a complex hash map.

Show Me The Code

private final static ScopedValue<String> TENANT_ID = ScopedValue.newInstance();

public void serveRequest(String tenant, Runnable logic) {
    // Context is bound to this scope and its children only
    ScopedValue.where(TENANT_ID, tenant).run(() -> {
        performBusinessLogic();
    });
    // Outside this block, TENANT_ID is automatically cleared
}

void performBusinessLogic() {
    // O(1) access, no risk of memory leaks, completely immutable
    String currentTenant = TENANT_ID.get(); 
    System.out.println("Working for: " + currentTenant);
}

Key Takeaways

Memory Efficiency: ScopedValue eliminates the heavy ThreadLocalMap overhead, making it the only viable choice for high-density Virtual Thread architectures.
Safety by Default: Immutability isn't a limitation; it's a feature that prevents "spooky action at a distance" across your call stack.
Structured Inheritance: Unlike InheritableThreadLocal, which performs expensive data copying, ScopedValue shares data efficiently with child threads within a StructuredTaskScope.

Want to go deeper? javalld.com — machine coding interview problems with working Java code and full execution traces.

Java Machine Coding: Building a Dependency Resolver with Topological Sort

Vishal Aggarwal — Thu, 23 Apr 2026 20:59:09 +0000

Java Machine Coding: Building a Dependency Resolver with Topological Sort

Dependency management is the backbone of build tools like Maven or Gradle and a high-signal problem in senior-level machine coding interviews. If you cannot correctly order task execution or detect circular dependencies, your system will fail at scale.

If you're prepping for interviews, I've been building javalld.com — real machine coding problems with full execution traces.

The Mistake Most Candidates Make

Naive Recursion: Using simple DFS without state tracking, which leads to redundant computations or infinite loops in circular graphs.
Ignoring In-Degrees: Attempting to "find" the next task by iterating over the entire list repeatedly ($O(N^2)$), rather than tracking which tasks are ready.
Coupling Logic: Mixing the task execution logic directly into the graph traversal code, making the system hard to test and extend.

The Right Approach

Core Mental Model: Represent the system as a Directed Acyclic Graph (DAG) and use Kahn’s Algorithm (BFS) to resolve nodes with zero incoming edges first.
Key Entities: Task, DependencyGraph, DependencyResolver.
Why it beats the naive approach: Kahn’s Algorithm provides $O(V + E)$ time complexity and offers a "free" way to detect cycles—if your output list is smaller than your input, you have a circular dependency.

The Key Insight (Code)

The heart of the resolver is maintaining the inDegree map. When a task's in-degree hits zero, it is ready for execution.

public List<String> resolve(Map<String, List<String>> adj, Map<String, Integer> inDegree) {
    Queue<String> queue = new LinkedList<>();
    inDegree.forEach((node, degree) -> { if (degree == 0) queue.add(node); });

    List<String> order = new ArrayList<>();
    while (!queue.isEmpty()) {
        String current = queue.poll();
        order.add(current);
        for (String neighbor : adj.getOrDefault(current, new ArrayList<>())) {
            inDegree.put(neighbor, inDegree.get(neighbor) - 1);
            if (inDegree.get(neighbor) == 0) queue.add(neighbor);
        }
    }
    if (order.size() != inDegree.size()) throw new CircularDependencyException();
    return order;
}

Key Takeaways

In-degree Tracking: This is the most efficient way to identify "ready-to-run" tasks without re-scanning the graph.
Cycle Detection: Always validate that the final sorted list size equals the total number of nodes to catch hidden circularities.
Separation of Concerns: Keep your graph representation (nodes/edges) distinct from the execution engine to allow for future features like parallel execution.

Full working implementation with execution trace available at https://javalld.com/problems/dependency-builder

Java LLD: Designing a Kafka-Like Message Queue for Machine Coding Interviews

Vishal Aggarwal — Thu, 23 Apr 2026 20:29:05 +0000

Java LLD: Designing a Kafka-Like Message Queue for Machine Coding Interviews

Designing a high-performance message queue is a frequent requirement in senior-level machine coding rounds. It tests your ability to balance thread safety with decoupled architecture while managing stateful consumer progress.

The mistake most candidates make

Using a standard java.util.Queue that removes elements upon polling, which prevents multiple consumer groups from reading the same data.
Coupling the Producer directly to the Consumer logic, violating the Pub-Sub principle and making the system brittle to scale.
Failing to implement independent offset management, leading to data loss or duplicate processing when one consumer lags.

The right approach

Core mental model: An immutable, append-only log where messages are persisted per topic, allowing consumers to track their own progress independently.
Key entities: Topic, Message, Subscriber, ConsumerGroup, OffsetManager.
Why it wins: It enables "replayability" and allows multiple heterogeneous systems to consume the same stream at different speeds without interference.

Implementation Insight: The Thread-Safe Log

public class Topic {
    private final List<Message> messages = new ArrayList<>();
    private final ReentrantLock lock = new ReentrantLock();

    public void addMessage(Message message) {
        lock.lock();
        try {
            messages.add(message);
        } finally {
            lock.unlock();
        }
    }

    public List<Message> getMessagesFrom(int offset) {
        return (offset >= messages.size()) ? List.of() : messages.subList(offset, messages.size());
    }
}

Key takeaways

Decouple producers and consumers by using an append-only log structure instead of a destructive queue.
Use ReentrantLock to ensure atomic appends to the message log in a multi-threaded producer environment.
Manage consumer state via independent offsets, allowing each ConsumerGroup to process messages at its own pace.

Full working implementation with execution trace available at https://javalld.com/problems/message-queue

Java LLD Interview Prep

Vishal Aggarwal — Thu, 23 Apr 2026 20:20:09 +0000

Java LLD: Designing a Scalable Job Scheduler Without Busy Polling

In my time at companies like Apple and Amazon, the "Job Scheduler" was a go-to interview question for senior roles. It isn't just about whether you can write a loop; it’s a litmus test for your understanding of resource management, thread safety, and low-level synchronization primitives. If you can't explain how to wake up a thread at the exact millisecond a job is due, you aren't passing the bar.

Why This Topic Matters

Designing a job scheduler is a foundational Low-Level Design (LLD) problem because it mirrors real-world systems like Crontab, Quartz, or the internal task executors used in microservices. In an interview, you aren't being asked to use ScheduledExecutorService; you are being asked to build it. The interviewer is looking for precision, efficiency, and a deep grasp of Java’s java.util.concurrent package.

The Mistake Most Candidates Make

The most common pitfall is "Busy Polling." I’ve seen countless candidates implement a while(true) loop that calls Thread.sleep(1000) and checks a queue for pending tasks.

This approach is flawed for two reasons:

Latency: If a job is scheduled for T+50ms and your thread just started a 1000ms sleep, the job will be 950ms late.
CPU Waste: If the queue is empty, the thread keeps waking up unnecessarily, consuming CPU cycles and draining battery/resources for no reason.

Experienced engineers know that the goal is to have the scheduler thread sleep for the exact duration until the next task is due, or until a new, higher-priority task is added.

The Right Approach: The Mental Model

To build a production-grade scheduler, you need to combine the Command Pattern with a Priority Queue and fine-grained synchronization.

Key Entities

Job: A wrapper around a Runnable that includes an executionTime (epoch timestamp).
Scheduler: A Singleton that manages the lifecycle of the background worker.
JobStore: A PriorityQueue (min-heap) that keeps the job with the earliest execution time at the head.
WorkerThread: The consumer thread that waits for jobs to become "due."

Why This Wins

Instead of generic sleeping, we use ReentrantLock and its associated Condition object. This allows us to implement a "wait-with-timeout" strategy. If a new job arrives that is scheduled earlier than the current head of the queue, we can signal the worker thread to wake up, recalculate its wait time, and go back to sleep—or execute the new job immediately.

The Core Insight: Smart Waiting

The magic happens in the worker's execution loop. We don't just wait; we wait conditionally. We use Condition.await(delay) to put the thread into a timed-waiting state. This is more efficient than Thread.sleep because it can be interrupted by a signal() call when a new job is pushed.

public void run() {
    while (running) {
        lock.lock();
        try {
            while (jobQueue.isEmpty()) {
                newJobCondition.await(); // Wait indefinitely for the first job
            }

            long currentTime = System.currentTimeMillis();
            Job nextJob = jobQueue.peek();
            long delay = nextJob.getExecutionTime() - currentTime;

            if (delay <= 0) {
                executorService.submit(jobQueue.poll()); // Execute due job
            } else {
                // Wait until the job is due OR a new job is added
                newJobCondition.await(delay, TimeUnit.MILLISECONDS);
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            lock.unlock();
        }
    }
}

Concurrency Angle: Thread Safety and Atomicity

When designing this, you must account for the Producer-Consumer race condition. While the worker thread is checking the peek() of the queue, a producer thread might be calling addJob().

If you use a standard PriorityQueue, it is not thread-safe. Even if you use a PriorityBlockingQueue, it doesn't solve the "wait-until-due" logic on its own. You need the ReentrantLock to ensure that the process of checking the time and deciding to wait is atomic.