public class HelloThread {
    public static void main(String[] args) {
        Thread t = new Thread(() -> {
            System.out.println("Hello from thread: "
                + Thread.currentThread().getName());
        });
        t.start();
        System.out.println("Hello from main: "
            + Thread.currentThread().getName());
    }
}

$ javac HelloThread.java && java HelloThread
Hello from main: main
Hello from thread: Thread-0

• The order of output is nondeterministic — run it again and you might get a different order!

public class Counter {
    static int count = 0;
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 100_000; i++) count++;
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 100_000; i++) count++;
        });
        t1.start(); t2.start();
        t1.join();  t2.join();
        System.out.println("count = " + count);
    }
}

$ java Counter
count = 137462      # Expected 200000!

public class SyncCounter {
    static int count = 0;
    static final Object lock = new Object();
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 100_000; i++)
                synchronized (lock) { count++; }
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 100_000; i++)
                synchronized (lock) { count++; }
        });
        t1.start(); t2.start();
        t1.join();  t2.join();
        System.out.println("count = " + count);
    }
}

$ java SyncCounter
count = 200000      # Correct every time!

Java also lets you synchronize entire methods.

public class BankAccount {
    private int balance;
    public BankAccount(int initial) { this.balance = initial; }
    public synchronized void deposit(int amount) {
        balance += amount;
    }
    public synchronized void withdraw(int amount) {
        if (balance >= amount) {
            balance -= amount;
        }
    }
    public synchronized int getBalance() {
        return balance;
    }
}

• synchronized on a method locks on this — only one thread can execute any synchronized method on that object at a time.
• Is this enough? What could go wrong?

public class Deadlock {
    static final Object lockA = new Object();
    static final Object lockB = new Object();
    public static void main(String[] args) {
        Thread t1 = new Thread(() -> {
            synchronized (lockA) {
                synchronized (lockB) { System.out.println("t1"); }
            }
        });
        Thread t2 = new Thread(() -> {
            synchronized (lockB) {
                synchronized (lockA) { System.out.println("t2"); }
            }
        });
        t1.start(); t2.start();
    }
}

import java.util.concurrent.atomic.AtomicInteger;
public class AtomicCounter {
    static AtomicInteger count = new AtomicInteger(0);
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 100_000; i++) count.incrementAndGet();
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 100_000; i++) count.incrementAndGet();
        });
        t1.start(); t2.start();
        t1.join();  t2.join();
        System.out.println("count = " + count.get());
    }
}

$ java AtomicCounter
count = 200000

public class Visibility {
    static boolean running = true;   // not volatile!
    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(() -> {
            while (running) { /* spin */ }
            System.out.println("Stopped!");
        });
        t.start();
        Thread.sleep(100);
        running = false;   // might never be seen by t!
    }
}

Why do we need a memory model?

• Modern CPUs reorder instructions and cache memory for performance

• Without rules, threads might see stale or inconsistent data

• The Java Memory Model (JMM) defines happens-before relationships:

  • Unlock on a monitor happens-before subsequent lock on that monitor
  • Write to volatile field happens-before subsequent read
  • Thread.start() happens-before any action in the started thread
  • All actions in a thread happen-before Thread.join() returns

• Without happens-before, you have no guarantee about what one thread sees from another.

• This is a language-level specification — it constrains what the JVM and CPU can optimize.

import java.util.concurrent.*;
public class PoolExample {
    public static void main(String[] args) throws Exception {
        ExecutorService pool = Executors.newFixedThreadPool(4);
        List<Future<Integer>> futures = new ArrayList<>();
        for (int i = 0; i < 10; i++) {
            final int n = i;
            futures.add(pool.submit(() -> {
                Thread.sleep(100);
                return n * n;
            }));
        }
        for (Future<Integer> f : futures) {
            System.out.println(f.get());    // blocks until result ready
        }
        pool.shutdown();
    }
}

import java.util.concurrent.CompletableFuture;
public class AsyncChain {
    public static void main(String[] args) {
        CompletableFuture
            .supplyAsync(() -> "Hello")
            .thenApply(s -> s + " World")
            .thenApply(String::toUpperCase)
            .thenAccept(System.out::println)
            .join();   // wait for completion
    }
}

HELLO WORLD

import java.util.concurrent.*;
public class ProducerConsumer {
    public static void main(String[] args) {
        BlockingQueue<Integer> queue = new ArrayBlockingQueue<>(10);
        Thread producer = new Thread(() -> {
            for (int i = 0; i < 20; i++) {
                try {
                    queue.put(i);      // blocks if queue is full
                    System.out.println("Produced: " + i);
                } catch (InterruptedException e) { break; }
            }
        });
        Thread consumer = new Thread(() -> {
            for (int i = 0; i < 20; i++) {
                try {
                    int val = queue.take();  // blocks if queue is empty
                    System.out.println("Consumed: " + val);
                } catch (InterruptedException e) { break; }
            }
        });
        producer.start(); consumer.start();
    }
}

Java 21 introduced virtual threads — lightweight, JVM-managed threads.

import java.util.concurrent.*;
public class VirtualThreads {
    public static void main(String[] args) throws Exception {
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            for (int i = 0; i < 100_000; i++) {
                final int n = i;
                executor.submit(() -> {
                    Thread.sleep(1000);
                    return n;
                });
            }
        }   // waits for all tasks to complete
        System.out.println("Done!");
    }
}

• 100,000 OS threads would crash. 100,000 virtual threads is fine!
• Virtual threads are extremely cheap and heap-allocated — create one per task, no pooling.
• The JVM multiplexes them onto OS threads, unmounting transparently on block. Similar to Go's goroutines.
• Existing blocking code works as-is. Avoid synchronized/JNI — they pin virtual threads to OS threads!
• Similar motivation to Go's goroutines.

How do other languages approach concurrency?

• The shared-memory model (Java, C) is the lowest-level approach.
• Higher-level models (actors, channels, STM) try to make concurrency safer by design.

public class LazyInit {
    private static Map<String, String> cache;
    public static String get(String key) {
        if (cache == null) {
            cache = new HashMap<>();
            cache.put("greeting", "hello");
        }
        return cache.get(key);
    }
}

Is this fix correct?

public class LazyInit {
    private static volatile Map<String, String> cache;
    public static String get(String key) {
        if (cache == null) {
            synchronized (LazyInit.class) {
                if (cache == null) {       // double-checked locking
                    Map<String, String> temp = new HashMap<>();
                    temp.put("greeting", "hello");
                    cache = temp;
                }
            }
        }
        return cache.get(key);
    }
}

• Double-checked locking — fast path avoids synchronization.
• Only correct with volatile! Without it, the JMM allows reordering that lets another thread see a partially constructed map.
• Getting concurrency right is hard. Prefer higher-level abstractions when possible.

• Threads share memory — this is powerful but dangerous.
• Race conditions arise from unsynchronized access to shared mutable state.
• synchronized and locks enforce mutual exclusion, but introduce deadlock risks.
• volatile ensures visibility between threads, but not atomicity.
• Atomic classes provide lock-free thread-safe operations for simple cases.
• The Java Memory Model defines happens-before rules that govern what threads can see.
• Higher-level abstractions (ExecutorService, CompletableFuture, BlockingQueue) reduce error-prone manual synchronization.
• Virtual threads (Java 21) make thread-per-task practical.
• Immutability is the simplest path to thread safety — functional programming and concurrency are natural partners.
• The concurrency landscape ranges from shared memory (Java/C) to message passing (Go/Erlang) to compile-time enforcement (Rust).