JavaScript 中的伪共享（False Sharing）问题：多线程 Worker 环境下 Cache Line 对齐对原子操作的影响

伪共享：JavaScript 多线程 Worker 环境下 Cache Line 对齐对原子操作的影响

各位编程爱好者、系统架构师以及对高性能 JavaScript 应用充满热情的朋友们，大家好。

在软件开发领域，我们常常追求代码的简洁、逻辑的清晰，但当性能成为关键瓶颈时，我们就不得不深入到计算机体系结构的底层。今天，我们将探讨一个在多核处理器时代日益凸显的问题——伪共享（False Sharing），以及它在 JavaScript Web Worker 环境下对原子操作性能的深远影响。我们将看到，即使是 JavaScript 这样通常被认为是“高级”的语言，在利用 SharedArrayBuffer 进行多线程编程时，也无法逃避底层硬件机制的影响。

1. 序言：多核时代的性能陷阱

曾几何时，提升程序性能的主要途径是等待更快的单核处理器。然而，随着物理定律的限制，CPU 制造商转向了多核架构。现在，我们的计算机拥有多个核心，每个核心都能独立执行指令，这为并行计算带来了巨大的潜力。Web Workers 与 SharedArrayBuffer 的引入，使得 JavaScript 也能以真正的共享内存多线程方式利用这些核心。

然而，并行并非没有代价。在享受多核并行带来的吞荣的同时，我们也面临着新的挑战，其中之一就是“伪共享”。伪共享是一个臭名昭著的性能杀手，它发生在不同的 CPU 核心访问看似不相关的数据，但这些数据却不幸地共享同一个缓存行时。这种无意的共享会导致缓存一致性协议频繁地在核心之间传递缓存行的所有权，从而产生巨大的性能开销，甚至抵消并行带来的好处。

今天的讲座，我们将深入剖析伪共享的原理、它在 JavaScript SharedArrayBuffer 环境下的具体表现，以及如何通过缓存行对齐等策略来有效缓解它。

2. JavaScript 中的多线程编程：Web Workers 与 SharedArrayBuffer

JavaScript 最初被设计为单线程语言，以避免复杂的并发问题。然而，随着 Web 应用复杂度的提升和多核处理器的普及，对并行处理的需求日益增长。Web Workers 的出现，允许 JavaScript 在后台线程中执行脚本，从而避免阻塞主线程。但最初的 Web Workers 之间只能通过消息传递进行通信，这意味着每次数据交换都需要序列化和反序列化，效率低下。

2.1 Web Workers：隔离与消息传递

Web Workers 提供了在浏览器后台运行脚本的能力，它们有自己独立的全局环境，与主线程隔离。这种隔离确保了主线程的响应性，即使 Worker 正在执行耗时的计算。

// main.js
const worker = new Worker('worker.js');

worker.postMessage('Hello from main thread!');

worker.onmessage = (event) => {
    console.log('Main thread received:', event.data);
};

// worker.js
self.onmessage = (event) => {
    console.log('Worker received:', event.data);
    self.postMessage('Hello from worker!');
};

这种模型对于 CPU 密集型任务非常有用，但当需要在多个 Worker 之间频繁共享大量数据时，消息传递的开销会变得非常显著。

2.2 SharedArrayBuffer：共享内存的突破

为了解决 Web Workers 之间高效数据共享的问题，SharedArrayBuffer 应运而生。SharedArrayBuffer 是一种特殊类型的 ArrayBuffer，它允许在多个 Worker 和主线程之间共享其内存内容。这意味着所有拥有该 SharedArrayBuffer 引用上下文都可以直接读写其中的数据，而无需进行昂贵的数据复制。

// main.js
const sab = new SharedArrayBuffer(1024); // 1KB shared memory
const intArray = new Int32Array(sab); // View on the shared buffer

// Initialize some data
for (let i = 0; i < intArray.length; i++) {
    intArray[i] = i;
}

const worker = new Worker('worker.js');
worker.postMessage({ sab }); // Pass the SharedArrayBuffer to the worker

worker.onmessage = (event) => {
    console.log('Main thread received update:', intArray[0]); // Observe changes made by worker
};

// worker.js
self.onmessage = (event) => {
    const { sab } = event.data;
    const intArray = new Int32Array(sab); // Create a view in the worker

    console.log('Worker sees initial value:', intArray[0]);
    intArray[0] = 100; // Worker modifies shared memory
    console.log('Worker modified value to:', intArray[0]);

    self.postMessage('Done');
};

SharedArrayBuffer 极大地提升了 JavaScript 并行计算的潜力，但同时也引入了传统多线程编程中的所有并发难题，例如数据竞争（data races）、竞态条件（race conditions）和内存一致性问题。如果不加以正确管理，这些问题将导致不可预测的行为和程序崩溃。

3. 原子操作的基石：JavaScript Atomics API

