⚛️ Atomic Variables & Synchronization

**1. What are atomic variables?**

Atomic variables are essentially variables that allow us to perform thread-safe operations without explicitly using locks (like *synchronized*). When I use an atomic variable, the operation (like read-modify-write) is done in a single, indivisible hardware step (using CAS - Compare-And-Swap). This is different from ordinary variables where an operation like `count++` actually takes three steps (read, increment, write) and can get interrupted by other threads, leading to race conditions.

**2. Name at least four classes from the java.util.concurrent.atomic package that provide atomic operations for different data types**
*AtomicInteger*
*AtomicLong*
*AtomicBoolean*
*AtomicReference*

**Use case:** I usually use `AtomicInteger` when I need a simple counter in a web server or an application to keep track of concurrent requests or active users. It's much faster than wrapping an `int` inside a `synchronized` block.

**3. Compare locks with atomic variables.**
- **Atomic variables** are a better choice when I only need to update a *single* variable or flag independently (like a counter). They have less overhead because they don't block threads.
- **Locks** are necessary when my logic involves updating *multiple* variables at the same time that depend on each other, or when I need to protect a complex critical section of code.


🔒 Locks & Concurrent Design

**4. A program is completely free of race conditions but still performs poorly under high contention.**

Even if my code has zero race conditions, it can still run slowly due to:
1. **High Contention:** If all my threads are constantly trying to acquire the same lock, most of them will just be waiting in a queue doing nothing.
2. **Coarse-grained locking:** If I lock an entire large method instead of just the critical section, I limit concurrency unnecessarily.
3. **Context Switching Overhead:** The OS wastes a lot of CPU cycles switching between threads that are constantly pausing and waking up to check locks.

**5. Many concurrent systems experience performance degradation as the number of threads increases.**

Adding threads doesn't scale linearly. The main reasons are:
- **Context switching:** The CPU spends too much time saving and loading thread states instead of running my actual code.
- **Contention & Synchronization overhead:** More threads mean more competition for the same locks. Managing these locks takes time.
- **Cache coherence:** Threads on different CPU cores modify shared data, forcing the CPU to constantly update and synchronize caches across cores, which slows down the memory bus.

⚠️ Deadlocks

**6. Deadlocks often only appear in production, not during testing.**
During local testing, my computer usually runs threads fast and with low load, so they often execute sequentially and never hit that exact timing needed for a deadlock. In production, thousands of users hit the system concurrently with unpredictable network delays, creating the perfect random interleaving of threads that causes a deadlock cycle.
**Strategies to expose deadlocks:**
1. **Stress/Load Testing:** I can write a test that spawns hundreds of threads simulating simultaneous high-volume transactions to increase lock contention.
2. **Strategic Thread.sleep():** I can add `Thread.sleep(10)` or `Thread.yield()` right after a thread acquires its first lock but before it gets the second one. This forces a context switch and drastically increases the chance of catching a cyclic deadlock.