Lock contention is what happens when multiple threads frequently compete for the same Lock, forcing some of them to wait rather than run. A small amount of contention is harmless: the point of a lock is to serialize access to a critical section, so some waiting is expected by design. The problem is when contention grows to the point that threads spend more time waiting for the lock than doing useful work inside it.

Contention doesn't scale linearly with thread count, it tends to get disproportionately worse. Every thread that fails to acquire a Spinlock burns CPU cycles retrying, or (for a blocking lock) forces a context switch to sleep and another later to wake up, both of which are pure overhead that wasn't there with fewer threads. Worse, every failed atomic attempt on the lock variable generates Cache coherence traffic as the cache line bounces between cores, which slows down even the thread that currently holds the lock, since it now has to compete for the same cache line via the memory subsystem.

threads:  1    2    4    8    16
throughput:  scales up ... then flattens ... then drops
                           ^ contention overhead exceeds useful work

The standard fixes all aim at the same target: shrink how often threads need the lock, or shrink how long they hold it. Reduce the critical section to the minimum work that actually needs protecting, moving anything that doesn't touch shared state outside the lock. Shard the lock, splitting one lock protecting a large structure into many locks each protecting a smaller slice (a hash map with one lock per bucket instead of one lock for the whole table), so unrelated operations don't contend at all. Avoid the lock entirely for the hot path using Atomics or a lock-free structure like Lock-free queue, accepting more implementation complexity in exchange for no blocking. Left unaddressed, severe contention on a single lock can degrade into a Lock convoy, where the problem compounds rather than merely persisting.