为了安全地操作 SharedArrayBuffer 中的共享数据，JavaScript 提供了 Atomics 对象。Atomics 提供了一组静态方法，用于执行原子性的读、写、修改操作，以及更高级的同步原语（如等待/通知）。原子操作保证了操作是不可分割的，即在操作执行期间，没有其他线程能够观察到该操作的中间状态，从而避免了数据竞争。

3.1 为什么需要 Atomics？

考虑以下场景：两个 Worker 同时尝试递增 SharedArrayBuffer 中的同一个计数器。

// 假设 intArray[0] 是一个共享计数器
// Worker A
let valueA = intArray[0];
valueA = valueA + 1;
intArray[0] = valueA;

// Worker B
let valueB = intArray[0];
valueB = valueB + 1;
intArray[0] = valueB;

如果没有原子性，这两个 Worker 的操作可能会交错执行，导致计数器递增不正确。例如：

1. Worker A 读取 intArray[0] (假设为 0)。
2. Worker B 读取 intArray[0] (仍为 0)。
3. Worker A 计算 0 + 1 = 1。
4. Worker B 计算 0 + 1 = 1。
5. Worker A 将 1 写入 intArray[0]。
6. Worker B 将 1 写入 intArray[0]。
   最终结果是 1，而不是期望的 2。这就是典型的竞态条件。

Atomics API 通过提供一系列原子操作来解决这个问题，确保了读-改-写（Read-Modify-Write, RMW）操作的整体性。

3.2 Atomics 核心方法概览

Atomics 对象提供了一系列方法，用于对 SharedArrayBuffer 支持的 TypedArray 进行原子操作。这些方法都是静态的，直接通过 Atomics 对象调用。

方法	描述	参数	返回值
Atomics.add(arr, idx, val)	原子性地将 val 加到 arr[idx] 上，并返回 arr[idx] 的旧值。	arr: TypedArray, idx: 索引, val: 值	arr[idx] 的旧值
Atomics.sub(arr, idx, val)	原子性地将 val 从 arr[idx] 中减去，并返回 arr[idx] 的旧值。	arr: TypedArray, idx: 索引, val: 值	arr[idx] 的旧值
Atomics.and(arr, idx, val)	原子性地对 arr[idx] 和 val 执行按位与操作，并返回 arr[idx] 的旧值。	arr: TypedArray, idx: 索引, val: 值	arr[idx] 的旧值
Atomics.or(arr, idx, val)	原子性地对 arr[idx] 和 val 执行按位或操作，并返回 arr[idx] 的旧值。	arr: TypedArray, idx: 索引, val: 值	arr[idx] 的旧值
Atomics.xor(arr, idx, val)	原子性地对 arr[idx] 和 val 执行按位异或操作，并返回 arr[idx] 的旧值。	arr: TypedArray, idx: 索引, val: 值	arr[idx] 的旧值
Atomics.load(arr, idx)	原子性地读取 arr[idx] 的值。	arr: TypedArray, idx: 索引	arr[idx] 的当前值
Atomics.store(arr, idx, val)	原子性地将 val 写入 arr[idx]。	arr: TypedArray, idx: 索引, val: 值	val (写入的值)
Atomics.exchange(arr, idx, val)	原子性地将 val 写入 arr[idx]，并返回 arr[idx] 的旧值。	arr: TypedArray, idx: 索引, val: 值	arr[idx] 的旧值
Atomics.compareExchange(arr, idx, exp, val)	原子性地比较 arr[idx] 是否等于 exp。如果相等，则将 val 写入 arr[idx]，并返回 arr[idx] 的旧值（即 exp）。否则，不进行写入，并返回 arr[idx] 的当前值。	arr: TypedArray, idx: 索引, exp: 期望值, val: 新值	arr[idx] 的旧值 (无论是否发生写入)
Atomics.wait(arr, idx, val, timeout)	如果 arr[idx] 等于 val，则阻塞直到被 notify 或超时。	arr: TypedArray, idx: 索引, val: 期望值, timeout: 毫秒数	'ok', 'not-equal', 'timed-out'
Atomics.notify(arr, idx, count)	唤醒在 arr[idx] 上等待的一个或多个 Worker。	arr: TypedArray, idx: 索引, count: 唤醒数量	实际唤醒的 Worker 数量

通过 Atomics.add()，上面的计数器问题可以得到正确解决：

// 假设 intArray[0] 是一个共享计数器
// Worker A
Atomics.add(intArray, 0, 1);

// Worker B
Atomics.add(intArray, 0, 1);

现在，即使多个 Worker 同时调用 Atomics.add，CPU 底层也会保证这个操作的原子性，确保计数器正确递增。

然而，Atomics 只能保证操作本身的原子性，它并不能神奇地解决所有并发性能问题。特别是当数据访问模式不佳时，即使是原子操作也可能因为底层硬件的限制而变得异常缓慢。这正是伪共享发挥作用的地方。

