应使用 queue queue = new linkedlist() 面向接口编程，避免暴露链表索引操作；优先用 offer()/poll() 而非 add()/remove() 以安全处理边界；有界场景需封装原子性容量控制，arraydeque 性能更优但 linkedlist 在需中间操作、gc 敏感或兼容 list 时仍必要。
用 LinkedList 当 Queue 接口实现类，而不是直接 new
直接 new LinkedList() 并赋值给 LinkedList 类型变量，会暴露不必要的链表操作（如 get(int)、remove(int)），破坏队列语义，也容易误用索引导致 O(n) 查找。正确做法是面向接口编程：Queue<string> queue = new LinkedList();</string>。这样编译器只允许调用 offer()、poll()、peek() 等标准队列方法，天然约束为 FIFO 行为。
offer() 和 poll() 是首选，别用 add() 或 remove()
add() 与 remove() 在队列为空或满时抛异常，而真实任务场景中空队列出队、满队列入队是常态——比如消费者线程轮询但暂无任务，或突发流量压入超限。用 offer() 返回 boolean 可显式处理失败；poll() 返回 null 比捕获 NoSuchElementException 更轻量、更符合异步/非阻塞逻辑。
-
queue.offer(task)：成功返回true，失败（如人为限制容量）返回false，不打断流程 -
Task t = queue.poll()：有任务就取，没任务得null，可立即 continue 或 sleep - 避免
queue.add(task)—— 一旦底层被改造成有界队列（如包装成固定长度），它会炸
性能上，ArrayDeque 通常比 LinkedList 更快，但 LinkedList 仍有不可替代场景
ArrayDeque 基于循环数组，内存局部性好，offer()/poll() 均为均摊 O(1)，且无节点对象开销。多数纯 FIFO 场景应优先选它。但 LinkedList 在以下情况仍有必要：
- 需要在队列中间插入/删除（虽违背 FIFO，但某些调度策略需动态调整）
- 对 GC 敏感且元素生命周期极短——
LinkedList节点可被快速回收，而ArrayDeque数组扩容会产生旧数组残留 - 已有代码强依赖
List接口（如需list.subList()做切片分析），而ArrayDeque不实现List
要加长度限制？别手写 removeFirst()，用封装好的有界队列逻辑
想让队列最多存 200 个任务，直接在每次 offer() 后检查 size() 并手动 removeFirst() 是错的：竞态条件下可能漏删或多删，且破坏了单次操作的原子性。正确方式是封装一个固定容量队列类，或直接换用 LinkedBlockingQueue（带锁）或 ConcurrentLinkedQueue + 外部计数（无锁）。如果坚持用 LinkedList，至少把容量控制逻辑收进单一方法：
public class BoundedQueue<t> {
private final int capacity;
private final LinkedList<t> delegate = new LinkedList();
public BoundedQueue(int capacity) {
this.capacity = capacity;
}
public boolean offer(T e) {
if (delegate.size() >= capacity && !delegate.isEmpty()) {
delegate.removeFirst(); // 踢掉最老任务
}
return delegate.addLast(e); // addLast() 等价于 offer()
}
public T poll() { return delegate.pollFirst(); }
}</t></t>
注意：这个类不是线程安全的；多线程下必须加同步，或改用并发集合。
真正容易被忽略的是边界一致性——size() 检查和 removeFirst() 不是一次原子操作，裸用必出竞态。哪怕只是单线程批量处理，也要把“检查+裁剪”锁在一个方法里，否则日志里突然冒出 201 条任务，你就得翻半天。
