ArrayBlockingQueue 的 capacity 创建后不可修改，因其底层采用固定长度数组存储，构造时即分配且Java数组长度不可变，所有操作依赖该数组边界；锁机制、条件队列及状态判断均严格基于初始capacity。
ArrayBlockingQueue 的 capacity 在创建后不可修改，根本原因在于它底层使用**固定长度的数组**作为存储结构，且整个类的设计基于“有界”和“线程安全”的严格契约。
数组长度在构造时就已固化
ArrayBlockingQueue 在构造时会立即分配一个指定长度的 Object[] 数组（例如 new Object[capacity]）。Java 中数组一旦创建，其长度就是 final 的，无法扩容或缩容。后续所有入队、出队、遍历等操作都依赖这个数组的边界（0 到 capacity - 1）进行索引计算和循环队列逻辑。若允许 runtime 修改 capacity，数组本身无法响应变化，整个数据结构将失去一致性。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
锁与状态机依赖固定容量
ArrayBlockingQueue 使用单个 ReentrantLock 和配套的 Condition（notFull / notEmpty）来协调生产者与消费者。它的等待/唤醒机制、size 计数、以及是否允许 offer/poll 的判断，全部基于当前 capacity 值做原子校验（如 count ）。如果 capacity 可变，锁保护的状态条件会瞬间失效——比如一个线程刚判断 “notFull” 为 true，另一线程却把 capacity 调小了，此时再入队就可能越界或破坏 FIFO 语义。
API 设计强调不可变性与可预测性
作为 JDK 并发包中明确标注 “bounded” 的阻塞队列，ArrayBlockingQueue 的核心价值之一是提供**确定性的资源上限**。capacity 不可变，意味着：
- 内存占用从创建起就可精确预估
- 线程阻塞行为（如 put() 等待）的触发阈值稳定可靠
- 与其它依赖容量语义的组件（如线程池的 workQueue 配置）能保持契约一致
替代方案：需要动态容量应选其它类型
如果业务确实需要运行时调整容量，ArrayBlockingQueue 并不适合。可考虑：
- LinkedBlockingQueue：用链表实现，构造时可传入 capacity，但同样不可变；不过无参构造默认为 Integer.MAX_VALUE，实际接近无界
- 自定义封装：用多个 ArrayBlockingQueue + 路由逻辑，或切换为 ConcurrentLinkedQueue + 外部限流（如 Semaphore）模拟有界行为
- 第三方库：如 Disruptor 提供可配置的环形缓冲区，但模型更复杂
