ArrayList扩容机制是：首次添加元素时初始化容量为10，后续按1.5倍（oldCapacity + oldCapacity>>1）扩容，通过Arrays.copyOf复制数组实现，耗时O(n)，非线程安全。
不能通过反射安全、可靠地“修改集合大小”来动态干预ArrayList的elementData扩容机制。
反射无法绕过扩容逻辑的本质
ArrayList的容量控制不是仅靠size字段决定的，而是由elementData.length（底层数组长度）和内部扩容流程共同保障的。即使你用反射强行修改size字段：
- 它只影响
get()、set()、remove()等方法的行为边界，不会改变数组实际能容纳多少元素； -
add()仍会检查size + 1 > elementData.length，触发grow()——此时若size被人为调大，反而可能立即抛ArrayIndexOutOfBoundsException或导致数组越界写入； - 修改
elementData本身（如替换为更小/更大的数组）会破坏内部一致性，后续操作（如addAll()、iterator()）极易出错或抛ConcurrentModificationException。
常见误操作及其风险
有人尝试用反射“提前扩容”或“伪造已填充状态”，例如：
- 反射设置
size = 100后直接set(99, x)：若elementData.length ，运行时直接报错； - 反射替换
elementData为一个new Object[1000]：虽看似“扩容”，但size仍为0，add()从索引0开始写，旧数据丢失，且ensureCapacityInternal()后续仍按原逻辑判断，可能再次触发无谓扩容； - 在多线程中反射修改：ArrayList本就不保证线程安全，反射操作更无同步保障，极易引发数据错乱或JVM崩溃。
真正可控的干预方式
Java提供了公开、安全、语义明确的替代方案，无需反射：
-
预设容量：构造时传入合理初始值，如
new ArrayList(2048)； -
主动预扩容：调用
ensureCapacity(int minCapacity)，例如list.ensureCapacity(5000)，它会按1.5倍规则扩容到不低于该值的最小容量； -
批量添加前预留：对已知集合，用
addAll()而非循环add()，底层会一次性计算所需容量并扩容； -
使用Guava工具类：如
Lists.newArrayListWithCapacity(1000)，语义清晰且避免手误。
为什么反射方案在生产环境不可取
反射操作破坏封装性，依赖内部字段名和实现细节（如elementData、size、DEFAULT_CAPACITY），而这些在不同JDK版本中可能调整。自Java 9起，模块系统进一步限制对java.base包内私有字段的反射访问，运行时可能抛InaccessibleObjectException。性能上也无优势——真正的扩容是Arrays.copyOf，反射只是改个数字，不解决内存分配与复制问题。
