add()在队列满时抛IllegalStateException，适合要求操作必须成功的场景；offer()则返回false，适用于需容忍失败的异步、限流等场景，二者语义不同不可混用。
add() 在容量不足时抛出 IllegalStateException
当 Queue 实现类有固定容量（比如 ArrayBlockingQueue），而队列已满时调用 add()，它不会静默失败，而是直接抛出 IllegalStateException。这不是业务异常，属于 unchecked 异常，不强制捕获，但一旦发生，线程会中断执行。
常见错误现象：本地测试用 LinkedList 没问题，上线换成 ArrayBlockingQueue 后突然报错，日志里只看到 IllegalStateException，没带具体消息，容易误判为其他逻辑问题。
-
add()的设计意图是“必须成功，否则报错”，适合你明确要求操作必须生效的场景 - 不是所有 Queue 都会抛这个异常——
LinkedList、PriorityQueue无容量限制，add()总返回true - 若未做 try-catch，该异常可能穿透到上层，触发线程终止或任务丢弃（尤其在 ForkJoinPool 或自定义线程池中）
offer() 在容量不足时返回 false 而非抛异常
offer() 是更温和的入队方式：无论队列是否满，它都只返回 boolean，true 表示成功，false 表示拒绝（通常因满）。它不改变线程状态，也不打断流程。
使用场景典型如异步日志采集、限流缓冲、背压处理——你不需要阻塞等待，也不希望一次失败就崩掉整个处理链路。
立即学习“Java免费学习笔记（深入）”；
-
offer(E e)是标准签名；部分实现还支持offer(E e, long timeout, TimeUnit unit)（如ArrayBlockingQueue），但那是另一个重载，和无参offer()行为无关 - 注意：
offer()返回false不一定代表“永久失败”，可能是瞬时满，下一轮重试就成功——所以别把它当成 fatal error 记录告警 - 和
add()相比，offer()的调用开销略低，因为省去了异常对象构造和栈展开成本（高频写入场景可测出差异）
别混用 add() 和 offer() 来判断队列是否满
有人会写 if (!queue.offer(e)) { handleFull(); }，这没问题；但反过来用 try { queue.add(e); } catch (IllegalStateException ignored) { handleFull(); } 就很危险。
原因不只是性能差：某些 Queue 实现（比如自定义子类或第三方库）可能对 add() 做了不同语义的重写，或者把 IllegalStateException 包装成其他异常，导致你的 catch 失效。
- 靠异常流控违背了 fail-fast 原则——你应该用可预测的返回值分支，而不是依赖异常类型做逻辑跳转
-
offer()是接口契约里明确定义“失败返回 false”的方法，add()的契约是“失败抛异常”，二者语义层级不同，不能互换用途 - 如果真要统一处理，优先选
offer()+ 显式判断；除非业务强要求“失败必须中断当前流程”，才考虑add()
ArrayBlockingQueue 和 LinkedBlockingQueue 的行为差异
两者都是常用有界队列，但默认构造行为不同，直接影响 add() 和 offer() 的表现频率。
ArrayBlockingQueue 必须指定容量，且不可扩容，所以满就是真满；LinkedBlockingQueue 构造时不传参数，默认用 Integer.MAX_VALUE 作为容量上限——表面看“几乎无限”，但实际插入 2^31-1 个元素后才会触发 add() 抛异常，日常几乎遇不到。
- 别被
LinkedBlockingQueue的“无参构造”迷惑，它仍是“有界”队列，只是界限极大；offer()在它里面基本永远返回true - 如果你需要真正无界行为（比如允许内存撑爆也不拒绝），应选
ConcurrentLinkedQueue或LinkedTransferQueue，它们的add()和offer()都不会因容量拒绝 - 生产环境配置有界队列时，建议显式传容量，并配合监控队列水位，而不是依赖
add()抛异常来发现瓶颈
ThreadPoolTaskExecutor）底层悄悄配了 ArrayBlockingQueue，而你一直用 add() 往里塞任务——某天流量高峰，线程池拒绝新任务，却只留下一个空泛的 IllegalStateException，连上下文都难定位。 
