逻辑删除是通过标记元素无效而非移动数组元素来避免System.arraycopy开销的删除方式，它保持数组物理结构不变，仅用状态位标识已删项，设标记为O(1)，遍历过滤为O(n)，适合高频增删与遍历并存的场景。
逻辑删除不是真删，而是用标记代替移动——它把“删元素”变成“标无效”，彻底绕开数组拷贝的开销。
什么是逻辑删除
逻辑删除不改变数组物理结构，只在元素旁加一个状态位（如 boolean valid 或 int flag），表示该位置“已被删除”。原数组长度、内存布局、索引关系全部保留，后续遍历时跳过 marked 项即可。
它不触发 System.arraycopy，不挪动任何元素，时间复杂度稳定为 O(1)（设标记）或 O(n)（仅遍历过滤），和删除位置完全无关。
适用场景与实现要点
适合以下情况：
- 删除操作频繁，但读取/遍历也高频（如实时日志缓冲区、游戏实体管理池）；
- 数组生命周期长、大小相对固定（如预分配的线程本地对象池）；
- 允许延迟物理清理（比如等一帧结束、或批量压缩时再真正回收）。
关键实现建议：
- 用独立布尔数组或位图（BitSet）管理有效性，避免污染业务字段；
- 维护一个有效元素计数器（size），替代原始 length 做边界判断；
- 提供 compact() 方法，在低峰期一次性前移所有 valid 元素，归并空洞——此时才触发一次 arraycopy，而非每次删除都来一遍。
对比物理删除的收益
以 10 万元素数组为例：
- 物理删除索引 500 处元素：移动约 99,500 个引用；删 10 次中间元素 → 累计移动近百万次引用；
- 逻辑删除同样 10 次：仅写 10 个布尔值，耗时微秒级；compact 一次 → 移动约 9.9 万个有效元素（假设删了 1000 个）；
- 总开销下降两个数量级以上，且响应更平稳，无突发卡顿。
配合迭代器的安全遍历
不能直接 for (int i = 0; i
推荐封装安全迭代器：
- 内部维护当前游标，自动跳过 invalid 项；
- 支持 hasNext()/next()，行为与 ArrayList 迭代器一致；
- 可选支持 remove() —— 仅改标记，不移动，仍为 O(1)。
这样上层业务代码无需感知“删没删干净”，逻辑清晰，性能可控。
