项目上线没多久，服务器ref="/tag/27/" style="color:#8B0506;font-weight:bold;">内存占用一路飙升，重启后几分钟又回到高位。这种情况在用 Spring 框架开发的 Web 应用中并不少见，尤其是基于 Spring Boot 的微服务架构下，稍不注意就会埋下内存泄漏的隐患。
静态集合持有 Bean 引用
最常见的泄漏点之一是把 Spring 管理的 Bean 存进了静态容器。比如为了“提升性能”，有人会把一些 service 实例缓存到一个 static Map 里，结果这些 bean 永远不会被 GC 回收。
public class UserServiceCache {
private static Map<String, UserService> cache = new HashMap<>();
public static void addService(String key, UserService service) {
cache.put(key, service);
}
}上面这段代码一旦执行，UserService 对象就被静态 map 持有，即使容器重新刷新或销毁，这些对象依然驻留在老年代，久而久之就 OutOfMemoryError。
@EventListener 默认是单例监听
使用 @EventListener 注解时，默认情况下事件监听器是单例模式，如果监听方法所在的类被频繁创建（比如通过 new 实例化而非 Spring 管理），那么监听器会被重复注册，导致内存堆积。
@Component
public class OrderListener {
@EventListener
public void handleOrderEvent(OrderEvent event) {
System.out.println("处理订单: " + event.getOrderId());
}
}如果这个类没有被 Spring 托管，或者在非 Spring 上下文中多次加载，监听器实例就会不断累积。正确做法是确保该类由 Spring 容器管理，并避免手动 new。
未关闭资源的定时任务
用 @Scheduled 写定时任务很方便，但如果任务本身持有外部资源或引用了大对象，且没有及时释放，也会造成泄漏。特别是当任务抛异常未被捕获时，可能中断执行流但对象仍存活。
@Component
public class DataSyncTask {
@Scheduled(fixedRate = 5000)
public void sync() {
List<Record> records = loadLargeDataSet(); // 加载大量数据
process(records);
// 这里如果没有清空或置 null，可能影响 GC
}
}虽然 Java 有自动回收机制，但若局部变量被意外延长生命周期（如被线程局部变量 ThreadLocal 持有），问题就来了。
ThreadLocal 使用不当
有些开发者在拦截器或过滤器中用 ThreadLocal 存用户上下文信息，这本身没问题，但忘了在线程结束前调用 remove()，而在 Tomcat 这类使用线程池的容器中，线程会被复用，导致上一次请求的数据还挂在 ThreadLocal 上。
public class UserContextHolder {
private static final ThreadLocal<User> context = new ThreadLocal<>();
public static void setUser(User user) {
context.set(user);
}
public static void clear() {
context.remove(); // 必须手动清理
}
}记得在 Filter 的 finally 块中调用 clear()，否则每个线程都会缓慢积压对象。
第三方库注入的隐藏引用
集成某些 SDK 时，比如日志追踪、监控埋点工具，它们可能会偷偷把 Spring Bean 注册为回调监听。这类泄漏最难查，因为代码里看不到明显的问题。这时候得靠内存分析工具出手。
用 jmap 导出堆转储文件：
jmap -dump:format=b,file=heap.hprof <pid>然后用 Eclipse MAT 或 JVisualVM 打开，查看哪些类的实例数量异常多，重点关注 *HashMap$Entry*、*ArrayList*、*ThreadLocalMap* 这些常见容器。
在 MAT 中通过“Leak Suspects”报告，通常能一眼看出是谁持有了大量对象引用。再结合项目代码逆向追踪，就能定位到具体类。
避免泄漏的实用建议
别滥用 static 缓存 Spring Bean，真要缓存数据就用 Redis 或 Caffeine 这种可控的方案。尽量让所有组件由 Spring 统一管理生命周期，不要混用 new 和 @Autowired。对于定时任务，加上 try-catch 防止中断，关键变量处理完及时置 null。最重要的是，上线前做一轮压力测试，用 jstat 观察老年代增长趋势，早发现早解决。