asLifoQueue只是为Deque套上Queue接口的薄包装，不改变底层行为、不保证线程安全、不校验null、不处理泛型擦除风险，仅适用于低频单线程临时场景；生产环境应直接使用ArrayDeque的push/pop。
asLifoQueue 是个假队列，别当真用
它不创建新队列，只是给 Deque 套了层 Queue 接口的壳，所有操作最终都转发回原 Deque。这意味着：你传进去的是 ArrayDeque，它就还是 ArrayDeque；你传进去的是线程不安全的实现，它依然线程不安全。
常见错误现象：asLifoQueue 返回对象调用 offer() 或 poll() 时行为不符合预期——比如以为会自动做栈式压入/弹出，结果发现底层仍是双端队列的默认策略（addLast/removeFirst），而没走你想要的 addFirst/removeFirst。
- 它只重写了
offer(E)→ 调用addFirst(E) -
poll()→ 调用removeFirst() -
peek()→ 调用peekFirst() - 其余方法（如
size()、isEmpty()）直接透传，不做任何栈语义适配
为什么不能用 LinkedList 传给 asLifoQueue
LinkedList 实现了 Deque，看起来合法，但它是基于链表的双向结构，每次 addFirst 都要新建节点+改指针，在高频栈操作下比 ArrayDeque 慢不少；更关键的是，它的迭代器不保证 fail-fast 行为在并发修改下稳定，而 asLifoQueue 完全不加锁。
使用场景：仅适合低频、单线程、临时包装需求。生产环境栈操作建议直接用 ArrayDeque 自己调 push()/pop()，别绕这一圈。
-
ArrayDeque内部用循环数组，push/pop是 O(1) 均摊，无对象分配 -
LinkedList的push虽也调addFirst，但每次新增节点触发 GC 压力 -
asLifoQueue(new LinkedList())返回对象的iterator()会按从头到尾顺序遍历，不是“栈序”
asLifoQueue 的 null 入参会直接 NPE
它不做空检查，传 null 进去立刻抛 NullPointerException，错误信息是：java.lang.NullPointerException: deque。这个错不在你调用栈里，而在 asLifoQueue 方法入口处就崩了。
容易踩的坑：从工厂方法或配置动态获取 Deque 实例时，忘了判空，比如：
Deque<String> stack = getStackFromConfig(); // 可能返回 null Queue<String> lifo = Collections.asLifoQueue(stack); // boom
- 必须在调用前确保
stack != null - 不能依赖返回值做空安全判断——它不返回 Optional，也不返回代理空对象
- 如果上游可能为空，要么提前兜底（如
Objects.requireNonNull(stack)），要么换用显式栈逻辑
泛型擦除导致的 ClassCastException 风险
虽然 asLifoQueue 签名是 <t> Queue<t> asLifoQueue(Deque<t> deque)</t></t></t>，但运行时泛型已擦除。如果你把一个原始类型 Deque（比如 new ArrayDeque()）传进去，再往返回的 Queue 里塞不同类型的对象，编译期不报错，运行时在 poll() 后强转时才崩。
示例：
Deque rawDeque = new ArrayDeque();
rawDeque.add("hello");
rawDeque.add(123);
Queue<String> q = Collections.asLifoQueue(rawDeque); // 编译通过
String s = q.poll(); // ClassCastException: Integer cannot be cast to String
- 永远用带泛型声明的
Deque构造，如new ArrayDeque<string>()</string> - 避免混用原始类型和参数化类型，尤其在跨模块传递时
- 这个陷阱和
Arrays.asList()的原始数组问题类似，但更容易被忽略，因为 asLifoQueue 看起来“只是个转换”
真正要用栈，就老实用 ArrayDeque 的 push/pop；asLifoQueue 存在的意义，只是让某些需要 Queue 接口的地方能临时凑合一下——但它不改变底层行为，也不修复设计缺陷，更不负责兜底。
