Java Concurrency: From Threads to Thread Safety — Part 1

I have been spending some time to dig deeper into Java concurrency - threads, synchronization, race conditions.
Most tutorials usually show you how to start a Thread, print "Hello World" which is not how any of this works in production.

This post covers my experiments, traps that I fell into, and what finally clicked - the non-"Hello World" way.

Processes vs. Threads

You can think of a Process as a factory. It has its own walls and its own resources. When you boot up a Java application, the JVM itself is the process.

A Thread is a worker inside your factory. The JVM automatically creates the main thread when your app starts. Every other thread you spawn is born from that main thread. Because all threads share the exact same workspace (the Java Heap memory), they can communicate instantly.

This shared memory is the root cause that makes multithreading dangerous. If one thread reads a value while another thread is halfway through updating it, the data gets corrupted. They don't even need to run at the exact same instant — one thread just needs to get in between another's read and write.

What threads share vs What they own

Shared between all threads in a process:

• Heap memory — all your new SomeObject() calls
• Static variables — one copy, every thread sees it
• Class bytecode — the compiled .class files

Private to each thread:

• Its own stack — local variables, method parameters, return addresses
• Program counter — which line is this thread currently executing

Creating a thread: The Two Ways

If you want to hire a background worker in Java, there are two ways to do it.

Way 1: Extend the Thread Class

class MyWorker extends Thread {
    @Override
    public void run() {
        System.out.println("Running on: " + Thread.currentThread().getName());
    }
}
new MyWorker().start();

Way 2: Implement Runnable

Runnable is an interface with a single run() method.

Runnable task = () -> {
    System.out.println("Running on: " + Thread.currentThread().getName());
};
new Thread(task).start();

Note: Implementing Runnable keeps your class free to extend something else. In real codebases, always prefer Runnable.

Pitfall #1

Observe the below code:

new Thread(task).run();    // Looks right. Completely wrong.
new Thread(task).start();  // What you actually want.

I ran this to see what happens:

Runnable task = () -> {
    System.out.println("Running on: " + Thread.currentThread().getName());
};

System.out.println("--- calling run() ---");
new Thread(task).run();

System.out.println("--- calling start() ---");
new Thread(task).start();

Output:

    --- calling run() ---
    Running on: main
    --- calling start() ---
    Running on: Thread-1

run() is just a regular method call. No new thread is born. The main thread itself jumps into run() and executes it. You never left main. Nothing concurrent happened.

start() actually tells the JVM — spin up a new thread, give it a stack, and let it run. That's when you see Thread-1 in the output.

Calling run() instead of start() is the worst kind of bug because it throws no errors, the code executes, but your application stays single-threaded.

The Static Variable and join()

Runnable has a fundamental flaw - run() method returns void. It behaves like fire and forget.

The hack was to use a shared static variable, whenever a value needs to be returned.

static int result = 0;

public static void main(String[] args) {
    Runnable task = () -> { result = 10 + 10; };
    new Thread(task).start();

    System.out.println(result); // What does this print?
}

If you run this, it will almost always print 0.
Because the main thread is fast. It starts the background worker, and then immediately races to the next line and prints result before the background worker even computes.

To fix this, we have to force the main thread to wait using .join().

    Thread t1 = new Thread(task);
    t1.start();
    t1.join(); // Tells the main thread: Stop here until t1 is completely dead.
    System.out.println(result); // Now prints 20

Pitfall #2: The Race Condition

The static variable combined with .join() works for one thread, but it falls apart in production code.
If you have two threads writing to that shared result variable at the same time, their data overwrites each other unpredictably. The output will change from run to run making it difficult to debug.

Callable & FutureTask

Static variable hack is so unpredictable, Java introduced Callable.

It is exactly like Runnable, but it returns a value and can throw exceptions.

But there is a catch: Thread doesn't accept Callable directly. The compiler will throw an error if you try new Thread(myCallable).

So Java has FutureTask — a wrapper that accepts a Callable and is itself Runnable, so Thread can take it:

    Callable<String> task = () -> {
        return "Result from: " + Thread.currentThread().getName();
    };

    FutureTask<String> futureTask = new FutureTask<>(task);
    new Thread(futureTask).start();

    System.out.println(futureTask.get()); // blocks until result is ready

ExecutorService & Future

