🧪volatile vs Atomic vs transient

Three different tools for three different problems: visibility, atomicity, and serialization control.

📌 Key Ideavolatile is for visibility/order, Atomic* classes are for lock-free atomic updates, and transient excludes fields from Java serialization. They solve different layers and are not interchangeable.

📖

Definition

Interview trap: these keywords/classes sound related but target different subsystems. Concurrency correctness (volatile, Atomic*) is different from object serialization behavior (transient).

✅

When to Use

Use volatile for simple state flags read by many threads.
Use Atomic* for high-frequency counters and lock-free updates.
Use transient to prevent sensitive or recomputable fields from being serialized.

🚫

When NOT to Use

Do not use volatile for compound state transitions.
Do not use Atomic* as a replacement for all locking; complex invariants still need locks.
Do not assume transient secures data at rest/network automatically.

💻

Code Variations

1️⃣ volatile for visibilityjava

class Worker implements Runnable {
  private volatile boolean running = true;
  void stop() { running = false; }

  public void run() {
    while (running) doWork();
  }
}

Writer thread update becomes visible to reader thread.

2️⃣ Atomic counterjava

class Metrics {
  private final AtomicLong requests = new AtomicLong();
  void mark() { requests.incrementAndGet(); }
  long total() { return requests.get(); }
}

No race like count++ on plain/volatile int.

3️⃣ transient field examplejava

class SessionUser implements Serializable {
  String userId;
  transient String rawAccessToken; // not serialized
  transient Cache warmCache;       // recompute on restore
}

transient affects Java serialization, not runtime thread safety.

📊