4. 深入理解 CPU 缓存与缓存行

要理解伪共享，我们必须首先理解现代 CPU 的缓存体系结构。

4.1 内存墙问题与缓存层级

CPU 的处理速度远超主内存（RAM）的访问速度。这种巨大的速度差异被称为“内存墙”（Memory Wall），它是现代计算机系统的一个主要性能瓶颈。为了弥补这种差距，CPU 引入了多级缓存（Cache）。

• L1 缓存 (Level 1 Cache)：最小、最快、最靠近 CPU 核心的缓存。通常分为指令缓存和数据缓存，容量通常在几十 KB 左右。每个核心独享 L1 缓存。
• L2 缓存 (Level 2 Cache)：比 L1 慢，但比主内存快。容量通常在几百 KB 到几 MB 之间。通常每个核心独享 L2 缓存，或者几个核心共享一个 L2 缓存。
• L3 缓存 (Level 3 Cache)：比 L2 慢，但比主内存快。容量通常在几 MB 到几十 MB 之间。通常由所有 CPU 核心共享。

当 CPU 需要访问数据时，它首先检查 L1 缓存，然后是 L2，然后是 L3，最后才是主内存。如果数据在缓存中找到（缓存命中），访问速度会非常快；如果不在（缓存未命中），则需要从下一级缓存或主内存中获取，这将导致显著的延迟。

4.2 缓存行 (Cache Line)：缓存的最小单位

CPU 缓存不是以单个字节或单个变量为单位进行数据传输的，而是以固定大小的块进行传输，这些块被称为缓存行 (Cache Line)。

• 大小: 缓存行的大小是固定的，通常为 64 字节（在 x86 和 ARM 处理器上最为常见，但具体值可能因架构而异）。
• 传输单位: 当 CPU 从主内存中读取一个字节时，它会一次性将包含该字节的整个 64 字节缓存行加载到其缓存中。同样，当 CPU 将数据写回主内存时，也是以缓存行为单位进行操作。

这个特性至关重要：即使你只需要一个字节的数据，CPU 也会加载其周围的 63 个字节。

4.3 缓存一致性协议 (Cache Coherency Protocols)

在多核系统中，每个核心都有自己的 L1/L2 缓存。为了确保所有核心对共享内存的视图是一致的，CPU 实现了缓存一致性协议。最著名的协议之一是 MESI 协议 (Modified, Exclusive, Shared, Invalid)，它定义了缓存行在不同核心缓存中的四种状态：

• Modified (M): 缓存行中的数据已被核心修改，且与主内存中的数据不一致。这是缓存行唯一的所有者。
• Exclusive (E): 缓存行中的数据与主内存一致，且只有本核心拥有该缓存行。
• Shared (S): 缓存行中的数据与主内存一致，且可能被多个核心共享。
• Invalid (I): 缓存行中的数据无效，需要从主内存或其他核心的缓存中重新加载。

关键机制: 当一个核心修改其缓存中的一个缓存行时（状态变为 Modified），它会向其他所有核心发送信号，强制它们将自己缓存中对应的缓存行标记为 Invalid。如果其他核心需要访问该缓存行中的任何数据，它们必须重新从主内存（或从拥有 Modified 状态缓存行的核心）加载最新的数据。这个过程是确保内存一致性的核心，但也是伪共享的根源。

5. 伪共享现象：问题之源

现在，我们已经理解了 CPU 缓存、缓存行和缓存一致性协议，就可以深入探讨伪共享了。

5.1 伪共享的定义与发生机制

伪共享指的是这样一种性能问题：两个或多个不相关的数据（即它们在逻辑上由不同的线程独立访问和修改），由于它们在内存中恰好位于同一个缓存行内，导致不同 CPU 核心在访问这些不相关数据时，频繁地触发缓存行的失效和同步操作，从而显著降低性能。

让我们通过一个具体的例子来理解这个过程：

假设有一个 SharedArrayBuffer，其中包含两个 Int32 类型的计数器 counterA 和 counterB，它们紧密排列在内存中，并且碰巧位于同一个 64 字节的缓存行内。

内存布局示意 (假设 4 字节一个 Int32, 64 字节一个缓存行):

+----------------------------------------------------------------+
| Cache Line 1 (64 bytes)                                        |
+----------------------------------------------------------------+
| counterA (4 bytes) | counterB (4 bytes) | ... (56 bytes unused) |
+----------------------------------------------------------------+

现在，Worker 1 负责递增 counterA，Worker 2 负责递增 counterB。

