核心是避免一次性加载、减少驻留时间、控制引用生命周期：用流式处理替代全量加载，预估集合容量，善用弱/软引用和对象池，结合MAT等工具定位大对象滞留问题。
处理大型内存对象导致的溢出，核心是避免一次性加载、减少驻留时间、控制引用生命周期。不能只靠调大堆内存，关键在于让大对象“进得合理、存得短暂、退得及时”。
避免一次性加载大对象
比如从数据库查几百万条记录转成 List
- 用流式处理替代全量加载：JDBC 查询启用
fetchSize+ResultSet.TYPE_FORWARD_ONLY，逐批处理；文件读取用InputStream分块读，而非Files.readAllBytes() - 对集合类做容量预估：如明确知道要存 10 万条，初始化
new ArrayList(100000)，避免扩容带来的临时数组复制开销 - 用迭代器或 Stream API 处理大数据集，配合
limit()、skip()或自定义分页逻辑
缩短大对象生命周期
即使对象本身不大，若长期被静态集合、缓存、监听器等意外持有，也会累积成“隐性大对象”。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 检查
static Map、static List是否无限制地 put 对象，尤其注意缓存未设 TTL 或淘汰策略 - 避免在 Lambda 或匿名内部类中隐式持有外部大对象（如把整个 Service 实例传进线程池任务）
- 用局部变量承载中间结果，方法结束即自然脱离作用域；必要时显式置为
null（仅对长生命周期引用有意义）
善用替代结构与引用类型
不是所有“大”都必须是堆内对象——可换存储位置或降低 GC 压力。
立即学习“Java免费学习笔记（深入）”；
- 超大字节数组优先考虑
ByteBuffer.allocateDirect()（分配在直接内存），但需手动清理cleaner或依赖系统回收 - 缓存场景下，对非关键数据使用
WeakReference或SoftReference包装，让 GC 在内存紧张时自动释放 - 高频创建/销毁的固定结构对象（如 DTO、VO），考虑对象池（如 Apache Commons Pool 或 JBoss Pool），复用实例而非反复 new
快速定位与验证
光靠日志很难判断是不是大对象惹的祸，得靠工具抓现场。
- 启动时加参数
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof，OOM 后自动生成堆快照 - 用 MAT（Memory Analyzer Tool）打开 dump 文件，按“Dominator Tree”看谁占内存最多，再点开“Path to GC Roots”确认是否被意外强引用
- 结合
jstat -gc <pid>观察老年代增长趋势，若每次 Full GC 后老年代使用率不降，大概率存在泄漏或大对象滞留
