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 内部已封装安全复制逻辑