1. 初始状态: 两个 Worker 核心的缓存中都没有包含 counterA 和 counterB 的缓存行，或者缓存行状态为 Invalid。
2. Worker 1 访问 counterA:
   • Worker 1 核心需要读取 counterA。
   • CPU 将包含 counterA 的整个缓存行从主内存加载到 Worker 1 的 L1 缓存中。
   • 此时，counterA 和 counterB 都在 Worker 1 的缓存中。缓存行状态可能为 Exclusive 或 Shared。
3. Worker 2 访问 counterB:
   • Worker 2 核心需要读取 counterB。
   • CPU 将包含 counterB 的整个缓存行从主内存加载到 Worker 2 的 L1 缓存中。
   • 此时，counterA 和 counterB 都在 Worker 2 的缓存中。两个核心的缓存行状态都为 Shared。
4. Worker 1 修改 counterA:
   • Worker 1 核心执行 Atomics.add(intArray, indexA, 1)。
   • counterA 所在缓存行的状态在 Worker 1 的缓存中变为 Modified。
   • 根据缓存一致性协议，Worker 1 向其他核心（包括 Worker 2）发送信号，强制它们将自己缓存中对应的缓存行标记为 Invalid。
   • 现在，Worker 2 缓存中的该缓存行已失效。
5. Worker 2 修改 counterB:
   • Worker 2 核心执行 Atomics.add(intArray, indexB, 1)。
   • 由于 Worker 2 缓存中的缓存行已失效，它必须重新从主内存（或从拥有 Modified 状态的 Worker 1）获取最新的缓存行。
   • 获取到最新缓存行后，Worker 2 核心修改 counterB。
   • counterB 所在缓存行的状态在 Worker 2 的缓存中变为 Modified。
   • Worker 2 向其他核心（包括 Worker 1）发送信号，强制它们将自己缓存中对应的缓存行标记为 Invalid。
   • 现在，Worker 1 缓存中的该缓存行已失效。

这个过程周而复始。每次一个 Worker 修改其负责的变量时，即使另一个 Worker 修改的是同一个缓存行中的不同变量，都会导致对方的缓存行失效。结果是，两个 Worker 核心不得不反复地在缓存之间来回传递缓存行的所有权，并从主内存或其他核心中重新加载数据。这种频繁的缓存同步和数据传输开销，即使操作本身是原子性的，也会极大地拖慢程序的执行速度，这便是伪共享的危害。

5.2 JavaScript 代码示例：伪共享的演示

为了直观感受伪共享的影响，我们来编写一个 JavaScript 示例。我们将创建两个 Worker，每个 Worker 负责递增 SharedArrayBuffer 中一个独立的计数器。首先，我们故意让这两个计数器紧密相邻，以触发伪共享。

我们将使用 Int32Array，每个元素占用 4 字节。一个 64 字节的缓存行可以容纳 16 个 Int32 元素。

main.js (主线程)

// main.js
const NUM_WORKERS = 2;
const ITERATIONS = 100_000_000; // 每个 Worker 迭代次数

// 创建一个 SharedArrayBuffer 来存储两个计数器
// 故意让两个计数器紧密相邻
const sharedBuffer = new SharedArrayBuffer(NUM_WORKERS * Int32Array.BYTES_PER_ELEMENT);
const sharedCounters = new Int32Array(sharedBuffer);

// 初始化计数器
sharedCounters[0] = 0;
sharedCounters[1] = 0;

console.log('--- 演示伪共享 ---');
console.log(`SharedArrayBuffer size: ${sharedBuffer.byteLength} bytes`);
console.log(`Int32Array element size: ${Int32Array.BYTES_PER_ELEMENT} bytes`);
console.log(`Expected cache line size: ~64 bytes`);
console.log(`Counters are at indices 0 and 1, which are ${Int32Array.BYTES_PER_ELEMENT * 0} and ${Int32Array.BYTES_PER_ELEMENT * 1} bytes offset from start.`);
console.log('These are likely to be in the same cache line.');

const workers = [];
const workerPromises = [];

const startTime = performance.now();

for (let i = 0; i < NUM_WORKERS; i++) {
    const worker = new Worker('worker-false-sharing.js');
    workers.push(worker);

    workerPromises.push(new Promise(resolve => {
        worker.onmessage = (event) => {
            if (event.data === 'done') {
                resolve();
            }
        };
    }));

    worker.postMessage({
        sharedBuffer: sharedBuffer,
        counterIndex: i, // Worker 0 操作 sharedCounters[0], Worker 1 操作 sharedCounters[1]
        iterations: ITERATIONS
    });
}

