System.arraycopy本身不提供结构拉平能力，其零开销仅限复制阶段；结构拉平需预分配连续数组并硬编码字段提取与索引计算，将嵌套对象的核心字段值按序写入一维数组以实现内存连续布局。
System.arraycopy 本身不提供“结构拉平”能力，它只是内存块的高效复制工具。所谓“零开销实现大对象的结构拉平”，本质是**规避对象嵌套带来的引用跳转和 GC 压力，通过预分配连续数组 + arraycopy 批量搬运字段值，把树状/嵌套结构拍平为一维数组布局**。真正的零开销只存在于复制阶段；拉平逻辑（字段提取、索引计算）仍需编码，但可做到无额外对象分配、无装箱、无反射。
明确“结构拉平”的目标形态
不是把对象转成 byte[]，而是将多个关联对象的**核心字段值**（如 int、long、float、boolean 或已预先池化的 short ID）按固定顺序，写入一个长数组（如 int[] 或 Object[]），使逻辑上“属于同一记录”的数据在内存中连续存放。
- 例如：原有一组 Order → List
- → Item {id, qty, price}
，拉平后变成一个 int[]：[order_id, item0_id, item0_qty, item0_price, item1_id, item1_qty, item1_price, ...] - 关键约束：所有字段必须是基本类型或可映射为基本类型的紧凑表示（如 enum → byte，String → interned int ID）
- arraycopy 只负责“搬数字”，不负责“理解结构”——结构规则由你定义并硬编码
用 arraycopy 替代逐字段赋值，消除循环开销
当你要把一批对象的同类型字段批量写入目标数组某一段时，避免 for 循环逐个赋值。先将这些字段提取到临时数组，再用 arraycopy 一次性拷贝。
- 错误示范（有分支、有边界检查、JIT 不易向量化）：
for (int i = 0; i - 正确做法（单次调用，CPU memcpy 级别效率）：
先用预分配的 int[] tempIds = new int[items.length];
再用循环填 tempIds（这步无法避免，但无副作用）
最后 System.arraycopy(tempIds, 0, dst, offset, items.length); - 进阶：若字段分散在不同对象中（如 orders[i].timestamp 和 items[i].qty），可先用 Unsafe.copyMemory 手动拼接，但需自行管理偏移，风险高；arraycopy 更安全可控
预计算偏移 + 分段 copy，支撑动态嵌套深度
面对变长子项（如每个 Order 有不同数量的 Item），不能用固定 stride。需两遍扫描：第一遍统计总长度并预分配 dst 数组；第二遍用累计偏移 + arraycopy 写入各段。
- 第一遍：遍历所有 Order，累加 1（order 头）+ item_count × 3（每个 Item 占 3 个 int），得到 dst 长度
- 第二遍：维护当前写入位置 pos，对每个 Order：
→ 写 order.id 到 dst[pos]（直接赋值）
→ 将其 items 的 id/qty/price 三列分别提取到三个临时数组
→ 用三次 arraycopy 把三列依次追加到 dst[pos+1] 起始处
→ pos += 1 + item_count × 3 - 优势：arraycopy 保证每段内部连续；整体仍是单块数组，缓存友好；无 ArrayList.add() 的扩容拷贝
注意事项：零开销不等于零成本
arraycopy 是 JVM 底层优化过的，但它不解决算法复杂度问题。拉平的价值在于后续遍历——你可以用纯数组下标遍历替代对象图遍历，省去大量指针解引用和 cache miss。
- 不要对小对象或低频操作拉平：对象创建开销可能小于你手写拉平逻辑的维护成本
- 避免在拉平过程中触发 GC：临时数组（如 tempIds）应复用（ThreadLocal 或对象池），否则频繁 new int[n] 会制造压力
- 无法拉平引用类型字段：如果必须保留 String 或自定义对象，要么序列化为字节存入 byte[]（配合 ByteBuffer.array() + arraycopy），要么用压缩指针数组 + 外部 lookup 表
- 调试困难：拉平后丢失原始对象语义，建议保留 debug-only 的反向重建方法
