远程提取Heap Dump避免预执行GC及Tomcat内存异常排查求助

由于VisualVM默认触发Full GC后生成Heap Dump，且你无法在VisualVM中修改live参数，结合服务器未安装JDK的情况，推荐以下两种方案：

方案1：使用jmap（需匹配JVM版本） #

• 找到与远程服务器Tomcat所用JVM版本完全一致的JDK，将其中的jmap二进制文件上传至服务器临时目录（如/tmp）
• 给jmap添加执行权限：

  chmod +x /tmp/jmap
  

• 通过SSH执行全堆dump命令（不加live参数，不会触发Full GC）：

  /tmp/jmap -dump:format=b,file=/tmp/full_heap.hprof <你的Tomcat进程PID>
  

• 用SCP将生成的full_heap.hprof下载到本地，使用VisualVM或MAT工具分析

方案2：使用Arthas（轻量级，无需JDK） #

Arthas是轻量级Java诊断工具，仅依赖JRE即可运行：

• 下载Arthas到服务器：

  curl -O https://arthas.aliyun.com/arthas-boot.jar
  

• 启动Arthas并选择Tomcat进程：

  java -jar arthas-boot.jar
  

• 执行全堆dump命令（默认不触发Full GC）：

  heapdump /tmp/full_heap.hprof
  

• 下载dump文件到本地分析

从Full GC后内存能回到初始1GB的情况来看，大概率不是传统意义上的内存泄漏（内存泄漏的特征是Full GC后内存无法回落至基线），更可能是临时大对象占用、GC参数不合理或缓存策略问题，建议按以下步骤排查：

• 收集并分析GC日志：给Tomcat添加GC日志参数，记录GC的频率、回收量、停顿时间等信息：

  # 在Tomcat的启动脚本中添加
  -Xloggc:/tmp/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution
  

  通过日志判断是否存在频繁Full GC、年轻代空间不足导致对象过早进入老年代等问题。

• 定位临时大对象：在内存占用峰值时，用Arthas的heapdump生成全堆快照，分析其中占用内存最高的对象类型，重点排查：

  • 批量数据查询/导出操作：是否存在一次性加载上万条数据未分页的情况
  • 大对象生成：如超大字符串、集合、字节数组等未及时释放
  • 文件流/IO资源：是否有读取大文件到内存后未关闭流的情况

• 检查线程与CPU占用：用Arthas的thread命令查看CPU占比最高的线程，确认是GC线程（说明GC压力大）还是业务线程（说明有耗时业务操作）：

  # 查看CPU top 5的线程
  thread -n 5
  

• 优化GC参数：如果GC日志显示年轻代过小、老年代回收效率低，可调整JVM参数：

  • 增大年轻代：-Xmn400m（根据服务器总内存调整，一般占堆内存的1/3-1/2）
  • 选择合适的GC收集器：如G1（适合大堆内存场景），添加参数-XX:+UseG1GC

• 检查缓存策略：排查本地缓存（如Guava Cache、Caffeine）是否设置了合理的过期时间和容量上限，避免缓存对象堆积占用内存；同时确认分布式缓存（如Redis）是否正常，防止缓存击穿导致大量请求生成临时对象。

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