Promise.all(workerPromises).then(() => {
    const endTime = performance.now();
    const duration = endTime - startTime;

    console.log(`n--- 伪共享测试结果 ---`);
    console.log(`总耗时: ${duration.toFixed(2)} ms`);
    console.log(`最终计数器值:`);
    sharedCounters.forEach((value, index) => {
        console.log(`  Counter ${index}: ${value}`);
    });
    console.log(`期望总计数: ${NUM_WORKERS * ITERATIONS}`);
    console.log(`实际总计数: ${sharedCounters[0] + sharedCounters[1]}`);

    // 清理 Workers
    workers.forEach(w => w.terminate());

    if (sharedCounters[0] + sharedCounters[1] === NUM_WORKERS * ITERATIONS) {
        console.log('原子操作确保了结果的正确性，但性能可能受伪共享影响。');
    } else {
        console.error('错误：计数结果不正确！');
    }

    // 接下来我们将演示如何解决伪共享
    // 稍后会加载另一个 worker-no-false-sharing.js 进行对比
    console.log('n请注意上述耗时，稍后我们将通过对齐来对比性能。');
});

worker-false-sharing.js (Worker 线程)

// worker-false-sharing.js
self.onmessage = (event) => {
    const { sharedBuffer, counterIndex, iterations } = event.data;
    const sharedCounters = new Int32Array(sharedBuffer);

    console.log(`Worker ${counterIndex} started, operating on index ${counterIndex}`);

    for (let i = 0; i < iterations; i++) {
        Atomics.add(sharedCounters, counterIndex, 1);
    }

    console.log(`Worker ${counterIndex} finished.`);
    self.postMessage('done');
};

运行这段代码，你会看到两个 Worker 使用 Atomics.add 分别递增各自的计数器。虽然 Atomics.add 保证了操作的正确性，但在底层，由于 sharedCounters[0] 和 sharedCounters[1] 位于同一个缓存行，它们之间的竞争会导致频繁的缓存行失效和同步，从而使得总耗时远高于没有伪共享的情况。

6. 伪共享对原子操作性能的影响

我们已经知道 Atomics API 能够保证操作的原子性，防止数据竞争导致结果错误。然而，原子操作的“原子性”主要是指其逻辑上的不可分割性，它确保了数据的一致性。但这种原子性并不意味着其执行速度不受底层硬件因素的影响。

当多个线程对位于同一缓存行内的不同变量执行原子操作时，伪共享的性能惩罚依然存在。每次 Atomics.add 或其他原子修改操作发生时，即使它只修改了缓存行内的一个小部分数据，整个缓存行也会被标记为 Modified，并触发缓存一致性协议。

• 缓存行失效: 一个核心修改缓存行，其他所有核心中该缓存行的副本都会被标记为 Invalid。
• 重新加载: 当其他核心需要访问该缓存行中的任何数据（即使是伪共享的另一个变量）时，它必须重新从主内存或拥有最新数据的核心那里加载整个缓存行。
• 总线流量和延迟: 这种反复的缓存行传输增加了系统总线流量，并引入了显著的内存访问延迟。对于每个操作，CPU 可能需要等待其他核心释放缓存行所有权，或者等待数据从主内存传输。

因此，伪共享并没有破坏原子操作的正确性，但它极大地影响了原子操作的性能。在极端情况下，伪共享可能导致多线程程序的性能比单线程版本还要差，因为并发引入的协调开销超过了并行执行的潜在收益。

性能下降的量级：伪共享带来的性能下降通常是显著的，可能是几倍甚至几十倍的差距。这对于需要高吞吐量或低延迟的并发应用来说是不可接受的。

7. 检测伪共享

伪共享是一个低层次的硬件现象，通常很难直接在 JavaScript 环境中检测到。JavaScript 运行时（V8 引擎）和浏览器抽象了底层硬件细节，不提供直接的 CPU 缓存状态或性能计数器访问。

然而，我们可以通过以下间接方法来识别或推断伪共享的存在：

1. 性能基准测试: 这是最直接和最常用的方法。

   • 设计对照实验：一个测试用例包含可能导致伪共享的数据布局，另一个测试用例通过填充等方式消除伪共享。
   • 比较两个测试用例的执行时间。如果消除伪共享的用例性能显著提升，那么伪共享很可能就是之前的瓶颈。
   • 我们的演示代码就是基于这种方法。

2. 代码审查和内存布局分析:

   • 检查 SharedArrayBuffer 中共享变量的内存布局。
   • 如果由不同 Worker 独立访问和修改的变量在 TypedArray 视图中是相邻的，且它们的总大小小于缓存行大小（通常 64 字节），那么伪共享的风险就很高。
   • 例如，在 Int32Array 中，如果 arr[0] 和 arr[1] 由不同 Worker 访问，它们就可能在同一个缓存行。如果 arr[0] 和 arr[20] 由不同 Worker 访问，则它们很可能在不同的缓存行（因为 20 * 4 = 80 字节，超过 64 字节）。

3. CPU 性能计数器 (仅适用于底层语言): 在 C++、Rust 等系统编程语言中，可以使用 perf (Linux) 或其他平台特定的性能分析工具来直接访问 CPU 的性能计数器，例如 L1/L2 缓存未命中率、缓存行失效事件等。这些指标可以直接指示伪共享的存在。但在 JavaScript 环境下，我们无法直接访问这些硬件计数器。

