在Spring Boot中浅尝内存泄漏的实战记录

使用静态集合持有对象引用，阻止gc回收

关键点：

使用static list作为内存泄漏的锚点，其生命周期与classloader一致
每次请求向列表添加1mb字节数组，这些对象会持续占用堆内存
由于集合持有强引用，gc无法回收这些对象
最终会导致outofmemoryerror: java heap space

可执行代码：

package io.renren.controller;
import org.springframework.boot.springapplication;
import org.springframework.web.bind.annotation.getmapping;
import org.springframework.web.bind.annotation.restcontroller;
import org.springframework.web.client.resttemplate;
import java.util.arraylist;
import java.util.list;
/**
 * author: lj
 * date: 2025-4
 */
@restcontroller
public class memoryleakcontroller {
    // 静态集合会持续持有对象引用
    private static list leaking_list = new arraylist<>();
    // 内存泄漏端点
    @getmapping("/leak")
    public string leakmemory() {
        // 每次请求添加1mb数据（不会被释放）
        leaking_list.add(new byte[1024 * 1024]);
        return "已泄漏内存: " + leaking_list.size() + " mb";
    }
    // 触发oom的测试方法（快速验证）
    public static void main(string[] args) throws interruptedexception {
        springapplication.run(memoryleakcontroller.class, args);
        // 通过循环请求快速触发oom
        while(true) {
            new resttemplate().getforobject("http://localhost:8080/leak", string.class);
            thread.sleep(100);
        }
    }
}

验证：

1，运行程序（启动时添加jvm参数限制堆大小）：

//在cmd中先cd到jar包所在目录，执行如下命令启动
//-xmx100m 当程序需要更多内存时，jvm会尝试分配最多100mb的堆内存。如果超过这个限制，可能会抛出outofmemoryerror
//-xms100m jvm在启动时分配的最小内存量。如果初始堆内存设置得过低，程序可能在运行过程中频繁扩展堆内存，影响性能。
//-xx:+heapdumponoutofmemoryerror 在发生outofmemoryerror时生成堆转储（heap dump）的功能
java -jar -xmx100m -xms100m -xx:+heapdumponoutofmemoryerror -xx:heapdumppath=d:\temp renren-generator-1.0.0.jar

2，访问 http://localhost:8080/leak 触发泄漏

日志输出显示了内存泄漏位置。

并且在临时目录中保存了一份堆转储文件，稍后使用mat(memory analyzer tool)分析。

问题定位

使用jvisualvm工具定位问题

在cmd输入jvisualvm指令

选中应用后，可以监控应用程序的性能。

触发内存泄露后，查看每次gc的持续时间、回收的内存等信息。oom之后，点击界面右上角的堆dump，打开应用的堆转储信息。

查找最大对象

打开java.lang.object[]的保留堆

查看leaking_list的引用链，至此问题定位完成。

使用mat(memory analyzer tool)工具定位问题

下载地址：https://eclipse.dev/mat/download/previous/
我的是jdk8，所以我下载了memory analyzer 1.10.0 release版本。下载完成后，直接解压，运行其中的memoryanalyzer.exe文件即可启动mat工具。

用mat工具打开刚刚临时目录中保存的堆转储文件，点击leak suspects生成内存泄漏报表。

点击details查看java.lang.object[]的保留堆

查看leaking_list的引用链，至此问题定位完成。

调优建议

1，避免长时间持有大对象引用。
2，定期执行集合清理操作。

@scheduled(fixedrate = 60_000)
public void cleanleakingdata() {
    leaking_list.removeif(data -> /* 清理条件 */);
}

--------------------------------------------------更新---------------------------------------------------------

变种实现方式

@springbootapplication
@restcontroller
@enablecaching // 关键注解：启用缓存
public class cacheleakdemo {
    // 模拟缓存未正确清理
    @cacheable("leakycache")
    @getmapping("/cache-leak")
    public byte[] cacheleak() {
        return new byte[1024 * 1024]; // 每次缓存1mb
    }
    public static void main(string[] args) {
        springapplication.run(cacheleakdemo.class, args);
    }
}

