Queue接口是约定行为的契约，不保证FIFO但标准实现默认遵循；add()失败抛异常，offer()返回false更安全；poll()/peek()空时返回null，remove()/element()则抛异常；ArrayDeque适合单线程高性能，LinkedBlockingQueue和queue.Queue才用于多线程。
Queue 接口不是“一个队列”，而是一套**约定行为的契约**——它不保证 FIFO，但所有标准实现（如 LinkedList、ArrayDeque）默认都按 FIFO 运作；真要打破这个规则，得靠 PriorityQueue 或手动实现。
为什么 add() 和 offer() 都要学？别只用一个
它们干的都是“往队尾塞元素”，但失败时反应完全不同：add() 直接抛 IllegalStateException（有界队列满时）或 NoSuchElementException（某些特殊实现），而 offer() 宁可返回 false 也不崩。生产代码里几乎从不用 add()，尤其在不确定容量或并发场景下。
- 用
offer()：适合需要容错、不想被异常打断流程的场景，比如任务批量入队 - 用
add()：仅限调试或明确知道队列永远不满（如无界LinkedList+ 小数据量），否则等于埋雷 - 注意：
ArrayDeque是无界的，offer()几乎总返回true；但LinkedBlockingQueue设了capacity后，offer()就可能失败
poll() vs remove()：空队列时的行为差异必须刻进本能
这是新人踩坑最密集的点——两个方法都“拿走队头并返回”，但空的时候：poll() 安静地返回 null，remove() 狂甩 NoSuchElementException。线上服务一旦在没判空的情况下调 remove()，就是 500 起手式。
- 日常取数优先写
if (!queue.isEmpty()) { queue.poll(); }，而不是赌运气 - 如果业务逻辑要求“必须拿到一个值，否则报错”，才考虑
remove()，且得包try-catch -
peek()和element()也是同理：前者空时返null，后者直接炸——别图省事少写个if就换element()
Python 的 queue.Queue 和 Java 的 Queue 不是同一类东西
名字像，但定位完全不同：Java 的 Queue 是集合接口，轻量、非线程安全、纯内存操作；Python 的 queue.Queue 是为多线程设计的阻塞队列，自带锁、支持 block/timeout、甚至能 join() 等待任务完成。拿 Python 的 queue.Queue 当普通容器用，性能会掉一截；用 Java 的 LinkedList 去做跨线程任务分发，大概率出竞态。
- 单线程/高性能场景：Java 用
ArrayDeque，Python 用collections.deque - 多线程任务传递：Java 选
LinkedBlockingQueue，Python 必用queue.Queue - 别把
queue.Queue.qsize()当实时准确值用——它只是快照，多线程下可能刚读完就变了
循环队列和链式队列的底层选择，其实早被封装掉了
你不需要手写 front/rear 指针或处理“假溢出”——ArrayDeque 内部就是优化过的循环数组，LinkedList 就是链式结构，API 完全一致。真正该关心的是：什么时候该换实现？
- 高频出入队 + 内存敏感 →
ArrayDeque（数组连续，缓存友好，无 GC 压力） - 需要稳定 O(1) 插入/删除 + 不介意指针开销 →
LinkedList（但注意，它不是为 Queue 场景优化的，ArrayDeque多数时候更快） - 千万别用
Stack或Vector模拟队列——Stack是 LIFO，Vector是同步但过时的包袱
offer() 返回 false 不一定代表内存满了，可能是流控策略、背压信号，或是分布式队列里的远程拒绝。 