8. 缓解伪共享的策略：缓存行对齐

缓解伪共享的核心思想是：确保由不同线程独立访问的数据驻留在不同的缓存行中。最常见和有效的策略就是填充 (Padding)。

8.1 填充 (Padding) 的原理

填充是指在数据结构中插入一些“无用”的字节，这些字节不用于存储实际数据，但它们占据了内存空间，从而将相邻的、由不同线程访问的变量分隔开，使得每个变量（或一组由同一线程访问的变量）都能够独立地占据一个完整的缓存行。

假设缓存行大小为 64 字节，我们的目标是让每个由不同 Worker 访问的 Int32 计数器都位于其缓存行的起始位置，并且其后续数据不被其他 Worker 访问。

填充前的布局 (伪共享):
+----------------------------------------------------------------+
| Cache Line 1 (64 bytes)                                        |
+----------------------------------------------------------------+
| counterA (4B) | counterB (4B) | ... (56B unused)               |
+----------------------------------------------------------------+

填充后的布局 (无伪共享):
+----------------------------------------------------------------+
| Cache Line 1 (64 bytes)                                        |
+----------------------------------------------------------------+
| counterA (4B) | PADDING (60B)                                  |
+----------------------------------------------------------------+
+----------------------------------------------------------------+
| Cache Line 2 (64 bytes)                                        |
+----------------------------------------------------------------+
| counterB (4B) | PADDING (60B)                                  |
+----------------------------------------------------------------+

通过填充，counterA 和 counterB 现在位于不同的缓存行。当 Worker 1 修改 counterA 时，它只会使包含 counterA 的缓存行 1 变为 Modified。Worker 2 访问 counterB 时，它所在的缓存行 2 不受影响，从而避免了缓存行失效和同步开销。

8.2 JavaScript 中的填充实现

在 JavaScript 中，我们使用 SharedArrayBuffer 和 TypedArray 来手动实现填充。由于我们无法直接控制内存的字节对齐，我们只能通过在 TypedArray 的索引之间跳过足够的空间来模拟填充。

假设缓存行大小是 64 字节，Int32Array 的每个元素是 4 字节。那么一个缓存行可以容纳 64 / 4 = 16 个 Int32 元素。为了将两个计数器分隔到不同的缓存行，我们需要在它们之间插入至少 16 - 1 = 15 个“填充”元素。这样，第一个计数器占据索引 0，而第二个计数器则从索引 16 开始，确保它们在内存中至少相距 64 字节。

// main.js (消除伪共享版本)
const NUM_WORKERS_NO_FS = 2;
const ITERATIONS_NO_FS = 100_000_000;
const CACHE_LINE_SIZE_BYTES = 64; // 假设缓存行大小为 64 字节
const INT32_BYTES = Int32Array.BYTES_PER_ELEMENT; // 4 字节
const ELEMENTS_PER_CACHE_LINE = CACHE_LINE_SIZE_BYTES / INT32_BYTES; // 16 个 Int32 元素

// 每个计数器都需要一个完整的缓存行，所以我们分配 (NUM_WORKERS * ELEMENTS_PER_CACHE_LINE) 个 Int32 元素的空间
const sharedBufferNoFS = new SharedArrayBuffer(NUM_WORKERS_NO_FS * ELEMENTS_PER_CACHE_LINE * INT32_BYTES);
const sharedCountersNoFS = new Int32Array(sharedBufferNoFS);

// 初始化计数器
for (let i = 0; i < NUM_WORKERS_NO_FS; i++) {
    sharedCountersNoFS[i * ELEMENTS_PER_CACHE_LINE] = 0;
}

console.log('n--- 演示消除伪共享 (通过填充) ---');
console.log(`SharedArrayBuffer (No False Sharing) size: ${sharedBufferNoFS.byteLength} bytes`);
console.log(`Int32Array element size: ${INT32_BYTES} bytes`);
console.log(`Cache line size used for padding: ${CACHE_LINE_SIZE_BYTES} bytes`);
console.log(`Each counter will be offset by ${ELEMENTS_PER_CACHE_LINE * INT32_BYTES} bytes (${ELEMENTS_PER_CACHE_LINE} Int32 elements).`);
console.log('Counters are at indices 0 and 16, ensuring they are in different cache lines.');

const workersNoFS = [];
const workerPromisesNoFS = [];

const startTimeNoFS = performance.now();

for (let i = 0; i < NUM_WORKERS_NO_FS; i++) {
    const worker = new Worker('worker-no-false-sharing.js'); // 使用新的 Worker 脚本
    workersNoFS.push(worker);

    workerPromisesNoFS.push(new Promise(resolve => {
        worker.onmessage = (event) => {
            if (event.data === 'done') {
                resolve();
            }
        };
    }));

    worker.postMessage({
        sharedBuffer: sharedBufferNoFS,
        // 计算每个 Worker 操作的实际索引，确保它们在不同的缓存行
        counterIndex: i * ELEMENTS_PER_CACHE_LINE,
        iterations: ITERATIONS_NO_FS
    });
}

