用linkedlist当队列时，应避免list接口的add(0)/remove(0)/get(i)等o(n)操作，而应使用deque接口的addfirst()/removefirst()、addlast()/removelast()等o(1)方法。
用 LinkedList 当队列时，性能陷阱往往不是出在“用了它”，而是出在“怎么用”——尤其容易误用 List 接口的方法，忽略它作为 Deque 的本质优势。
别用 List 接口的 add(0) / remove(0) 模拟队头操作
很多人写队列逻辑时习惯调用 list.add(0, item) 或 list.remove(0)，这看似是“加到队头/删队头”，但实际触发的是 LinkedList 的 add(int index, E) 和 remove(int index) 方法。这两个方法必须先遍历到第 0 个位置（哪怕只是头节点），时间复杂度仍是 O(n)，完全浪费了链表头指针的 O(1) 能力。
- ✅ 正确做法：用 Deque 接口专属方法 ——
addFirst()、removeFirst()、offerFirst()、pollFirst() - ✅ 同理，尾部操作用
addLast()/removeLast()或offerLast()/pollLast() - ❌ 避免：任何带索引参数的
add(i, x)、remove(i)、get(i)，哪怕 i 是 0 或 size-1
避免在循环中调用 get(i) 实现“按序处理”
有些业务会把 LinkedList 当成普通列表来遍历，比如用传统 for 循环做“取第 1 条、第 2 条……直到第 n 条”，代码像这样：
for (int i = 0; i String msg = list.get(i); // 危险！每次 get(i) 都从头遍历
// 处理 msg
}
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
哪怕只有 1000 条消息，总遍历步数接近 50 万次（1+2+…+1000）。这不是慢，是指数级浪费。
- ✅ 正确做法：用增强 for 循环（底层调用迭代器）或显式使用
Iterator - ✅ 若需边遍历边删除（如消费后移除），直接用
iterator.remove()—— LinkedList 下这是 O(1) 操作 - ✅ 更现代写法：用
forEach()或流式处理（但注意：stream().forEach()底层仍走迭代器，安全；stream().skip().limit()则可能触发多次遍历，慎用）
警惕“看似合理”的随机访问需求
业务中常出现类似“取最新 5 条”“跳过前 10 条”“查第 N 条重试消息”这类需求。这些听起来像“队列功能”，实则悄悄引入了随机访问语义，而 LinkedList 对此毫无优化。
- ⚠️
list.subList(size - 5, size)：内部仍要遍历定位起始位置，O(n) - ⚠️
list.get(size - 1)：虽靠近尾部，但 LinkedList 会判断是否从 tail 倒着遍历（有优化），可仍需约 size/2 步，不稳定 - ✅ 替代方案：
– 若只需尾部数据，维护一个独立的ArrayDeque或固定大小的ArrayList缓存最近 N 条；
– 若真要支持高效随机访问 + 高频头尾增删，考虑用ArrayDeque（循环数组，头尾 O(1)，随机访问 O(1)，内存更紧凑）；
– 极端场景下，自定义带索引缓存的双端结构（但多数业务不值得）
别忽略内存与 GC 成本
每条消息在 LinkedList 中不是一个引用，而是一个完整 Node 对象（item + prev + next），至少多占 16–24 字节。当队列长期持有数万条消息时，额外内存可达 MB 级，GC 压力上升，可能引发 STW 延迟毛刺。
- ✅ 控制队列长度：设置合理上限，配合
pollFirst()+size()做主动截断 - ✅ 优先考虑
ArrayDeque：它用循环数组实现 Deque，头尾操作同为 O(1)，无额外对象开销，JDK 官方也明确推荐它替代 LinkedList 作队列/栈 - ✅ 若必须用 LinkedList（如需频繁中间删除），确保及时清理不再引用的节点（避免强引用导致 GC 不回收）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
