ArrayList底层基于Object[]数组实现，非链表或哈希结构；初始化为空数组，首次添加时分配默认容量10；支持O(1)随机访问，末尾插入均摊O(1)，中间插入最坏O(n)；扩容按1.5倍增长，依赖Arrays.copyOf()拷贝；因泛型擦除使用Object[]存储，get()返回值由编译器自动强转；modCount用于fail-fast机制，校验单线程下迭代器误用，不保证线程安全。
ArrayList 底层用 Object[] 数组存储元素
ArrayList 不是链表，也不是哈希结构，它本质就是一个带自动扩容机制的 Object[]。初始化时（比如调用无参构造），elementData 字段指向一个空数组 {}，不是 null；首次添加元素时才真正分配默认容量 10 的数组。
关键点：
-
size记录当前逻辑长度（已存元素个数），和数组物理长度elementData.length是两回事 - 所有
get(i)、set(i, e)都是直接数组下标访问，O(1) 时间复杂度 - 因为基于数组，
add(e)在末尾插入是 O(1) 均摊，但add(0, e)或add(i, e)需要移动后续元素，最坏 O(n)
扩容机制：1.5 倍增长，但有边界处理
当 size == elementData.length 时，下一次 add 触发扩容。新容量计算逻辑在 grow() 方法里：
int newCapacity = oldCapacity + (oldCapacity >> 1); // 即 oldCapacity * 1.5
但要注意两个细节：
立即学习“Java免费学习笔记（深入）”；
- 如果计算出的
newCapacity溢出（比如接近Integer.MAX_VALUE），会退回到hugeCapacity(minCapacity)，尝试设为Integer.MAX_VALUE或抛OutOfMemoryError - 如果构造时指定了初始容量（如
new ArrayList(5)），扩容仍按 1.5 倍走，不会“凑整到 8/16”之类——Java 不做内存对齐优化 - 扩容涉及
Arrays.copyOf()，本质是System.arraycopy()，属于 JVM 层面的高效拷贝
为什么不用泛型数组直接声明？
你不能写 E[] elements = new E[10]，因为 Java 泛型擦除后，JVM 不知道 E 是什么类型，无法生成对应数组类。所以 ArrayList 只能用 Object[] 存储，所有 get() 返回值靠编译器自动加 (E) 强转：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
public E get(int index) {
rangeCheck(index);
return (E) elementData[index]; // 这里的 (E) 是 unchecked cast
}这就是为什么向 ArrayList 中存入错误类型（比如通过反射绕过泛型检查）会导致运行时 ClassCastException——擦除让类型安全只存在于编译期。
modCount 和 ConcurrentModificationException 的真实作用
modCount 是一个修改计数器，每次 add/remove/clear 等结构性修改都会自增。迭代器（Itr）在创建时会记录当时的 modCount 到 expectedModCount。后续每次 next() 或 remove() 都会校验两者是否一致。
这不是为了“禁止并发修改”，而是防止**单线程下误用迭代器**，比如：
- 边遍历边用
list.remove(x)（非迭代器自己的remove()） - 多个迭代器共享同一 list，一个改了另一个还在用
这个检查发生在方法入口，不依赖锁或 volatile，纯靠数值比对。如果你真需要并发写+读，得换 CopyOnWriteArrayList 或加外部同步。
ArrayList 的“动态”二字，全靠数组替换+拷贝撑着；它快在随机访问，慢在中间插入；泛型只是语法糖，运行时全是 Object；而 fail-fast 机制看着像线程安全，其实连线程安全的边都没沾上。
