能，但仅限于前initialCapacity个元素插入阶段；一旦超限即触发扩容，后续按1.5倍增长。
ArrayList 初始化时指定初始容量能避免扩容吗
能，但仅限于前 initialCapacity 个元素插入阶段。一旦元素数量超过该值，ArrayList 就会触发第一次扩容。
默认无参构造函数创建的 ArrayList 使用空数组（DEFAULTCAPACITY_EMPTY_ELEMENTDATA），首次 add() 时才扩容到 10；而传入 new ArrayList(100) 会直接分配长度为 100 的 Object[] 数组，跳过前两次扩容开销。
常见误判是认为“初始化容量 = 最终容量”，其实它只是起点——后续仍可能多次扩容：
- 扩容发生在
add()、addAll()等写操作中，非读操作 - 扩容不是按固定步长增长，而是当前容量 * 1.5（JDK 8+），向下取整后加 1（如 10 → 15 → 22 → 33…）
- 若预估容量严重不足（比如初始化为 10，却要塞 1000 个元素），会经历约 8 次扩容 + 数组拷贝，性能损耗明显
HashMap 的 initialCapacity 和 loadFactor 怎么配合使用
initialCapacity 不是桶数组的最终长度，而是「内部会向上取整为 2 的幂次」后的值；loadFactor 决定何时触发扩容——当 size > capacity × loadFactor 时扩容。
立即学习“Java免费学习笔记（深入）”；
例如：new HashMap(10, 0.75f) 实际桶数组长度为 16（≥10 的最小 2 的幂），阈值（threshold）为 16 × 0.75 = 12。第 13 次 put() 才触发扩容至 32。
容易踩的坑：
- 传入奇数或质数作为
initialCapacity（如 7、19）毫无意义，内部全被转成 8、32 等 2 的幂 -
loadFactor过小（如 0.5）会导致频繁扩容；过大（如 0.9）虽节省空间，但哈希冲突概率上升，链表/红黑树查找变慢 - 如果明确知道键数量（比如 1000 个用户 ID），推荐：
initialCapacity = (int) Math.ceil(expectedSize / loadFactor)，再由 HashMap 自动对齐到 2 的幂
LinkedList 初始化时传入 Collection 会触发扩容吗
不会。因为 LinkedList 是双向链表实现，没有“容量”和“扩容”概念——每个元素都单独分配节点对象（Node），插入只涉及指针重连。
所以 new LinkedList(someList) 只是遍历原集合，逐个调用 addLast()，时间复杂度 O(n)，但全程无数组拷贝、无内存重分配。
不过要注意副作用：
- 即便传入空集合，也会新建一个空的
header节点（JDK 8 中是first = last = null，但逻辑上仍需维护头尾引用） - 相比
ArrayList，LinkedList的内存开销更大（每个元素额外两个引用字段），随机访问慢（O(n)），仅在频繁首尾增删时有优势 - 它的「初始化」本质是构建链表结构，不是预分配连续内存，所以谈不上“扩容机制”
ConcurrentHashMap 在多线程下如何控制扩容节奏
JDK 8+ 的 ConcurrentHashMap 把扩容拆成多个段（transferIndex 分片），由多个线程协作完成，不阻塞读写。扩容触发条件仍是 size > capacity × loadFactor，但行为完全不同：
当一个线程发现需要扩容，它会尝试推进迁移进度（从高位桶开始搬数据），其他线程在 put 时若碰到正在迁移的桶（ForwardingNode），也会顺手帮搬几个桶，直到全部迁移完成。
关键细节：
- 扩容不是全量复制，而是分段迁移，每段大小为 16 个桶（
MIN_TRANSFER_STRIDE） - 扩容期间读操作不受影响（旧桶仍可读），写操作会先协助迁移再写入新桶
- 初始容量建议设为 2 的幂，否则会被自动提升（如传 10 → 实际用 16），且并发度参数（
concurrencyLevel）在 JDK 8+ 已被忽略，仅保留向后兼容
真正难处理的是扩容过程中的中间态：某个桶已迁移，另一个还没动，这时候遍历（keySet() 或 entrySet()）返回的结果可能不一致——这不是 bug，是设计使然。
