What are the practical risks of using static (class) variables for mutable shared state, especially in multithreaded code?

## Recap: what 'static' means A **static variable** (class variable) is declared with the `static` keyword and has exactly **one copy per class**, created when the class is loaded and shared by every instance of the class and every piece of code that can reach it. That sharing is exactly what makes it powerful — and dangerous when the variable is *mutable* (its value can change). Mutable static state is, in effect, **global variable state**. Decades of experience show global mutable state causes bugs. Here is why, term by term. ### Risk 1 — Thread-safety (the concurrency problem) A **thread** is an independent path of execution; a program can run many at once. When multiple threads touch the same static variable, two hazards appear: - **Race condition / lost update:** an operation like `count++` is not atomic — it reads, adds, and writes back. If two threads interleave those steps, one update is lost. - **Visibility:** without synchronization the Java Memory Model gives no *happens-before* guarantee, so one thread may keep reading a stale cached value and never see another thread's write. Fixes, each with limits: - `synchronized` blocks/methods give both mutual exclusion and visibility, but add contention. - `volatile` guarantees **visibility** of the latest write but does **not** make compound actions (like `++`) atomic. - Atomic types (`AtomicInteger`, etc.) give lock-free atomic compound operations. ```java class Counter { static int unsafe; // race-prone static volatile int visibleButNotAtomic; // visible, but ++ still races static final java.util.concurrent.atomic.AtomicInteger safe = new java.util.concurrent.atomic.AtomicInteger(); static void inc() { unsafe++; // lost-update risk safe.incrementAndGet(); // correct under concurrency } } ``` ### Risk 2 — Testability Because a static is shared, **tests are not isolated**: a test that mutates a static leaks that state into the next test, so order matters and tests cannot safely run in parallel. There is also no seam to **substitute a fake** — you cannot easily inject a different implementation for a `static` field the way you can for an instance you pass in. This makes static mutable state a well-known testability smell. ### Risk 3 — Lifetime and memory leaks A static field is reachable as long as its **class** is loaded — typically the whole program (a class is unloaded only if its class loader becomes collectible, which rarely happens for application classes). Therefore **anything the static field references stays alive**. A static `Map` used as an ad-hoc cache, or a static list of registered listeners, grows forever and is never garbage-collected — a classic **memory leak** in long-running servers. ### When statics are fine - **True constants:** `static final` of an immutable type (`public static final int MAX = 100;`) — shared, never changes, no concurrency hazard. - **Stateless utility methods** and factory constants. - **Carefully designed singletons** with proper synchronization — though injecting a single instance is usually cleaner. ### The better pattern Prefer **dependency injection**: create one instance of a service and pass it where needed, instead of reaching for a mutable static. You keep the "one shared thing" benefit while regaining testability, controlled lifetime, and explicit dependencies. If you must share static mutable state, make access thread-safe (atomics/locks) and bound its growth. ### Summary Mutable static = global mutable state: shared, long-lived, and unsynchronized by default. Expect races, leaked memory, and brittle tests. Reserve `static` for constants and stateless helpers; inject instances for everything else.