缓存泄漏原理：
@cacheable会将每次不同参数的返回结果缓存

因为没有设置过期时间或大小限制，缓存会无限增长

示例中每个请求生成唯一key（默认基于方法参数），导致缓存不断累积

调优建议

对于缓存使用weakreference或框架（caffeine/ehcache）

// 使用weakhashmap解决
private static map safe_map = 
    collections.synchronizedmap(new weakhashmap<>());

// 使用caffeine缓存并设置上限
@bean
public cachemanager cachemanager() {
    caffeinecachemanager manager = new caffeinecachemanager();
    manager.setcaffeine(caffeine.newbuilder()
            .maximumsize(100)
            .expireafterwrite(10, timeunit.minutes));
    return manager;
}

因为在 java 中，weakhashmap 的设计目的就是通过弱引用（weak reference）自动清理不再被使用的键值对，从而避免因对象残留导致的内存泄漏。

引用类型对比表：

关键机制：
weakhashmap 的 键（key）使用弱引用存储
当键对象不再被其他强引用持有时，该键值对会被自动移除
值对象（value）仍使用强引用，需要特别注意解耦

内存泄漏场景 vs weakhashmap修复方案

//使用普通hashmap导致泄漏
public class leakingcache {
    private static map cache = new hashmap<>();
    // 添加大对象到缓存
    public static void addtocache(byte[] key, string value) {
        cache.put(key, value);
    }
    public static void main(string[] args) {
        // 模拟添加后不再使用key
        byte[] key = new byte[1024 * 1024]; // 1mb
        addtocache(key, "大数据");
        key = null; // 删除强引用
        // 触发gc
        system.gc();
        // 缓存仍然持有key的强引用，导致1mb内存无法回收
        system.out.println("缓存大小: " + cache.size()); // 输出1
    }
}

//使用weakhashmap
public class safecache {
    // 使用weakhashmap + 同步包装（线程安全）
    private static map safe_cache = 
        collections.synchronizedmap(new weakhashmap<>());
    public static void addtocache(byte[] key, string value) {
        safe_cache.put(key, value);
    }
    public static void main(string[] args) {
        byte[] key = new byte[1024 * 1024];
        addtocache(key, "安全数据");
        key = null; // 删除最后一个强引用
        // 强制gc（生产环境不要主动调用system.gc()）
        system.gc();
        // 给gc一点时间执行
        try { thread.sleep(1000); } catch (interruptedexception e) {}
        system.out.println("缓存大小: " + safe_cache.size()); // 输出0
    }
}

实战应用

场景：设备连接会话管理

@restcontroller
public class devicecontroller {
    // 使用weakhashmap管理临时会话
    private static map devicesessions = 
        collections.synchronizedmap(new weakhashmap<>());
    @postmapping("/connect")
    public string connect(@requestbody device device) {
        session session = new session(device);
        devicesessions.put(device, session);
        return "connected";
    }
    // 当device对象不再被外部引用时，自动清理会话
}

配置验证端点

@getmapping("/session-count")
public int getsessioncount() {
    return devicesessions.size();
}

测试方法

1，发送连接请求
curl -x post http://localhost:8080/connect -d '{"id":"device1"}'
2，立即调用/session-count查看数量
3，停止持有device对象引用后触发gc
4，再次检查会话数量

增强版缓存实现（带自动清理）

public class advancedcache {
    private final map cache = 
        new weakhashmap<>();
    private final referencequeue queue = 
        new referencequeue<>();
    public void put(k key, v value) {
        // 清理已回收的条目
        processqueue();
        cache.put(key, value);
    }
    private void processqueue() {
        reference ref;
        while ((ref = queue.poll()) != null) {
            // 这里可以触发回调清理相关资源
            system.out.println("清理条目: " + ref);
        }
    }
}

代码测试片段

