应优先阅读源码并辅以反编译验证，因ArrayList扩容逻辑完全由Java层控制，字节码仅呈现底层指令而无法体现设计意图与工程权衡。

直接看字节码对理解 ArrayList 扩容机制帮助有限，真正高效的方式是结合源码 + 反编译验证关键逻辑，而不是逐行分析 class 文件的字节码指令。

为什么不需要深挖字节码

ArrayList 的扩容行为完全由 Java 层代码控制（add → ensureCapacityInternal → grow），不涉及 JVM 特殊指令或本地方法。它的核心操作——比如数组拷贝（Arrays.copyOf）、位运算（oldCapacity >> 1）、条件判断——在字节码中只是常规的 invokestatic、ishl、if_icmpge 等指令，可读性差且不反映设计意图。

• 扩容的“1.5 倍”逻辑体现在源码的 oldCapacity + (oldCapacity >> 1)，反编译后能看到相同表达式，但字节码只显示底层计算步骤，不体现工程权衡
• transient 字段、modCount 自增、空数组区分（DEFAULTCAPACITY_EMPTY_ELEMENTDATA vs EMPTY_ELEMENTDATA）等关键设计，必须读 Java 源码才能理解上下文
• JDK 自带的 javap -c 输出冗长，例如 grow() 方法可能生成 20+ 行指令，但真正影响行为的只有容量计算和数组复制两处

推荐的三步验证法

用反编译作为辅助手段，聚焦验证源码中易被忽略的细节：

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• 确认默认容量触发时机：写一个空参构造的 ArrayList 并调用 add("a")，用 javap -c 查看 add 方法调用链，会看到它确实先跳转到 ensureCapacityInternal，再进入 calculateCapacity —— 这印证了“容量不是构造时分配，而是首次 add 时才设为 10”
• 验证 1.5 倍是整数位运算：反编译 grow 方法，找到类似 iload_1; iconst_1; ishr; iadd 的指令序列，对应 oldCapacity >> 1 再加原值，说明没有用浮点乘法，避免精度与性能损耗
• 检查 MAX_ARRAY_SIZE 边界处理：在扩容逻辑中搜索 Integer.MAX_VALUE - 8 相关分支，反编译后能看到 if_icmpgt 跳转到 hugeCapacity，证实该限制真实参与运行时判断，不是注释摆设

实操建议

日常调试和学习优先使用以下方式：

立即学习“Java免费学习笔记（深入）”；

• 下载对应 JDK 版本的 src.zip（如 JDK 17 的 java.base 模块源码），在 IDE 中直接跳转阅读 ArrayList.java
• 用 IDEA 的 “Jump to Source” 功能跟踪 add → grow 调用链，配合断点观察 elementData.length 和 size 的变化
• 仅当怀疑编译器优化或泛型擦除影响行为时（例如 ArrayList<string></string> 和 ArrayList<object></object> 编译后是否一致），再用 javap -v 对比字节码；扩容本身与此无关

字节码是底层快照，源码才是设计蓝图。把精力放在读懂 grow() 里那十几行 Java 代码，远比解析 50 行字节码更能掌握扩容本质。