Stream终止操作不触发GC，对象是否回收取决于强引用是否可达；终止后流不可复用，但原始集合和中间对象的存活由引用关系决定，而非流本身。
Stream终止操作本身不改变变量的引用状态，也不会触发GC；真正影响堆内存回收的，是终止后相关对象是否还被强引用可达。
终止操作只消耗流，不释放数据源或中间对象
调用 collect()、forEach()、count() 等终止操作后，Stream管道立即失效，不能再复用。但注意：
- 原始集合（如 ArrayList）仍存在于堆中，只要还有变量引用它，就不会被回收
- 中间操作生成的临时对象（如 map 后的新 Integer）是否存活，取决于它们是否被结果容器持有，而非 Stream 是否终止
- Stream 对象自身是短生命周期对象，通常在终止后很快不可达——但它不是内存压力的主要来源
关键看“谁还拿着引用”
Stream 处理过程中的变量若持有强引用，会直接阻碍 GC。常见情况包括：
- 局部变量未及时置空：比如将 stream.collect() 结果赋给一个 long-lived 局部变量，或存入 static 集合，该结果及其元素都会持续驻留
- peek 或自定义 Collector 中引入闭包引用：例如在 peek 里捕获外部对象，可能意外延长其生命周期
- 并行流使用 ThreadLocal 或共享缓冲区：ForkJoinPool 中的线程可能缓存中间状态，需结合 GC 日志观察实际回收时机
验证回收行为的实用方法
不能仅靠“流结束了”就认为对象已释放，建议通过以下方式实测：
- 用 -Xlog:gc* 启动 JVM，观察日志中是否有对应对象的回收记录
- 在终止操作后显式将关键引用设为 null（如 result = null），再强制 System.gc()（仅用于调试）对比前后堆快照
- 用 JFR 录制「Object Count」事件，筛选目标类实例数量变化趋势
- 避免依赖 finalize() 或 Cleaner，它们执行时机不确定，不能作为回收依据
变量引用失效 ≠ 对象立刻回收，GC 只响应可达性分析结果。Stream 终止只是数据处理完成的信号，后续内存命运，全看引用图里还有没有通往它的路径。
