我明白这种卡在内存溢出问题里的挫败感——尤其是已经试过常规调参还是没解决的情况。针对你遇到的SWTBot测试用例和Eclipse自身触发的java.lang.OutOfMemoryError: Java heap space问题，咱们可以从几个容易忽略的角度再排查下：

1. 确认堆配置的作用范围，别搞混全局与测试用例 #

你提到在运行配置和eclipse.ini里加了堆参数，但要注意两个配置的作用是完全分开的：

• 测试用例的堆配置：右键你的SWTBot测试→Run As→Run Configurations→找到对应的JUnit/SWTBot配置→切换到Arguments标签页，确认VM arguments里确实有-Xms768m -Xmx1024m（甚至可以临时调大到-Xmx2048m试试），而且参数格式正确（无多余符号，空格分隔或单独成行均可）。
• Eclipse自身的堆配置：eclipse.ini里的VM参数要单独占一行，而且如果你的JDK是Java 8及以上，PermGen已经被Metaspace取代，原来的-XX:PermSize=512m要换成-XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m，不然配置根本不会生效。正确示例：

  -Xms768m
  -Xmx1024m
  -XX:MetaspaceSize=512m
  -XX:MaxMetaspaceSize=512m
  

2. 排查SWTBot测试的内存泄漏（重点！） #

SWTBot测试非常容易因为UI资源没正确释放导致内存泄漏，这也是很多人调大堆内存后依然溢出的核心原因：

• 在每个测试方法的@After注解方法里，显式清理UI资源：比如调用对话框的close()、控件的dispose()方法，若是工作台级别的测试，试试bot.resetWorkbench()重置状态。
• 生成堆转储分析：在测试的VM参数里加-XX:+HeapDumpOnOutOfMemoryError，溢出时会自动生成java_pidXXX.hprof文件，用Eclipse自带的Memory Analyzer Tool（MAT）打开，找出占用内存最高的对象——如果是大量SWT控件或测试上下文对象没被回收，那就是泄漏无疑了。

3. 调整垃圾回收策略适配UI测试场景 #

默认的GC策略在频繁创建销毁UI对象的场景下效率不高，可以试试这些调优参数：

• 对于Java 8+，使用G1收集器：-XX:+UseG1GC，它更适合大堆内存和频繁对象创建的场景，能有效减少Full GC的频率。
• 开启GC日志排查：加-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，运行测试时查看控制台的GC日志，如果发现频繁触发Full GC且每次回收的内存极少，基本可以确定是内存泄漏问题。

4. 排除项目与插件的额外内存消耗 #

• 检查测试用例是否加载了不必要的大资源：比如测试时加载了超大的图片、文档，这些资源如果没及时释放，会快速占满堆内存。
• 试试干净的Eclipse环境：如果你的Eclipse安装了很多第三方插件，可能存在插件本身的内存泄漏。可以下载只带SWTBot必要插件的Eclipse版本，再运行测试，排除插件干扰。

5. 临时调大堆内存验证问题 #

如果以上方法都没头绪，先临时把堆内存调得更大，比如-Xms1024m -Xmx2048m：如果这样就不溢出了，说明当前堆内存确实不够用；如果还是溢出，那肯定是存在内存泄漏，得回到第二步仔细排查。

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