Promise.all(workerPromisesNoFS).then(() => {
    const endTimeNoFS = performance.now();
    const durationNoFS = endTimeNoFS - startTimeNoFS;

    console.log(`n--- 消除伪共享测试结果 ---`);
    console.log(`总耗时: ${durationNoFS.toFixed(2)} ms`);
    console.log(`最终计数器值:`);
    for (let i = 0; i < NUM_WORKERS_NO_FS; i++) {
        console.log(`  Counter ${i}: ${sharedCountersNoFS[i * ELEMENTS_PER_CACHE_LINE]}`);
    }
    console.log(`期望总计数: ${NUM_WORKERS_NO_FS * ITERATIONS_NO_FS}`);
    let actualTotal = 0;
    for (let i = 0; i < NUM_WORKERS_NO_FS; i++) {
        actualTotal += sharedCountersNoFS[i * ELEMENTS_PER_CACHE_LINE];
    }
    console.log(`实际总计数: ${actualTotal}`);

    // 清理 Workers
    workersNoFS.forEach(w => w.terminate());

    if (actualTotal === NUM_WORKERS_NO_FS * ITERATIONS_NO_FS) {
        console.log('通过缓存行对齐，不仅保证了正确性，也显著提升了性能！');
    } else {
        console.error('错误：计数结果不正确！');
    }

    // 对比两个测试的性能
    // 为了进行对比，我们需要将之前的伪共享测试结果保存下来
    // 假设之前的 `duration` 变量是伪共享测试的结果
    // 例如：
    // const durationFalseSharing = /* 从上一个 Promise.all 获得的 duration */;
    // console.log(`n性能对比:`);
    // console.log(`伪共享耗时: ${durationFalseSharing.toFixed(2)} ms`);
    // console.log(`消除伪共享耗时: ${durationNoFS.toFixed(2)} ms`);
    // console.log(`性能提升倍数: ${(durationFalseSharing / durationNoFS).toFixed(2)}x`);
});

worker-no-false-sharing.js (Worker 线程)

// worker-no-false-sharing.js
// 这个 Worker 脚本与 worker-false-sharing.js 几乎相同
// 唯一的区别是它接收的 counterIndex 已经经过了填充计算
self.onmessage = (event) => {
    const { sharedBuffer, counterIndex, iterations } = event.data;
    const sharedCounters = new Int32Array(sharedBuffer);

    console.log(`Worker operating on index ${counterIndex} (aligned) started.`);

    for (let i = 0; i < iterations; i++) {
        Atomics.add(sharedCounters, counterIndex, 1);
    }

    console.log(`Worker operating on index ${counterIndex} (aligned) finished.`);
    self.postMessage('done');
};

运行与对比:
当你在浏览器环境中运行这两个 main.js（你需要分别运行它们，或者将它们组织在一个更大的脚本中，确保 durationFalseSharing 变量可用），你会发现启用填充的 worker-no-false-sharing.js 组合会比 worker-false-sharing.js 组合快得多，通常是数倍甚至数十倍的性能提升。这有力地证明了伪共享的负面影响以及缓存行对齐的有效性。

表格：伪共享与缓存对齐的对比

特性	伪共享场景	缓存对齐场景
数据布局	不同线程访问的独立变量紧密相邻，共享缓存行	不同线程访问的独立变量被填充物分隔，位于不同缓存行
缓存一致性开销	高（频繁的缓存行失效与传输）	低（每个核心的缓存行独立，失效次数减少）
性能	差（多线程性能可能低于单线程）	好（充分利用多核优势，性能显著提升）
Atomics 作用	保证操作正确性，但不解决性能瓶颈	保证操作正确性，并通过对齐提升性能
内存占用	小	大（因填充而增加内存使用）
复杂性	易于实现（无需特殊处理），但性能隐患大	需要手动计算和管理填充，增加代码复杂性，但性能优异

9. 进一步优化与考虑

除了基本的填充策略，还有一些更广阔的视角和优化方法可以帮助我们更好地管理并发和避免伪共享。

9.1 数据结构设计

• 局部性原则: 将那些经常被同一线程一起访问的数据打包放在一起。这有助于提高缓存命中率，因为当线程读取其中一个数据时，其他相关数据也很可能被加载到同一个缓存行中。
• 分离独立数据: 对于由不同线程独立访问和修改的数据，确保它们之间有足够的间隔（通过填充）或将它们完全放入不同的数据结构中。
• 读写分离: 如果一个数据结构的大部分字段是只读的，而少数字段是频繁写入的，可以考虑将写入字段与只读字段分开，以减少写操作对缓存一致性的影响。

