数组拷贝决定副本独立性，直接影响缓存一致性风险：未拷贝则共享内存引发伪共享，拷贝后物理隔离可规避跨核缓存行争用；arrays.copyof()和system.arraycopy()生成新数组，天然避免false sharing，并在序列化、多级缓存等场景中防止脏读与状态不同步。
数组拷贝本身不是缓存一致性协议的一部分，但它在多核并发场景中会直接触碰缓存一致性的边界——尤其当多个线程共享数组引用、或在本地缓存与分布式缓存之间搬运数组数据时，拷贝行为决定了是否引入脏读、伪共享或状态不同步风险。
拷贝决定副本独立性，影响缓存行竞争
未拷贝的数组引用意味着多个线程操作同一块内存地址。即使每个线程只读不写，若该数组被映射到同一缓存行（64字节），一个线程修改相邻字段（如结构体数组中的某个成员）也可能导致其他线程所在核心的整个缓存行失效（false sharing）。而一次 Arrays.copyOf() 或 System.arraycopy() 生成新数组，就让数据物理隔离，天然避开跨核缓存行争用。
- 例如：两个线程分别更新 int[] 中下标 0 和下标 1 的值，若数组起始地址对齐且长度足够小，这两个元素很可能落在同一缓存行 → 触发频繁的缓存行无效化与重载
- 显式拷贝后，每个线程操作独立数组，各自缓存行互不影响
序列化过程中的拷贝是防“缓存污染”的关键环节
分布式缓存（如 Redis）写入含原始数组字段的对象时，若未深拷贝 byte[] 或 int[]，业务代码后续修改该数组，会意外改变已序列化并写入缓存的数据内容——这不是缓存一致性协议能解决的问题，而是应用层数据生命周期管理缺失所致。
- JDK 原生序列化会自动复制数组字段；但 JSON 序列化（如 Jackson）默认不保证，需手动拷贝或使用不可变封装
- Spring Cache 的
@Cacheable方法若返回数组类型，框架不自动拷贝，调用方拿到的仍是原始引用，多线程环境下极易出错
多级缓存协同依赖拷贝保障局部一致性
本地缓存（如 Caffeine）从 Redis 加载 int[] 类型的 SKU 列表后，若直接赋值而非拷贝，该数组可能同时被后台任务修改、被前端请求读取，造成本地缓存与分布式缓存视图不一致——此时缓存一致性协议（如 MESI）无法干预，因为问题发生在应用逻辑层。
- 拷贝使本地缓存持有“快照”，与远程缓存形成逻辑隔离，避免因共享引用导致的时序错乱
- 构建布隆过滤器、批量预热 key 等场景中，拷贝还能防止多线程写入冲突，降低 L1/L2 缓存行失效频率
拷贝方式影响 CPU 缓存访问效率
拷贝不是越快越好，而是要匹配缓存行特性。小数组用循环赋值更高效（L1 全驻留、无函数开销）；中等数组用 System.arraycopy()（底层调用 memcpy，支持 AVX 加速）；大数组则需关注地址对齐与分块，否则即使用了高效拷贝，也会因跨缓存行读写拉低吞吐。
- 未对齐拷贝（如源地址偏移 17 字节）会导致单次读取跨两个物理缓存行，浪费总线带宽
- 顺序拷贝天然友好；跳读（stride > 1）或分散写入（scatter）会破坏空间局部性，大幅降低缓存命中率
