linkedlist适用于频繁头尾增删、需双端队列操作且无法预估容量的场景，但内存开销大、缓存不友好，多数情况下arraydeque或arraylist更优。
频繁在头部或尾部增删元素时用 LinkedList
LinkedList 底层是双向链表，addFirst()、addLast()、removeFirst()、removeLast() 都是 O(1) 时间复杂度。如果业务逻辑大量涉及队列（FIFO）或栈（LIFO）操作，比如实现任务调度缓冲区、撤销/重做栈，直接用 LinkedList 比 ArrayList 更合适。
常见错误是误以为“链表适合所有增删”，其实中间插入（如 add(int index, E element)）仍需遍历找节点，O(n) 开销不小，这时不如用 ArrayList 配合批量操作。
- 用
offerFirst()/pollLast()替代addFirst()/removeLast()，语义更清晰且兼容Deque接口 - 避免调用
get(int index)做随机访问——每次都是从头或尾开始遍历，性能陡降 - 若仅需尾部追加+头部弹出（典型队列），
ArrayDeque通常更快（数组实现、缓存友好），LinkedList反而是次选
需要实现 Deque 接口但不想要数组扩容开销
LinkedList 是 Java 中少数原生实现 Deque 的类，且不依赖数组，没有扩容机制。当元素数量波动极大、无法预估上限，又必须支持双端操作时，它比 ArrayDeque 更“省心”——不会因扩容触发大量内存复制。
但要注意：ArrayDeque 大多数场景实际性能更好，因为 CPU 缓存命中率高；LinkedList 每个节点都是独立对象，内存分散，GC 压力也更大。
立即学习“Java免费学习笔记（深入）”；
- 确认是否真需要“无限增长 + 双端操作”：如果最大长度可预估（比如日志缓冲固定 1000 条），
ArrayDeque更优 -
LinkedList的iterator()是 fail-fast 的，但迭代中调用remove()是安全的（内部会同步修改 modCount） - 不要把它当 Map 用：有人误用
LinkedList<map.entry></map.entry>实现 LRU，结果发现remove(Object o)是顺序扫描匹配，O(n) 效率远低于LinkedHashMap
对内存占用敏感时要警惕 LinkedList 的额外开销
每个 Node 对象除了存数据，还包含 prev 和 next 两个引用字段，在 64 位 JVM 上至少多占 16 字节（未开启指针压缩）。10 万个元素的 LinkedList 比同规模 ArrayList 多用近 1.5MB 内存。
这不只是“浪费空间”的问题：内存分散导致 CPU 缓存行利用率低，遍历速度可能比 ArrayList 慢 3–5 倍。
- 用 JOL（Java Object Layout）工具验证实际对象大小：
new LinkedList<integer>().size()</integer>不代表内存开销小 - 如果只是需要“保持插入顺序”，
LinkedHashSet或LinkedHashMap的键集更紧凑 - Android 开发中尤其注意：内存受限设备上，
LinkedList容易触发频繁 GC
public class NodeSizeCheck {
public static void main(String[] args) {
// 实际测试需用 JOL，此处仅示意结构
// LinkedList.Node<Integer> = { Integer item; Node<Integer> next; Node<Integer> prev; }
// 即使 item 是 Integer.valueOf(1)，Node 对象本身已含 3 个引用字段
}
}
LinkedList 真正不可替代的点很少——多数所谓“链表优势场景”，ArrayDeque、LinkedHashMap 或批量处理的 ArrayList 都能做得更好。它的存在价值，主要在教学演示链表结构、极少数必须规避数组扩容的嵌入式/实时系统，以及当你已经用了它且改起来成本太高。 
