Why this matters
The bug. long++ is three JVM operations. Two threads racing both read 42, both increment to 43, both write — final value is 43, not 44. The race is invisible until traffic spikes.
The fix. AtomicLong provides hardware-atomic increment. Adjust track to requests.incrementAndGet() and get to requests.get().
Bigger picture. For high-throughput counters, LongAdder distributes contention across cells and merges on read. Faster than AtomicLong past a few hundred K ops/sec.
Review heuristic
Every check-then-act over shared state is a race waiting for production load. Look for read-then-write pairs that aren't inside a transaction, a lock, or an atomic CAS. If you can articulate the bug as "if two requests arrive at the same time, both will...", it's a race.
External reference: CWE-362: Concurrent Execution using Shared Resource.