ArrayDeque 明令禁止插入 null，所有插入方法均在开头检查并抛 NullPointerException；根源在于其循环数组依赖 head==tail 判空，无法区分空队列与含 null 元素，否则需重写全部逻辑。
ArrayDeque.add(null) 直接抛 NullPointerException
它不是“不推荐”，而是明令禁止——add、push、offer、addFirst 等所有插入方法，只要传入 null，立刻抛 NullPointerException。这不是警告，是硬性契约。
- 源码里每处插入逻辑开头都有
if (e == null) throw new NullPointerException(); - 哪怕你用反射绕过检查，后续
poll/pop时可能因内部指针错位导致诡异行为 - 和
HashMap允许null键值不同，ArrayDeque的设计从根上就拒绝null语义
为什么不允许？根源在循环数组的判空逻辑
ArrayDeque 用 head 和 tail 两个索引管理一个循环数组，靠 head == tail 判断队列为空——但这也意味着：它无法区分“队列空”和“存了一个 null 后刚好填满又弹出”的状态。
- 没有额外空间或标记位记录某个位置是否是“真实
null”还是“未使用” - 若允许
null，扩容、遍历、size()计算等所有逻辑都要重写边界判断，性能与简洁性双输 - 对比
LinkedList（基于节点对象，天然可存null），ArrayDeque的紧凑数组模型决定了它必须牺牲这一灵活性
替代方案：别硬塞 null，改用 Optional 或哨兵值
业务中真需要表达“缺失/未初始化”语义时，强行塞 null 只会让问题后移；应让语义显式化。
- 用
Optional<string></string>包装元素，插入Optional.empty()而非null - 定义明确的哨兵对象，比如
private static final String MISSING = "MISSING"; - 如果必须和遗留 API 对接且对方返回
null，请在进队前做转换：queue.offer(str != null ? str : MISSING);
和其他容器混用时的隐性风险
当把 ArrayDeque 当作通用容器传递给泛型工具方法，尤其涉及 Collection 接口操作时，容易踩坑。
立即学习“Java免费学习笔记（深入）”；
-
Collection#removeAll(null)不会报错，但ArrayDeque#removeAll(Collections.singleton(null))会触发内部遍历并抛 NPE -
Stream.of(queue.toArray()).filter(Objects::nonNull)看似安全，但如果 queue 本身已因非法插入崩溃，这行代码根本执行不到 - 序列化/反序列化时，若某次误存了
null导致对象损坏，错误往往出现在下游消费端，而非插入点
deque.add(x == null ? "NULL_PLACEHOLDER" : x)，这个分支就会悄悄蔓延到日志、监控、告警路径里——而 ArrayDeque 的设计初衷，就是用编译期/运行期的刚性约束，逼你从第一行就面对“这个值到底有没有意义”这个问题。 
