How False Sharing Slows Java Programs and How Cache Line Padding Boosts Performance

Before explaining the concept of false sharing , we run a program on a four‑core machine where four threads share an array and each repeatedly increments a distinct index one hundred million times, measuring the total execution time.

The program’s logic is four threads sharing the same array, each writing to a different element. After removing the commented padding code in SharingLong and rerunning, the execution time improves dramatically, showing a performance difference of up to 5 : 1.

False sharing (English: False Sharing ) occurs when variables that reside on the same cache line are accessed by different threads, causing unnecessary write‑contention. The padding lines in SharingLong are known as Cache Line Padding .

In a 64‑bit Java object, the header occupies two words (hashcode, flags, and pointer), and the fields v plus six p variables total eight long s, i.e., 64 bytes.

Modern CPUs have a three‑level cache hierarchy (L1, L2, L3). The smallest unit of cache storage is a cache line , typically 64 bytes. When a CPU reads from main memory, it loads an entire cache line; writes are first performed in the cache and later flushed back to memory.

The v field is declared volatile, which forces the CPU to make writes visible to other threads immediately, invalidating the corresponding cache line. If two volatile variables are placed adjacently, both threads may repeatedly load and invalidate the same cache line, leading to the false‑sharing effect.

Execution steps illustrate the problem:

CPU 1 reads v1 into its cache line.

CPU 2 reads v2 into its cache line.

CPU 1 writes v1, flushes to memory, and invalidates the line.

CPU 2 writes v2, sees the line invalidated, reloads it, and flushes again.

This interleaving causes repeated cache‑line loads—write competition—known as false sharing. Adding six padding long variables separates v1 and v2 into distinct cache lines, eliminating the contention and improving performance, albeit at the cost of lower cache‑line utilization (only ¼ of the line is used).

When the variables are changed from volatile to ordinary long s, the program runs three orders of magnitude faster because the CPU no longer needs to enforce immediate visibility, allowing most accesses to stay in cache.

Understanding false sharing is valuable for pure‑memory workloads; frameworks like the Disruptor use cache‑line padding to achieve order‑of‑magnitude throughput improvements over traditional Java queues.