9.2 算法设计

• 数据分区 (Data Partitioning): 尽可能将数据分解成独立的、互不重叠的块，每个 Worker 负责处理自己独有的数据块。这样可以最大程度地减少对共享内存的竞争，从而避免伪共享。例如，在处理大型数组时，每个 Worker 处理一个子数组，只在最终结果合并时才进行同步。
• 减少共享写操作: 伪共享主要发生在写操作上，因为写操作会导致缓存行失效。尽量设计算法，使得共享数据的写入操作尽可能少，或者集中在特定的、受控制的区域。
• 批处理: 如果必须对共享数据进行写操作，可以考虑将多个逻辑操作合并成一个批处理操作，减少原子操作的次数，从而减少缓存同步的频率。

9.3 SharedArrayBuffer 视图的选择

SharedArrayBuffer 可以通过多种 TypedArray 视图进行访问，例如 Int8Array, Uint8Array, Int16Array, Uint16Array, Int32Array, Uint32Array, BigInt64Array, BigUint64Array, Float32Array, Float64Array。不同的视图元素大小不同：

• Int8Array: 1 字节
• Int16Array: 2 字节
• Int32Array: 4 字节
• BigInt64Array: 8 字节

在计算填充量时，必须考虑所选 TypedArray 元素的字节大小。例如，如果使用 BigInt64Array（每个元素 8 字节），那么一个 64 字节的缓存行只能容纳 64 / 8 = 8 个 BigInt64 元素。因此，填充量应为 8 - 1 = 7 个 BigInt64 元素。

// 假设使用 BigInt64Array
const CACHE_LINE_SIZE_BYTES = 64;
const BIGINT64_BYTES = BigInt64Array.BYTES_PER_ELEMENT; // 8 字节
const ELEMENTS_PER_CACHE_LINE_BIGINT = CACHE_LINE_SIZE_BYTES / BIGINT64_BYTES; // 8

// Worker 0 操作 sharedCounters[0]
// Worker 1 操作 sharedCounters[ELEMENTS_PER_CACHE_LINE_BIGINT] (即索引 8)

9.4 跨平台兼容性与缓存行大小

尽管 64 字节是 x86 和 ARM 处理器上最常见的缓存行大小，但它并非一成不变。某些老旧或特殊的架构可能有不同的缓存行大小（例如 32 字节或 128 字节）。在设计高度优化的跨平台代码时，理想情况是能够动态检测缓存行大小，但这在 JavaScript 中几乎不可能。

因此，通常的做法是：

• 保守选择: 使用 64 字节作为默认的缓存行大小进行填充，因为它在大多数现代处理器上是安全的，并能带来显著的性能提升。
• 过度填充: 如果对某个特定架构的缓存行大小不确定，可以考虑使用更大的填充量（例如 128 字节），以确保兼容性，尽管这会稍微增加内存消耗。

9.5 JavaScript 语言层面的抽象

目前，JavaScript 开发者需要手动管理 SharedArrayBuffer 的内存布局和填充。这增加了并发编程的复杂性。未来，JavaScript 语言本身或者其生态系统可能会提供更高级的抽象来简化这一过程：

• 结构化共享内存: 类似于 C++ 中的 std::atomic 变量的对齐属性，或者提供 struct 样式的内存布局，并允许指定对齐要求。
• 库支持: 可能会有第三方库封装 SharedArrayBuffer 和 Atomics，提供更高级的并发数据结构，并在内部处理缓存行对齐。

10. 性能与内存的权衡

伪共享是一个典型的性能与内存的权衡问题。通过填充来消除伪共享，可以显著提升多线程应用的性能，但代价是增加了内存的使用。在内存资源紧张的环境中，过度填充可能会成为问题。

因此，在实际应用中，开发者需要根据具体场景进行权衡：

• 高并发、性能敏感: 如果应用程序是 CPU 密集型且对性能要求极高，并且涉及多个 Worker 对共享数据的频繁写入，那么缓存行对齐是必不可少的。
• 内存受限: 如果应用程序在内存受限的环境中运行，或者共享数据的写入频率不高，伪共享的性能影响可能不那么显著，此时可以减少填充甚至不填充，以节省内存。
• 局部化设计: 最好的策略是首先通过良好的算法和数据结构设计来减少共享数据的竞争，例如尽可能地分区数据，让每个 Worker 都在其私有数据上操作。只有当共享竞争不可避免时，才考虑缓存行对齐等低层次优化。

理解并解决伪共享问题，是迈向高性能 JavaScript Web Worker 应用的关键一步。它提醒我们，即使是在高级语言中，底层硬件的运作方式依然对程序性能有着深远的影响。通过深入理解 CPU 缓存机制，并运用缓存行对齐的策略，我们能够构建出更高效、更健壮的并行应用程序。