使用Eclipse MAT分析Jenkins：Hudson对象高内存占用问题咨询

结合我多年用MAT分析Jenkins内存问题的经验，给你拆解这两个问题：

绝对不是，这里你误解了**保留大小（Retained Size）**的定义，不能用保留大小除以浅大小来计算对象数量。

• 浅大小（Shallow Size）：就是单个Hudson对象本身占用的内存（312字节），只包含对象自身的字段，不包括它引用的其他对象。
• 保留大小：是当这个Hudson实例被GC回收时，能释放的总内存量——它包含Hudson对象本身，加上所有只能通过这个Hudson实例才能访问到的对象的总大小。

Jenkins本身是单例架构，通常整个系统只有一个Hudson核心实例，这个2GB的内存是它持有的所有子对象堆出来的：比如所有Job实例、构建历史记录、插件缓存、线程池、任务上下文等等，不是几十万相同的Hudson对象。

一、定位不必要的内存引用 #

1. 用MAT的支配树深挖引用链
   • 在MAT中打开「Dominator Tree」，找到这个Hudson实例，逐层展开它的子节点，重点关注占用内存Top N的对象：
     • 看jobs集合：是否堆积了大量已归档/废弃的Job实例；
     • 检查builds相关缓存：比如BuildHistory里是否保留了过多历史构建，或者某几个Job的构建日志、工件占用了大量内存；
     • 排查插件相关对象：有些第三方插件会在Hudson实例里缓存数据（比如报表、SCM拉取的代码缓存），检查是否有插件对象异常膨胀；
     • 查看线程池/执行器：是否有未关闭的线程持有任务上下文（比如流水线的临时变量、第三方服务客户端），导致对象无法被GC回收。
2. 对比基准快照找差异
   • 先在Jenkins刚启动、完成少量任务后拍一个内存快照，和现在的大内存快照对比，看哪些对象的数量或大小出现了异常增长——这些大概率就是泄漏点。
3. 检查Jenkins配置与插件行为
   • 查看全局配置：是否开启了过多的全局缓存（比如SCM缓存、构建结果缓存），或者缓存上限设置得过高；
   • 排查新增插件：如果是最近加了插件后出现的问题，优先检查该插件的内存使用情况，小众或自定义插件更容易出泄漏问题。

二、释放内存的可行方法 #

1. 针对性清理Jenkins数据
   • 清理废弃资源：在Jenkins界面删除不再需要的Job，给保留的Job设置构建历史保留策略（比如每个Job只保留最近10次构建）；
   • 清理插件缓存：很多插件自带清理缓存的功能（比如Git插件的拉取缓存、报表插件的临时数据），去插件配置页操作即可；
   • 清理工作目录：Jenkins的workspace和builds目录如果堆积过多文件，对应的文件句柄、路径对象也会被Hudson持有，手动清理或用「Workspace Cleanup」插件自动清理。
2. 调整JVM与Jenkins配置
   • 优化GC参数：改用G1GC（-XX:+UseG1GC），配置合理的堆内存大小（比如-Xmx4g -Xms4g，根据服务器资源调整），避免堆内存不足导致对象无法回收；
   • 开启软引用缓存：Jenkins部分模块支持用软引用缓存对象，当内存不足时自动释放，检查全局配置是否开启了相关选项；
   • 关闭不必要的全局功能：比如不需要的全局统计、监控功能，减少不必要的内存占用。
3. 修复泄漏根源
   • 如果定位到是某个插件导致的泄漏，优先升级到该插件的最新版本（官方通常会修复已知的内存泄漏问题），或者暂时禁用该插件；
   • 如果是自定义流水线/任务代码导致的，检查是否有静态变量、单例持有任务对象的情况，修改代码释放不必要的引用。
4. 临时应急方案：重启Jenkins
   • 如果需要快速释放内存，重启Jenkins可以一次性清除堆内所有对象，但这只是临时缓解，一定要找到泄漏的根源才能彻底解决问题。

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