数组对象生命周期遵循Java通用规则：创建→可达→不可达→候选回收→被GC回收；基本类型数组元素内联存储，引用类型数组仅持引用，回收取决于元素是否被其他引用持有。
数组对象本身是普通Java对象，按标准生命周期管理
Java中声明的数组（如int[] arr = new int[1000]或String[] strs = new String[50]）本质上是堆上的对象，其生命周期完全遵循Java对象通用规则：创建 → 可达 → 不可达 → 候选回收 → 被GC回收。
关键点在于：数组对象 = 数组容器本身，它包含两部分信息：数组长度、元素引用（对对象数组）或原始值（对基本类型数组）。JVM把整个数组结构（包括元数据和数据区）视为一个整体对象。只要该数组对象不可达，整个结构（含所有元素内容）就成为GC候选目标。
基本类型数组：数据与对象一体，无额外引用开销
像byte[]、int[]、double[]这类基本类型数组，其元素直接内联存储在数组对象的堆内存块中。没有独立的对象引用关系，因此：
- 只要数组对象本身失去所有强引用（如局部变量置为
null、方法结束且无逃逸），整个数组内存块立即满足回收条件； - GC无需遍历元素——因为它们不是对象，不参与引用链分析；
- 常见优化场景：处理大文件读取缓冲区（
new byte[8192]）后，在方法末尾显式赋buffer = null，可帮助JVM更早识别不可达性，尤其在长方法或循环中。
引用类型数组：元素引用决定子对象存活，需分层判断
对于String[]、MyBean[]等引用类型数组，数组对象只持有各元素的引用，而非对象本身。此时垃圾回收分两层：
立即学习“Java免费学习笔记（深入）”；
-
数组对象自身：若
String[] arr变量被回收，数组容器消失，但其中每个String实例是否回收，取决于它们是否还被其他引用持有； -
数组元素对象：即使数组被回收，只要某个
arr[i]同时被另一个变量（如String s = arr[0]）引用，该String就不会被回收； - 典型陷阱：将局部数组中的对象放入静态集合（
cache.add(arr[0])），会导致数组虽已不可达，但其元素因静态引用长期驻留堆中。
实战建议：控制作用域 + 避免隐式强引用 + 合理选用引用类型
提升数组相关内存效率的关键不在“怎么建”，而在“怎么断”：
- 优先将数组声明在最小作用域内（例如循环体内
for (int i = 0; i ），避免无意提升为成员变量； - 对大对象数组（如
Image[] images），在明确不再使用后主动置images = null，尤其在Android Activity或Web请求Handler中防止内存泄漏； - 缓存场景下，不用
String[] cache存大量字符串，改用WeakReference<string>[]</string>或SoftReference包装，使GC可在内存紧张时释放； - 避免匿名内部类/lambda捕获整个数组对象（如
Arrays.stream(arr).forEach(s -> process(s))通常安全，但若lambda被存储为字段，则可能延长数组生命周期）。
补充说明：System.gc()不解决根本问题
调用System.gc()只是向JVM发出建议，无法强制回收任何数组对象。真正影响回收时机的是引用关系是否切断。监控工具（如VisualVM、JConsole）中观察到“老年代缓慢增长”，往往源于数组被静态Map或监听器长期持有——修复应聚焦于引用管理，而非触发GC。