// 测试插入100万条数据
intstream.range(0, 1_000_000).foreach(i -> {
    object key = new object();
    map.put(key, "value-" + i);
});
// 强制gc后统计剩余条目
system.gc();
thread.sleep(1000);
system.out.println("剩余条目: " + map.size());

测试结果：

场景：设备状态临时缓存

public class devicestatemanager {
    // key: 设备对象，value: 最后上报时间
    private final weakhashmap lastreporttime = 
        new weakhashmap<>();
    // 更新状态
    public void updatestate(device device) {
        lastreporttime.put(device, system.currenttimemillis());
    }
    // 获取在线设备列表（需配合referencequeue清理）
    public list getonlinedevices() {
        return new arraylist<>(lastreporttime.keyset());
    }
}

优势分析：
当设备断开连接且不再被其他模块引用时，自动清理状态
避免因设备频繁上下线导致的内存增长
适合作为二级缓存，配合持久化存储使用

综上：
weakhashmap 是解决特定类型内存泄漏的有效工具，但需要充分理解其工作原理和适用场景。在实际物联网系统中，通常需要结合软引用、引用队列等机制构建更健壮的缓存系统。

----------------------------------------------基础信息补充--------------------------------------------------------
除了上方方法，也能通过jdk自带的工具jmap，jconsole来获得一个堆转储文件。

jvm（java虚拟机）管理的内存大致包括三种不同类型的内存区域：

permanentgeneration space（永久保存区域）、heap space(堆区域)、javastacks(java栈）。
1，其中永久保存区域主要存放class（类）和meta的信息，class第一次被load的时候被放入permgenspace区域，class需要存储的内容主要包括方法和静态属性。
2，堆区域用来存放class的实例（即对象），对象需要存储的内容主要是非静态属性。每次用new创建一个对象实例后，对象实例存储在堆区域中，这部分空间也被jvm的垃圾回收机制管理。
3，而java栈跟大多数编程语言包括汇编语言的栈功能相似，主要基本类型变量以及方法的输入输出参数。java程序的每个线程中都有一个独立的堆栈。
容易发生内存溢出问题的内存空间包括：permanentgeneration space和heap space。

第一种outofmemoryerror：permgenspace

发生这种问题的原意是程序中使用了大量的jar或class，使java虚拟机装载类的空间不够，与permanentgeneration space有关。解决这类问题有以下两种办法：

1、增加java虚拟机中的xx:permsize和xx:maxpermsize参数的大小，其中xx:permsize是初始永久保存区域大小，xx:maxpermsize是最大永久保存区域大小。如针对tomcat，在catalina.sh或catalina.bat文件中一系列环境变量名说明结束处（大约在70行左右） 增加一行：

java_opts=" -xx:permsize=64m -xx:maxpermsize=128m"

第二种outofmemoryerror：java heap space

发生这种问题的原因是java虚拟机创建的对象太多，在进行垃圾回收之间，虚拟机分配的到堆内存空间已经用满了，与heapspace有关。解决这类问题有两种思路：

1、检查程序，看是否有死循环或不必要地重复创建大量对象。找到原因后，修改程序和算法。

2、增加java虚拟机中xms（初始堆大小）和xmx（最大堆大小）参数的大小。如：set java_opts= -xms256m-xmx1024m

第三种outofmemoryerror：unable to create new nativethread

这种错误在java线程个数很多的情况下容易发生

gc

垃圾收集（gc）是java内存管理的重要机制之一。它负责自动回收不再使用的对象所占用的内存，以避免内存泄漏和oom问题的发生。
gc的工作原理主要涉及到两个关键概念：标记-清除（mark-sweep）和分代收集（generational）。标记-清除算法会遍历整个堆空间，标记出仍然被引用的对象，然后清除未被标记的对象所占用的内存。分代收集则是将堆空间划分为新生代和老年代两个区域，根据对象的存活周期采用不同的回收策略。

到此这篇关于在spring boot中浅尝内存泄漏的实战记录的文章就介绍到这了,更多相关spring boot内存泄漏内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！