日常开发中处理队列需求时，Queue和Deque这两个接口经常让人犹豫该选哪个。我最初也混淆过，后来根据具体场景梳理清楚后，用起来就顺手多了。下面结合我的实际经验，聊聊它们的区别以及LinkedList如何实现双端队列。
Queue是单端队列，遵循FIFO原则，只能从队尾插入、队头删除。Deque是双端队列，允许在两端进行插入和删除操作，既支持FIFO也支持LIFO。在Java中，Queue接口提供了offer、poll、peek等方法，而Deque接口额外提供了addFirst、addLast、removeFirst、removeLast等操作。选择哪个接口取决于是否需要两端操作：如果只需先进先出，用Queue即可；如果需要双端操作或栈结构，则用Deque。
LinkedList同时实现了List和Deque接口，因此可以作为双端队列使用。它内部采用双向链表结构，每个节点持有前后节点的引用，使得在头部和尾部插入删除的时间复杂度均为O(1)。使用时，可以直接创建LinkedList对象并赋值给Deque类型的变量：Deque deque = new LinkedList(); 注意，LinkedList不是线程安全的，多线程环境下需加锁或使用ConcurrentLinkedDeque。
Queue与Deque的核心区别
最直观的理解是：Queue是单端队列，按照先进先出（FIFO）原则工作，只能从队尾插入、从队头删除。而Deque是双端队列，允许在两端进行插入和删除操作，既支持FIFO也支持LIFO（后进先出）。在Java中，Queue接口提供了offer、poll、peek等方法，而Deque接口额外提供了addFirst、addLast、removeFirst、removeLast等操作。选择哪个接口取决于是否需要两端操作：如果只需先进先出，用Queue即可；如果需要双端操作或栈结构，则用Deque。
这个区别听起来简单，但实际编码时容易犯错。例如，有些同事习惯用Queue引用一个LinkedList实例，后来需要从头部插入数据时，才发现Queue没有addFirst方法，只能强转成Deque或LinkedList，增加了维护成本。所以我的建议是：一开始就根据需求明确接口类型。如果只是消息队列、任务调度这类严格的FIFO场景，用Queue；如果可能涉及双端操作、需要当栈用，或者未来可能扩展，直接声明为Deque更安全。
LinkedList作为双端队列的实现
LinkedList同时实现了List和Deque接口，因此可以作为双端队列使用。它内部采用双向链表结构，每个节点持有前后节点的引用，使得在头部和尾部插入删除的时间复杂度均为O(1)。使用时，可以直接创建LinkedList对象并赋值给Deque类型的变量：Deque<String> deque = new LinkedList<>(); 注意，LinkedList不是线程安全的，多线程环境下需加锁或使用ConcurrentLinkedDeque。
用LinkedList做双端队列，最爽的一点是它既能当队列又能当栈，而且push和pop方法默认操作队头（实际调用addFirst和removeFirst），与Stack类的行为一致。所以我一般推荐用Deque代替Stack，因为Stack是线程安全的但效率低，而Deque更灵活。不过要留心：LinkedList允许存储null元素，但如果你用ArrayDeque（另一个常用实现），它不允许null。如果业务逻辑里可能出现null作为有效值，可以选LinkedList；否则ArrayDeque性能更好。
性能考量：ArrayDeque与LinkedList的取舍
谈到性能，ArrayDeque底层用循环数组实现，在大多数场景下比LinkedList性能更优，因为数组访问更连续且内存占用更小。LinkedList在频繁插入删除中间元素时更灵活，但作为双端队列使用时，ArrayDeque通常更快。注意ArrayDeque不支持null元素，而LinkedList允许。如果队列大小固定或频繁扩容，ArrayDeque可能涉及数组复制，但总体开销仍可接受。选择时，若需随机访问或包含null，用LinkedList；否则优先ArrayDeque。
我在一个缓存队列场景中测试过：用ArrayDeque和LinkedList分别作为双端队列，执行100万次offer和poll操作。结果ArrayDeque耗时大约是LinkedList的60%左右（具体数据因环境而异，这里只是方向参考）。但这不是说LinkedList就不好——如果队列中需要随机访问元素（比如通过索引取中间数据），LinkedList就没法用get(index)方法（会导致O(n)性能），而ArrayDeque也不支持随机访问。所以关键是场景匹配。
常见坑与使用注意事项
一个常见陷阱是混淆Queue和Deque的方法命名。例如，Queue的poll和peek在空队列时返回null，而Deque的remove方法在空时抛异常。另一坑点是使用LinkedList作为Deque时，误用List的get(index)方法，这会导致O(n)性能，应避免。此外，不要在迭代时修改LinkedList，否则会抛出ConcurrentModificationException。最后，注意Deque接口提供了两种迭代顺序：正向和反向，可通过descendingIterator()获得反向迭代器。
实际排错时，我有过两次教训：一次是用了deque.removeFirst()，忘记检查队列是否为空，结果抛NoSuchElementException；另一次是多线程环境下直接用LinkedList，出现数据不一致，后来改成ConcurrentLinkedDeque才解决。所以我的建议是：用Deque时优先考虑用offerFirst/offerLast和pollFirst/pollLast，它们返回特殊值而非抛异常，更安全。如果确实需要抛异常，再用addFirst/removeFirst。
场景选择与判断流程
我通常会按这个顺序判断：
- 先问是不是纯FIFO？是则用Queue接口，实现类选LinkedList或ArrayDeque（如果不需要线程安全且允许null选LinkedList，否则ArrayDeque）。
- 如果需要双端操作或栈结构，声明为Deque接口，实现类优先ArrayDeque（除非需要null或随机访问）。
- 多线程环境下必须加锁或使用线程安全类，如ConcurrentLinkedDeque（无锁）或LinkedBlockingDeque（有界阻塞）。
一点补充
如果你在维护旧代码，发现别人用LinkedList作为Queue，但后来又要从头部操作，可以考虑重构为Deque接口，但注意方法签名变化。另外，Java文档里推荐使用ArrayDeque作为双端队列和栈的首选，除非有特殊需求。这个建议我一直遵守，目前没出过问题。当然，具体选型最好结合环境确认，比如Android开发中LinkedList可能因为内存碎片导致GC压力，而服务器端通常无所谓。没有万能答案，但理解这些区别后，你至少能做出有依据的选择。