cpu-cache-and-numalisted

# CPU Cache and NUMA ## Purpose Explain hardware-locality failures that blocking-oriented evidence can miss. False sharing can degrade throughput without monitor contention or a dedicated JFR event, but cache misses, coherence traffic, CPU saturation and scaling curves still leave evidence. Treat it as a hypothesis to falsify, not the default explanation for poor scaling. ## Workflow Start from the requested outcome and reuse existing captures, layout listings and deployment configuration when they match the workload and build. Preserve the project's Java baseline; use Java 25 when no target is specified. For a conceptual or flag question, answer the relevant contract directly. Keep an adequate layout or placement when there is no demonstrated problem. For a scaling investigation, select the following checks to resolve the remaining hypotheses: 1. **Measure the scaling curve**: throughput, p99, CPU, allocation and synchronization from one thread through the production concurrency range. Efficiency is descriptive; there is no universal 0.5 entry threshold. 2. **Check the signature.** Throughput that worsens as writers are added is consistent with coherence, but also with locks, queueing, GC, bandwidth saturation, scheduler overhead or a downstream limit. Use competing hypotheses. 3. **Rule out lock contention and true sharing first** — see the distinction table in `references/false-sharing.md`. JFR can expose qualifying blocking events; it has no dedicated