Introduction

In normal threaded execution, local variables are not shared between threads. Each thread has its own call stack, so each invocation of a function gets its own separate set of local variables. The confusion usually comes from the fact that a local variable can still point to a shared object.

The Basic Rule

A local variable lives inside a specific stack frame. Since each thread has its own stack, thread A cannot directly read or overwrite thread B's local variable just because both threads are running the same function.

That means this kind of state is isolated by default:

1public class LocalDemo {
2    static void work() {
3        int counter = 0;
4        counter++;
5        System.out.println(Thread.currentThread().getName() + ": " + counter);
6    }
7
8    public static void main(String[] args) {
9        Runnable task = LocalDemo::work;
10        new Thread(task, "T1").start();
11        new Thread(task, "T2").start();
12    }
13}

Each thread prints its own counter value. The variable is local to that thread's execution of work().

What Actually Gets Shared

The tricky part is references. A local variable itself is private to the thread, but it may refer to an object stored on the heap, and heap objects can be shared.

1public class SharedObjectDemo {
2    static class Counter {
3        int value = 0;
4    }
5
6    static void increment(Counter counter) {
7        for (int i = 0; i < 1000; i++) {
8            counter.value++;
9        }
10    }
11
12    public static void main(String[] args) throws InterruptedException {
13        Counter shared = new Counter();
14
15        Thread t1 = new Thread(() -> increment(shared));
16        Thread t2 = new Thread(() -> increment(shared));
17
18        t1.start();
19        t2.start();
20        t1.join();
21        t2.join();
22
23        System.out.println(shared.value);
24    }
25}

Here, the parameter counter is a local variable in each thread. But both local variables point to the same Counter object. The threads are not sharing the local variable slot; they are sharing the heap object referenced by that slot.

Stack Data Versus Heap Data

This is the mental model that avoids most mistakes:

• local variables are usually stored in a thread's stack frame
• objects created with new typically live on the heap
• stacks are private per thread
• heap objects may be shared if more than one thread can reach them

Once you understand that separation, many concurrency questions become easier.

Parameters Follow the Same Rule

Function parameters are also local variables. If two threads call the same method, each call gets its own parameter variables. Again, the only question is whether those parameters point to the same shared objects.

1import threading
2
3shared = []
4
5
6def work(items):
7    local_count = 0
8    for _ in range(3):
9        local_count += 1
10        items.append(local_count)
11
12
13threads = [threading.Thread(target=work, args=(shared,)) for _ in range(2)]
14for t in threads:
15    t.start()
16for t in threads:
17    t.join()
18
19print(shared)

In this Python example, local_count is private to each thread, but items refers to the same list object, so the list is shared.

Thread-Local Storage Is a Different Feature

Some languages also provide thread-local storage, which creates data that behaves like global state but is isolated per thread. That is different from an ordinary local variable because its lifetime is tied to the thread rather than to a single function call.

Do not mix up thread-local storage with stack locals. They solve different problems.

Closures and Async Can Blur the Picture

A variable that looks local in source code may actually be captured by a closure or stored inside an object. Once that happens, the storage location and sharing behavior may change.

That is why concurrency bugs often appear in lambdas, callbacks, and mutable captured state. The variable name still looks small and local, but the underlying object may no longer be thread-private.

Common Pitfalls

The most common mistake is saying "locals are never shared" without considering shared objects referenced by locals. The variable slot is private, but the data behind the reference may not be.

Another mistake is assuming function parameters are copied deeply. In most languages, object references are passed, so multiple threads can easily end up mutating the same object.

Finally, even when locals are thread-private, updating shared state through them still requires synchronization or other safe concurrency patterns.

Summary

• Ordinary local variables are not shared across threads.
• Each thread gets its own stack and its own stack frames.
• A local variable can still point to a shared heap object.
• Parameters follow the same rule as other locals.
• Concurrency bugs usually come from shared objects, not from the local variables themselves.