Concurrency in Java: When One Program Does More Than One Thing

Have you ever wondered how your phone can download something, play music, and still let you scroll through an app at the same time?

That’s where the idea of concurrency comes in.

I recently started learning concurrency in Java, and these were the concepts that helped me understand the basics.

So, What Exactly Is Concurrency?

Imagine you’re cooking.

You put pasta on the stove and, instead of standing there doing nothing until it boils, you start chopping vegetables.

Both tasks are making progress during the same period of time.

That’s the basic idea of concurrency.

In programming, we may have multiple tasks such as downloading a file, processing data, or responding to a user. Instead of making one task completely block the others, we can allow multiple tasks to make progress.

Enter: Threads

A thread is basically a path of execution inside a program.

Think of a program as a workplace and threads as people working there.

One person can handle one task while another handles something else.

When a Java program starts, the JVM creates a main thread, which executes:

public static void main(String[] args)

We can also create additional threads.

For example:

class MyThread extends Thread {

    public void run() {
        System.out.println("My thread is running");
    }
}

Then:

MyThread t = new MyThread();
t.start();

And this brings us to an important difference.

start() vs run()

This initially confused me.

t.start();

and

t.run();

are not the same thing.

When we use:

t.start();

Java starts a new thread, and that thread executes run().

But when we directly call:

t.run();

it’s just a normal method call. No new thread is created.

A simple way to remember it:

***start() → starts a new thread → run() gets executed***

***run() → normal method call***

Why Does the Output Sometimes Change?

Suppose the main thread and another thread are both printing numbers.

We might get:

Main Thread: 1
Child Thread: 1
Child Thread: 2
Main Thread: 2

But another time, we might get:

Child Thread: 1
Main Thread: 1
Main Thread: 2
Child Thread: 2

Why?

Because when multiple threads are running, we cannot always predict exactly which thread will get CPU time at a particular moment.

And this is where concurrency becomes interesting — and sometimes tricky.

The Real Problem: Shared Data

Now imagine two threads are working with the same object:

class Counter {
    int count = 0;
}

If both threads access the same Counter object, they are accessing the same count variable.

Threads don’t automatically get separate copies of an object’s instance variables.

So if both threads are doing:

count++;

at the same time, things can go wrong.

For example, both threads might read:

count = 0

before either one updates it.

Both then increase it to 1.

We expected:

0 → 1 → 2

but we might end up with:

0 → 1

This is called a race condition.

A race condition happens when multiple threads access shared data and the final result depends on the timing of their execution.

What I’ve Learned So Far

The basic picture of concurrency now looks like this:

Concurrency → Multiple tasks making progress during overlapping periods.

Thread → A path of execution inside a program.

**start()** → Starts a new thread.

**run()** → Contains the work performed by the thread.

Shared data → Data that multiple threads can access.

Race condition → When multiple threads access shared data and timing can cause an unexpected result.

And this leads to the next question:

If multiple threads can modify the same data, how do we make sure they don’t interfere with each other?

That’s where synchronization comes in.

And that’s the part I’m learning next. 🚀