我使用UIMA魯塔（V2.3.1）在我的項目之一，但我現在面臨一個問題： 的內存超出可解釋大小，但無法解決此問題所在的位置，除類別org.apache.uima.ruta.rule.RuleElementMatch外，該內存佔用率高達50％。
我打電話UIMA魯塔的的JavaAPI在我的項目，建立分析引擎。當我發送一個文本以大約400k字節的大小分析到這個引擎時，這個過程會阻塞大約700MB的內存，但GC沒有機會釋放一些空間。
魯塔項目：
給出的魯塔規則是內置了REGEXP結構，但理論上他們應該減少內存使用量，因爲有在特定端點UNMARKALL的陳述。
是否有人面臨高內存消耗的相同情況或者是否有任何建議的解決方案？使用低內存配置文件作爲uima本身的建議是不可能的，因爲響應時間已經在30秒左右。增加JVM的最大內存不是一種選擇。
這可能不是一個答案，但這裏有一些評論可能有幫助。
正如其名說，RutaRuleElementMatch商店規則元素，這是需要一個wihtin在RuleMatch以便確定行動的信息的匹配。在RuleMatch之後可以忘記這些信息，但有時需要存儲它。主要是，如果分析引擎配置爲調試（參數debug和debugWithMacthes），則會將其存儲。然後，爲了稍後創建調試註釋，將記住所有規則匹配和規則元素匹配。如果有很多匹配項，這可能會在當前實現中佔用大量內存。
調試配置也使用的Java API，例如，在Ruta.select（）或Ruta.matches（）英寸數量較少的情況下，這些匹配也會被記憶爲區塊報表的主要規則。
所以，如果調試被激活，應以減少內存使用停用。
400KB的文字相當多，我想。魯塔帶來了相當多的開銷，這是必需的，但也可以改進/減少。現在，直到實現得到改進，爲了處理ruta中的大型文檔，即減少內存使用量，有一些最佳實踐。
在您的使用情況下，我會切換到不同的播種機它創建只需要批註，並且只在您需要的，例如，你需要的空間和休息時間嗎？然後，我會重構規則。您在註釋中提到的示例規則效率極低，並生成許多RuleElementMatches。我建議儘可能使用字典查找，例如與TRIE。您還可以通過限制匹配條件來改進此類規則。在你的例子中，這可能是W或某些字典查找的輸出。
如果分析表明，大量的內存是由使用RutaRuleElementMatch，那麼這可以由調試配置引起的，或由低效的規則。
如果分析表明，大量的內存是由使用RutaBasic，那麼它是由文檔的大小引起的，並因此由註解的量。由於較少的覆蓋率信息需要存儲在內部列表/陣列中，因此減少註釋量有所幫助。至少在我的使用案例中，UNMARK和UNMARKALL也有幫助，但沒有達到預期的效果。還有參數lowMemoryProfile，它可以減少RutaBasic的內存使用情況，但也會降低運行時性能，如您所述。不過，我想你的規則可以進行很多優化，以便參數再次成爲選項。
我希望這會有所幫助。
免責聲明：我是UIMA魯塔開發商
感謝您的回答，我們正在尋找，我們如何將這些提示轉化爲out ruta-project中的更改。實際上，我們在堆轉儲中正面臨着許多數組ArrayList，我們轉換了一些效率低下的規則，但它仍然有600米左右的存儲高峯，所以我們正在尋找另一種解決方案。一個明顯的例子是我們創建的票證，但並不是唯一一個生成大的空陣列的地方。 的CASImpl類生成一些堆用固體尺寸，所以這是改善記憶性能的另一個點 –
可以當然也分割的文件和處理部件分開/順序。但是你可能知道這一點，而這往往不是一種選擇。 –
減少RutaBasic預告的數量對您來說可能是一個不錯的選擇。你真的需要TokenSeed註釋嗎？ –
你使用哪種Java API中的一部分？ –
你是什麼意思的REGEXP結構？ REGEXP條件或簡單的正則表達式規則？ UNAMRKALL行動有哪些規則？端點是什麼意思？ –
我應該如何理解JavaAPI的問題？我們按照該API的文檔中所述構建AnalysisEngine，添加所需的所有類型系統，並使用流程方法推送文本以針對此引擎進行分析。 REGEX-Structures在我們組合規則的條件部分，就像下面的例子： **（ANY {REGEXP（「（H | h）ello」）} ANY {REGEXP（「（Mr. | Mrs 。）「）}）{NOT（IS（問候語）） - > MARK（問候語）} ** –