Concurrency

A race condition is when a program's correctness depends on the unpredictable timing of two or more threads accessing shared mutable state at once. The classic case is two threads reading, incrementing, and writing the same counter, where interleaved steps lose an update. You fix it by serializing access with synchronized, a lock, or atomic operations.

A synchronized method or block acquires the monitor lock of an object before entering, so only one thread at a time can execute that critical section guarded by the same lock. This serializes access to shared mutable state, preventing race conditions where interleaved reads and writes corrupt data. Releasing the lock on exit also flushes changes so the next thread sees them.

Deadlock is when two or more threads each hold a lock the other needs and wait forever, so none can proceed. The classic case is thread A holding lock 1 and wanting lock 2 while thread B holds lock 2 and wants lock 1. You prevent it by imposing a consistent global lock-ordering so all threads acquire locks in the same sequence, using tryLock with a timeout to back off, or by holding fewer locks at once.

Two basic ways: extend Thread and override run(), or implement Runnable and pass it to a Thread. Implementing Runnable is preferred because it leaves the class's single inheritance slot free and separates the task from the worker. For tasks that return a result or throw a checked exception, implement Callable and submit it to an ExecutorService, which hands back a Future.

Two bugs. First, the lambda captures i, but a loop variable is not effectively final, so it does not compile — copy it into a final local (final int n = i;) and print n. Second, System.exit(0) terminates the JVM immediately, killing the sleeping threads before they print — remove it (or join each thread first) so the program waits for their output.

volatile guarantees visibility: every read and write of the field goes straight to main memory rather than a thread-local cache, so other threads always observe the latest written value and the compiler cannot reorder around it. It does NOT provide atomicity for compound operations like i++, which is a read-modify-write that two threads can still interleave and lose updates on.

wait() is an Object method that RELEASES the monitor lock and parks the thread until another thread calls notify()/notifyAll() on the same object; it must be invoked while already holding that lock, normally inside a synchronized block. sleep() is a static Thread method that just pauses the current thread for a fixed duration and KEEPS every lock it currently holds.

A race condition is a timing bug where threads interleave access to shared state and corrupt it; you fix it by serializing access with locks or atomics. A deadlock is threads each holding a lock the other needs and waiting forever; a consistent lock-ordering or tryLock timeouts prevent it. A livelock is threads that keep reacting to each other and changing state but make no progress; randomized back-off breaks it.

A process is an independent running program with its own isolated memory space. A thread is a lightweight unit of execution inside a process; all threads of one process share that process's heap and loaded objects but each gets its own stack. Threads are cheaper to create than processes and can share data directly, which is fast but requires synchronization.

The memory model defines happens-before: if action A happens-before B, everything A wrote is visible to B and cannot be reordered past it. Releasing a monitor, writing a volatile field and starting a thread each create such an edge. Without one, reads may be reordered and a thread can keep seeing a stale value forever.

ThreadLocal gives every thread its own independent copy of a value, held in a map that hangs off the Thread object, so no synchronization is needed to read or write it. InheritableThreadLocal additionally copies the parent's value into a child at the moment the child thread is created. Values must be removed explicitly: a pooled thread outlives the task and keeps the entry alive.

notify() wakes a single arbitrary thread waiting on the object's monitor; you cannot choose which one. notifyAll() wakes every waiting thread, and they then re-contend for the lock, each re-checking its condition before proceeding. Prefer notifyAll() when threads wait on different conditions, because notify() might wake the wrong thread and leave a thread that could have run waiting forever.

Both threads are BLOCKED on a monitor, and their monitor addresses cross: worker-1 holds 0x…41180 and waits for 0x…3f2c8, while worker-2 holds 0x…3f2c8 and waits for 0x…41180. That is a circular wait on two Account monitors — a deadlock, because transfer locks the accounts in the caller's argument order, so two opposite transfers grab them in opposite orders. Fix it with a consistent global lock order (e.g. by account id) or a timed tryLock with back-off.