运行2400个测试用例的Karate特征文件CPU占满，拆分后正常，求问方案差异

核心差异原因 #

1. 测试上下文的生命周期管理 #

• 单个大特征文件运行时，Karate会为整个文件创建全局共享的测试上下文，包含所有场景的变量、HTTP客户端连接、请求/响应缓存、测试状态等数据。2400个测试用例持续向这个上下文写入数据，且在整个文件执行完成前不会主动销毁这些对象，导致内存持续累积。
• 拆分后的小特征文件，每个文件的上下文是独立的，执行完成后会立即销毁所有关联对象，JVM的垃圾回收（GC）可以快速回收这部分内存，CPU也会因为上下文清理而短暂回落。

2. 垃圾回收（GC）的效率差异 #

• 单个大文件中，大量测试对象被上下文引用，JVM无法及时判定这些对象为“无用”，导致堆内存快速耗尽，同时触发频繁的Full GC（Full GC会暂停所有线程并占用大量CPU资源）。即使调整pom.xml的最大堆内存，也只是延缓耗尽时间，无法解决“对象无法被回收”的核心问题。
• 小文件执行时，每个文件结束后上下文对象失去引用，GC可以高效回收内存，避免堆内存持续膨胀，也减少了GC的CPU开销。

3. 资源调度与负载模式 #

• 单个大文件运行时，无论串行还是并行执行，都会一次性加载所有测试用例的元数据到内存，线程池持续处于高负载状态，CPU被持续占用。
• 拆分后的小文件是独立的执行单元，每个文件执行完成后，线程会释放回池，系统资源有机会短暂恢复，CPU占用自然回落。

4. 测试报告的内存压力 #

• 单个大文件运行时，所有测试用例的执行结果、日志、断言数据会持续保存在内存中，直到整个文件执行完成才生成完整报告，2400个用例的报告数据量会进一步加剧堆内存压力。
• 小文件执行时，每个文件的报告数据会在执行完成后立即写入磁盘并释放内存，不会累积大量报告数据。

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