不能完全避免扩容，但能显著推迟首次扩容时机；priorityqueue底层用object[]数组，默认初始容量11，传入initialcapacity可设数组长度，插入元素数≤initialcapacity时不会触发grow()扩容。
PriorityQueue 构造函数里 initialCapacity 真的能避免扩容吗
不能完全避免，但能显著推迟首次扩容时机。Java 的 PriorityQueue 底层用的是 Object[] 数组，默认初始容量是 11；如果构造时传入 initialCapacity，数组就按这个大小创建——前提是没传比较器或用自然顺序，否则行为一致。
关键点在于：这个容量只影响底层存储数组的长度，不改变堆结构逻辑。只要插入元素数 ≤ initialCapacity，就不会触发 grow() 扩容逻辑。
怎么正确传入 initialCapacity 参数
必须使用带 initialCapacity 的构造函数，且注意重载优先级：
-
new PriorityQueue(int initialCapacity)—— 使用自然顺序，最常用 -
new PriorityQueue(int initialCapacity, Comparator super E> comparator)—— 指定比较器，也生效 -
new PriorityQueue(Collection extends E> c)—— 这个构造函数会把c.size()作为初始容量，但内部会额外 +1，实际数组长度 ≥c.size() + 1，不是你控制的
错误写法：new PriorityQueue().ensureCapacity(100) —— PriorityQueue 没有 ensureCapacity 方法，编译不过。
扩容触发条件和实际影响
扩容发生在 offer(E e) 或 add(E e) 过程中，当 size == queue.length 时调用 grow()。默认 grow 策略是：旧容量
所以预设 initialCapacity=100 后，前 100 次 offer 完全无扩容开销；第 101 次才会分配新数组（约 150 长度），并复制元素。
容易踩的坑：
- 误以为
initialCapacity是“最小容量”，其实它就是数组起始长度，过大会浪费内存 - 在多线程场景下仍需同步，
initialCapacity不解决并发问题 - 如果后续反复
poll()再offer()，数组长度不会缩容，只增不减
结合使用场景选值的建议
不要拍脑袋定数字。观察你业务中「峰值待处理任务数」或「典型批次大小」：
- 定时批处理 50 条消息 → 设
initialCapacity=50或稍留余量（如 64） - 实时日志缓冲队列，平均积压 200 条 → 直接设 256，避开第一次扩容的 1.5 倍跳变点
- 不确定规模？宁可略高，也不要依赖默认 11 —— 12 次插入就扩容，代价比预分配明显
真正容易被忽略的是：PriorityQueue 的「容量」概念和 ArrayList 不同——它不提供 size() 以外的容量查询接口，也没办法 runtime 调整底层数组大小。一旦建好，initialCapacity 就锁死了扩容起点。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
