SpringBoot多线程OutOfMemoryError问题排查求助

1. 自动生成堆转储定位内存占用 #

给JVM添加启动参数，让OOM触发时自动生成堆转储文件，这是定位根因的核心手段：

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/your/local/dump/path

用Eclipse Memory Analyzer (MAT) 打开转储文件，重点分析：

• 占比Top 10的对象类型：排查是否存在超大集合、未释放的IO资源或静态变量引用的大对象
• 对象引用链：追踪哪些对象持续被持有无法被GC回收（比如线程池任务、ThreadLocal、全局缓存）
• 元空间使用情况：如果是Metaspace类型OOM，检查是否有大量动态生成的类（如CGLIB代理、热部署类）

2. 补全OOM异常细节 #

当前异常仅显示OutOfMemoryError，但不同子类的排查方向完全不同。修改全局未捕获异常处理器，打印完整异常栈：

Thread.setDefaultUncaughtExceptionHandler((thread, throwable) -> {
    // 替换为项目实际使用的日志框架
    log.error("Uncaught exception in thread: {}", thread.getName(), throwable);
});

重点区分OOM类型：

• Java heap space：堆内存不足，聚焦对象创建与释放逻辑
• Metaspace：类加载过多，检查动态代理、第三方依赖的自定义类加载器
• GC overhead limit exceeded：GC耗时超98%但回收内存不足2%，说明内存已接近饱和且对象无法释放

3. 针对性排查涉事线程 #

根据你给出的线程名称，逐个排查对应场景的内存风险：

• ClientThread：检查客户端连接（Socket/HTTP客户端）是否未正确关闭，比如RestTemplate、OkHttp是否复用连接池，是否有未释放的输入流资源
• pool-2-thread-1：若为自定义线程池，检查线程是否持有大对象（如请求上下文、批量数据集合）未释放；若为框架线程池，排查任务是否传递了超大对象
• http-nio-8080-Poller：调整Tomcat NIO参数（如server.tomcat.max-http-post-size限制请求体大小），检查文件上传是否未及时清理临时文件
• MaintenanceTimer-3-thread-1：检查定时任务是否每次执行都向静态集合新增对象，或数据库查询返回了超大结果集未做分页处理

4. 开启GC日志分析内存趋势 #

添加GC日志参数，持续监控内存变化规律：

-Xlog:gc*,gc+heap=info,gc+age=trace:file=/your/local/gc/path/gc.log:time,level,tags:filecount=5,filesize=100m

分析日志重点关注：

• 年轻代、老年代的内存增长曲线，是否存在持续上涨不回落的情况
• Full GC的触发频率，以及每次Full GC后老年代内存占用是否仍处于高位
• 大对象直接进入老年代的记录，判断是否存在一次性加载过多数据的场景

5. 检查ThreadLocal使用规范 #

ThreadLocal是内存泄漏高发点，尤其是线程池复用线程时：

• 确保所有ThreadLocal在任务结束后调用remove()方法
• 避免用静态ThreadLocal关联大对象（如用户上下文、批量业务数据）

6. 排查第三方依赖的内存泄漏 #

检查项目依赖是否存在已知的内存泄漏问题：

• 比如MyBatis一级缓存是否未配置过期时间，Redis客户端连接池是否未正确释放连接
• 查看依赖版本的发布说明，确认是否有内存泄漏相关的修复记录

内容的提问来源于stack exchange，提问作者Bipin Singh