Above code works fine. But we are creating a new Thread for every task. In real production case, this can easily spin up thousands of threads and result in OutOfMemoryError.

To put a check on this, a manager for thread creation is needed: an ExecutorService.

When you submit a Callable to a thread pool, the manager gives you back a Future.

A Future is basically a promise — the worker is on it, and the result will show up here when it's done. Main thread doesn't freeze, it just calls future.get() when it actually needs the value.

// 1. Initialize the Manager (A pool of 10 workers)
ExecutorService executorService = Executors.newFixedThreadPool(10);

// 2. Submit the task
Future<String> future = executorService.submit(myCallable);

// 3. Check the result
System.out.println(future.get());

executorService.shutdown();

Pitfall #3

The .get() method is blocking. When your main thread hits future.get(), it pauses and waits for the background worker to populate the box.

If that background worker gets stuck in an infinite loop, the main thread waits forever. Your application freezes. In production, never call .get() without a timeout.

try {
    System.out.println(future.get(3, TimeUnit.SECONDS));
} catch (TimeoutException e) {

    System.out.println("Task took too long!");
    future.cancel(true); // <--- Kill the zombie worker
}

Note: cancel(true). If you give up waiting, tell the worker to stop. Otherwise, it stays alive in the background keeping CPU running forever as a "zombie worker".

Shared State

Even with thread pools and futures, what happens when all threads try to access the exact same data?

Imagine a simple Bank Account:

public class BankAccount {
    private int balance = 0;

    public void deposit() {
        balance ++; 
    }

    public int getBalance() {
        return balance;
    }
}

Let's use our ExecutorService to submit exactly 10000 tasks. Every single task will simply call deposit() on the exact same bank account.

ExecutorService service = Executors.newFixedThreadPool(10);
BankAccount bankAccount = new BankAccount();

// Submit 10,000 deposit tasks to the pool
for (int i = 0; i < 10000; i++) {
    service.submit(() -> bankAccount.deposit());
}

// wait for the workers to finish
service.shutdown(); 
service.awaitTermination(5, TimeUnit.SECONDS);

System.out.println("Final balance: " + bankAccount.getBalance());

10000 deposits should equal a final balance of 10000. But if you run this code, you will get 9998. Or 9991. Or 9997.

Pitfall #4

For us, balance++ is one step. But to a CPU, it is three:

1. Read the current balance.
2. Add 1 to it.
3. Write the new value back.

For example: If Thread A reads the balance at 5000, and Thread B reads it before A writes back, they both see 5000. Both add 1, both write 5001. Two deposits, one update lost.

Fixing the Race Condition

First thing to try is to use synchronized.

public synchronized void deposit() {
    balance ++;
}

When you add synchronized to a method, Java automatically uses the object itself (in this case, your bankAccount instance) as a lock.

    * Thread 1 grabs the lock, runs the method.
    * Threads 2 through 10000 hit the locked door and OS put all those to sleep state (`BLOCKED`)
    * Thread 1 finishes, returns the lock, and wakes up Thread 2.
    * Repeat 10000 times.

synchronized works fine until many threads are constantly fighting for the same lock. When contention is high, thousands of threads hitting the same method, the constant blocking and waking becomes the bottleneck and you can end up slower than a single thread. That's when you look for alternatives.

Lock-Free Concurrency (Atomics)

Instead of locks, we can use hardware-level instructions. Modern CPUs have a feature called Compare-And-Swap (CAS).
It says:
Update a value only if it has not been changed by another thread.

In Java, we use AtomicInteger which is built on CAS mechanism. Here is the code:

public class BankAccount {
    private AtomicInteger balance = new AtomicInteger(0);

    // No synchronized keyword needed!
    public void deposit() {
        balance.incrementAndGet();
    }

    public int getBalance() {
        return balance.get();
    }
}

If you run 10000 threads against this, your balance prints 10000 every single time. No locks, no blocking. But it's not magic — see the note below

Note: CAS isn't free. Under the hood, if the update fails, the thread retries in a loop — it doesn't sleep, it spins. With few threads this is fast. With thousands of threads all spinning on the same value, you're burning CPU on retries. synchronized at least puts threads to sleep. Pick based on your contention level.

---

What's Next?

We will be discussing more on CompletableFuture, ConcurrentHashMap, CountDownLatch, DeadLocks and more in further posts.