---
title: CPU Cache Coherence and False Sharing for Cloud Backend Engineers
description: Two goroutines updating adjacent counters can saturate the memory bus on a c7g.4xlarge. This guide covers memory barriers, cache lines, and false sharing, and why placement groups do not fix application-level contention.
url: https://www.joinhorizon.co/blog/cpu-memory-model-cache-coherence-false-sharing-cloud/
datePublished: 2026-06-12T00:00:00.000Z
dateModified: 2026-10-28T00:00:00.000Z
author: palaniappan-p
category: Cloud Architecture
tags: engineering-guide, performance, aws, ec2
---

# CPU Cache Coherence and False Sharing for Cloud Backend Engineers

> Two goroutines updating adjacent counters can saturate the memory bus on a c7g.4xlarge. This guide covers memory barriers, cache lines, and false sharing, and why placement groups do not fix application-level contention.

**Graviton3 (June 2026)** offers strong price/performance for Java and Go services, but **false sharing** on hot counters still collapses scalability long before network limits.

> **Benchmark pattern (hypothetical workload):** Java 21 virtual-thread counter array with false sharing on adjacent AtomicLongs, throughput drops 8x (1.2M→150K ops/sec); padding to 64-byte cache lines restores 1.1M ops/sec on c7g.4xlarge Graviton3.

## Symptom → mechanism → AWS control

| Production symptom                     | Mechanism                                | AWS control                                                   |
| -------------------------------------- | ---------------------------------------- | ------------------------------------------------------------- |
| Scaling cores doesn't scale throughput | False sharing invalidates cache lines    | @Contended (Java), pad hot counters to 64 bytes               |
| Noisy neighbor CPU spikes              | Cache coherence traffic on shared memory | Pin workloads to dedicated instances, Graviton for price/perf |
| Latency jitter on lock-free code       | MESI protocol coherence misses           | Per-thread local accumulators, merge on flush                 |

**Opinionated take:** When horizontal scaling stops helping, check false sharing before buying bigger instances. It's the silent killer on Graviton and x86 alike.

## Mechanism

CPUs cache data in **64-byte lines**. Two threads mutating different variables in the same line cause **cache line bouncing** as the coherence protocol invalidates the line on every write. Memory barriers do not flush caches; they enforce ordering, so a core can stall until its pending stores are visible to the others.

Distributed systems add **network coherence** (DynamoDB conditional writes). Do not confuse this with the CPU MESI protocol.

## AWS services map

| Need                       | Service                                   | Skip when                                     |
| -------------------------- | ----------------------------------------- | --------------------------------------------- |
| CPU profiling              | CloudWatch Agent + perf or JFR on ECS/EKS | Fully managed Lambda with no profiling access |
| Graviton price-performance | c7g/m7g instances                         | x86-only dependencies without ARM builds      |
| Dedicated tenancy          | EC2 dedicated hosts                       | Shared tenancy with low CPU sensitivity       |

| Scenario                   | Mitigation                                                   |
| -------------------------- | ------------------------------------------------------------ |
| Per-request metrics arrays | Pad structs to cache line; use per-core aggregators          |
| Lock-free queues on EC2    | Align atomic slots; benchmark on same instance class as prod |
| NUMA on large instances    | Pin threads; use `c7g` size matched to actual parallelism    |

**Placement groups** reduce network latency. They do not fix false sharing in code.

## When this advice breaks

- **I/O-bound Lambda:** CPU cache is irrelevant; optimize cold start and downstream calls.
- **Managed services:** You do not tune RDS CPU cache; tune queries.

## What to do this week

1. Run `perf c2c` or VTune on hottest lock-free path under load.
2. Separate frequently updated atomics by 64 bytes in hot structs.
3. Load test on production instance family, not a laptop.

## More in This Track

Part of the **Engineering Guides** library (June 2026).

- Previous: [Part 3](https://www.joinhorizon.co/blog/high-concurrency-server-io-epoll-syscalls-zero-copy-aws/)
- Browse tracks: [Engineering Guides hub](https://www.joinhorizon.co/resources/engineering-guides/)

## What this guide doesn't cover

JVM GC and object layout: see concurrency runtime track.

## FAQ

### Will a placement group fix false sharing on EC2?
No. Placement groups cut network hop latency. False sharing is cache-line bouncing inside one instance when two threads mutate adjacent variables. Pad hot counters to 64 bytes, use per-thread accumulators, then load-test on the production instance family.

### When should I ignore CPU cache advice?
I/O-bound Lambda and query-bound RDS do not need MESI tuning. Optimize cold start and SQL first. This guide is for lock-free or high-churn counters on EC2/ECS/EKS where adding cores does not add throughput.

### Does Graviton change the cache-line size I should pad to?
Treat 64-byte lines as the working assumption on Graviton3 and x86 alike. The hypothetical Java 21 counter pattern in this guide collapsed until padding restored throughput on c7g.4xlarge. Measure with perf c2c or JFR on the same family as prod.

### What could go wrong if I buy a larger instance instead?
More cores can increase coherence traffic. Horizontal scaling that “stops helping” is the tell. Fix layout before dedicated hosts or a bigger c7g.

---

*Source: https://www.joinhorizon.co/blog/cpu-memory-model-cache-coherence-false-sharing-cloud/*