ArrayList随机读和批量写远快于LinkedList，因内存连续性带来CPU缓存友好；LinkedList仅在极少数频繁中间增删且无需随机访问的场景可能占优，但实际大型项目中几乎不存在。
ArrayList 和 LinkedList 的读写性能差异到底在哪
结论很直接：在绝大多数真实业务场景下，ArrayList 的随机读和批量写都比 LinkedList 快得多；只有在极少数「频繁中间插入/删除 + 不关心随机访问」的链表特化场景里，LinkedList 才可能有优势——但这种场景在大型项目里几乎不存在。
根本原因不是“数组慢、链表快”这种模糊印象，而是 CPU 缓存友好性 + 内存局部性：ArrayList 的元素连续存储，遍历或按索引取值时能高效预取；LinkedList 每个节点分散在堆内存各处，一次 get(i) 可能触发多次缓存未命中，实际耗时常是 ArrayList 的 5–10 倍（尤其在数据量 > 10k 后）。
-
ArrayList.get(i)是 O(1)，底层就是数组偏移计算 -
LinkedList.get(i)是 O(n)，必须从头或尾逐个 next，没有跳转优化 - 即使你用
Iterator遍历两者，ArrayList仍大概率更快——现代 JVM 对数组循环做了大量优化（如循环展开、向量化）
压测时最容易误判的三个操作
很多团队压出“LinkedList 插入更快”的假象，其实是测法错了。真实集合操作不是孤立调用单个方法，而要还原典型业务路径。
- 只测
addLast()而忽略后续的get()或stream().filter()—— 这等于只看汽车起步加速，不看高速巡航油耗 - 用
new LinkedList()空集合压测，但生产环境里集合通常已含数万元素，此时LinkedList的遍历开销会指数级放大 - 在 JMH 测试中没加
@Fork和@Warmup，导致 JIT 尚未优化就采样，结果受解释执行干扰严重
正确做法：模拟真实链路，比如「从 DB 查 5w 条订单 → 装入集合 → 按用户 ID 过滤 → 取前 100 条」，全程对比两种集合的实际耗时与 GC 次数。
大型项目里真正该关注的集合性能瓶颈
与其纠结 ArrayList 还是 LinkedList，不如先确认这几件事：
- 是否在循环里反复调用
list.size()？这在LinkedList中是 O(n)，但很多人写成for (int i = 0; i 却没意识到代价 - 是否用
ArrayList存储了上百万对象却没预设初始容量？每次扩容触发Arrays.copyOf()复制整个数组，GC 压力陡增 - 是否把集合当缓存用（比如静态
Map存全局配置），却没考虑并发安全？ConcurrentHashMap的分段锁开销远大于集合类型本身的选择
示例：初始化 ArrayList 时，如果已知最终大小为 8000，直接写 new ArrayList(8000)，可避免至少 12 次扩容复制。
什么时候真该换 LinkedList（极少，但存在）
只有同时满足以下全部条件时，才值得考虑 LinkedList：
- 集合生命周期极短（如单次 HTTP 请求内创建 → 插入 → 删除 → 丢弃）
- 操作模式固定为「大量
addFirst()/addLast()+ 少量removeFirst()/removeLast()」，且从不调用get(i)或indexOf() - JVM 堆内存足够宽松，能容忍额外的对象头开销（每个
Node比数组元素多 16–24 字节）
注意：ArrayDeque 在上述场景中通常比 LinkedList 更优——它用循环数组实现双端队列，无节点对象开销，缓存友好，且 JDK 自带优化。别被名字骗了，它不是“数组版 LinkedList”，而是更务实的替代品。
复杂点在于：压测结果高度依赖数据规模、JVM 参数、CPU 缓存状态。同一段代码，在 16G 内存机器上跑和在容器里限制 512M 的表现可能差 3 倍。别信单次 benchmark，要结合 Arthas 观察线上 Unsafe.copyMemory 调用频次和 GC 日志里的 promotion failed 次数。
