探讨数组复制方法的线程安全性

System.arraycopy本身线程不安全，其安全性取决于调用上下文：源数组需稳定不可变或同步更新，目标数组须独占使用；推荐采用不可变+volatile引用替换或CopyOnWriteArrayList实现线程安全。

System.arraycopy 本身不加锁、不保证原子性，也不控制共享状态——它只是高效搬运数据的底层指令。是否线程安全，完全取决于你如何组织数组的读写行为。

源数组必须稳定不可变

如果 src 数组正被其他线程修改（比如循环中执行 src[i] = newValue），arraycopy 可能复制出“撕裂快照”：前半段是旧值，后半段是新值。这不是方法缺陷，而是未同步的数据竞争。

• 推荐做法：让 src 成为只读快照，如初始化后不再变更的配置数组或预加载模板
• 若需动态更新，应在复制前完成全部写操作，并通过 volatile 引用或锁确保状态对读线程可见
• 避免在 ArrayList 扩容过程中并发调用 arraycopy —— 此时底层数组正处于被替换的临界态

目标数组要由当前线程独占

dest 数组若被多个线程复用（如全局日志缓冲区），即使各自写入不同下标范围，也存在风险：

• 写入区域必须严格不重叠，且不能有其他线程同时遍历或导出该 dest 区域
• 更稳妥方式：每次都在栈上 new 一个新数组作为 dest，用完即弃，不暴露引用
• 切忌将 dest 设为 static 或共享对象，尤其当多线程共用同一缓冲区时

同步必须覆盖整个逻辑流程

仅对 arraycopy 这一行加 synchronized，无法防止断层。真正需要保护的是“读取源状态 → 复制 → 发布结果”这一完整过程。

• 使用私有 final 锁对象（private final Object lock = new Object()），避免锁数组实例（易被外部误锁）
• 同步块内应包含状态检查、arraycopy 调用、volatile 标志置位或引用替换等关键动作
• 例如：synchronized(lock) { System.arraycopy(src, 0, dest, 0, src.length); ready = true; }

更优解：不可变 + volatile 引用替换

放弃“原地修改共享数组”，改用每次更新都生成新副本的模式，天然规避争用。

• 写线程：构造新数组 → 用 arraycopy 填充 → 用 volatile 字段原子替换引用（如 currentData = newData）
• 读线程：直接使用 volatile 引用的当前数组，全程无锁、无同步开销
• 适合读多写少场景；也可直接选用 CopyOnWriteArrayList，其 add/set 内部已封装安全复制逻辑