问题：
我在我的一个项目中使用UIMA Ruta（v2.3.1），但现在我遇到了一个问题： 内存超出了可解释的大小，但除了类 org.apache.uima.ruta.rule.RuleElementMatch 之外，它无法找到问题所在的位置。 50％的内存使用量。
我在项目中调用了UIMA Ruta的JavaAPI来设置分析引擎。当我向该引擎发送大约400k字节大小的文本进行分析时，此过程会阻止大约700MB内存，但GC没有任何机会释放一些空间。
Ruta项目：
给定的Ruta规则是使用REGEXP结构构建的，但理论上它们应该减少内存使用量，因为在特定端点有UNMARKALL语句。
是否有人面临高内存消耗的相同情况或是否有任何建议的解决方案？由于响应时间已经在30秒左右，因此无法使用低内存配置文件作为uima本身的建议。增加JVM的最大内存不是一种选择。
答案 0 :(得分：0)
这可能不是一个答案，但这里有一些可能有帮助的评论。
正如名称所示，RutaRuleElementMatch存储规则元素的匹配，这是一个RuleMatch所必需的，以便识别操作的信息。在RuleMatch之后可以忘记这些信息，但有时需要存储它。主要是，如果分析引擎配置为进行调试（参数debug和debugWithMacthes），则会存储它。然后，记住所有规则匹配和规则元素匹配，以便稍后创建调试注释。如果有许多匹配，则在当前实现中可能会占用大量内存。
调试配置也用在Java API中，例如，在Ruta.select（）或Ruta.matches（）中。在较小的数量中，匹配也会被记住用于块语句的头规则。
因此，如果激活调试，则应停用它以减少内存使用量。
我认为400KB的文字非常多。 Ruta带来了相当多的开销，这是必需的，但也可以改进/减少。现在，在实现得到改进之前，有一些最佳实践可以处理ruta中的大型文档，即减少内存使用量。
在您的使用案例中，我会切换到另一个播种器，该播种器只会创建您需要的注释，并且只在您需要它的地方，例如，您是否需要SPACE和BREAK？然后，我会重构规则。您在注释中提到的示例规则效率极低，并产生许多RuleElementMatches。我建议尽可能使用字典查找，例如与TRIE。您还可以通过限制匹配条件来改进此类规则。在您的示例中，这可能是W或某些字典查找的输出。
如果分析显示RutaRuleElementMatch使用了大量内存，那么这可能是由调试配置或低效规则引起的。
如果分析显示RutaBasic使用了大量内存，那么它是由文档的大小引起的，因此也是由注释量引起的。减少注释量有助于减少覆盖信息需要存储在内部列表/数组中。 UNMARK和UNMARKALL也有帮助，但至少在我的使用案例中没有给人的期望。还有参数lowMemoryProfile，它可以减少RutaBasic的内存使用量，但也可以降低运行时性能。但是，我认为您的规则可以进行大量优化，以便参数再次成为一个选项。
我希望这会有所帮助。
免责声明：我是UIMA Ruta的开发者