burpsuite的内存不足
去年冬天做渗透测试，内存Burp Suite 毫无征兆地弹了个 OutOfMemoryError，不足整个窗口直接白屏。内存当时正在跑 Intruder 对登录接口做字典爆破，不足payload 列表刚加载到第 8000 条。内存那台测试机 16GB 内存，不足Burp 的内存堆上限默认才 1GB 左右，根本扛不住这种量级的不足并发请求。
这不是内存个例。Burp 基于 Java 运行，不足JVM 的内存堆内存分配在启动时就固定了。默认配置下，不足它给 Java 堆的内存初始值通常只有物理内存的 1/64，最大值 1/4。不足听起来好像够用？内存问题是 Burp 同时要维护 Proxy history、Scanner 的请求队列、Intruder 的 payload 生成结果、Repeater 的会话缓存，这些数据全部驻留内存。一旦你开了多个标签页，每个标签页又挂着几百条请求记录，堆空间消耗速度快得离谱。
内存到底被什么吃掉了
Proxy history 是最大的隐形杀手。很多人习惯挂着代理就不管了，浏览器随便刷刷，几小时下来历史记录轻松过万条。每条记录不只是 URL 和响应体，还包括完整的请求头、Cookie、时间戳、MIME 类型等元数据。我实测过，一万条中等复杂度的 HTTP 记录大约占用 300-500MB 堆内存。如果你还开了“自动保存响应体”选项，那些图片、JS 文件的二进制内容也全在内存里躺着。
Scanner 更夸张。主动扫描一个稍微复杂点的目标，Burp 会生成大量变体请求，每个请求的响应都要缓存用于对比分析。有次我扫一个带 REST API 的后台，跑了二十分钟，内存监控显示堆使用量从 400MB 飙到 2.3GB。最后 Burp 直接卡死，只能杀进程。
几个实际管用的调整
最直接的办法是改 JVM 启动参数。找到 Burp 的启动脚本（Windows 下是 BurpSuitePro.vmoptions 文件，Linux/Mac 在安装目录里），加上 -Xmx4g 或者更大。但别超过物理内存的 70%，否则系统本身会开始换页，反而更慢。我一般设成物理内存的一半，16GB 的机器给 8GB 堆，留足余量。
然后去 Proxy 设置里把 history 限制打开。Options → Proxy → History 里有个“Limit history size”选项，设成 2000 条左右。超过就自动丢弃最旧的记录。别心疼，那些三天前的请求记录你根本不会回头看。同时把“Save response bodies”关掉，需要的时候再手动保存单条。
Intruder 的 payload 处理也得注意。如果字典超过五万条，别一次性全加载。用“Pitchfork”模式分批跑，或者干脆把字典拆成多个小文件。我有次跑 10 万条密码字典，Burp 在生成 payload 列表阶段就 OOM 了，后来改成每次 5000 条，分 20 批跑，虽然麻烦点但至少不崩。
一些零碎的观察
Burp 的内存回收机制其实不算差，但架不住它什么都往堆里塞。有个细节：当你关闭一个 Repeater 标签页时，那个标签页的请求历史并不会立即被 GC 回收，要等下一次 Full GC 才清理。所以如果你频繁开关标签页，内存曲线会呈现锯齿状上升——每次关闭只降一点点，但打开新标签又涨一大截。
还有扩展的问题。很多人装一堆 BApp Store 里的插件，每个插件都可能持有自己的缓存。有次我装了个自动解码的插件，它把每个响应的 body 都复制一份做分析，内存占用直接翻倍。后来只留了三个必需的，世界清净了。
最后说个偏方：如果实在不想改启动参数，可以试试在 Burp 里定期手动触发 GC。Project options → Misc → 有个“Run garbage collection”按钮。虽然治标不治本，但至少能让你撑到保存完当前进度再重启。
说到底，Burp 的内存问题本质上是“便利性”和“资源消耗”的权衡。它默认把所有东西都留在内存里，是为了让你随时能回溯、对比、重放。但作为使用者，你得主动告诉它：哪些东西可以丢，哪些值得留。否则它就会像个不懂节制的仓库管理员，把什么都往货架上堆，直到货架塌掉。