2017-08-11 49 views
-1

我在使用遞歸函數時遇到java.lang.StackOverflowError。如何通過java代碼中的更改來解決StackOverflowError

其實在遞歸函數xml文件已被解析,如果在xml文件中存在以前的xml提要url,則該xml再次傳遞給相同的函數,並再次在此xml文件中存在之前的xml提要url,然後再次傳遞給相同的函數。

該過程一直持續到它獲得之前的xml供稿網址。我沒有得到10,000個文件的錯誤,但在此之後,當第101001個文件再次發生相同的函數調用時,我得到java.lang.StackOverflowError。我想通過編碼的改變來解決這個錯誤,而不是增加內存,試圖像這樣遞歸調用固定批量大小來實現解決方案。

請讓我知道如果你能爲我提供更好的解決方案StackOverflowError。如果您實施此類解決方案,則需要部分解決方案代碼。

問候, Shobhit

+0

您是否在執行此遞歸調用時保持所有Streams打開?從我讀到的內容來看,聽起來好像您可以隨時關閉當前流,因爲您已遍歷到找到的文件。 – Nico

+0

當你進行過多的嵌套方法調用時,引起堆棧溢出(通常我相信),並且在遞歸代碼中是典型的。因此清楚你的遞歸。確保你有一個終止的基本情況。 – Adeel

+0

閱讀此http://www.javaworld.com/article/2072881/diagnosing-and-resolving-stackoverflowerror.html鏈接 –

回答

0

現在,我通過使用try/catch塊來解決問題。我捕獲StackOverflowError並將最後處理的文件存儲在內存中。然後,我再次調用該方法並從發生StackOverflowError的文件開始。

更新: 現在,我已經爲StackOverFlowError實現了更好的解決方案。我正在運行一批可配置大小的進程。例如,流程將以批量爲100的尺寸進行處理,如果需要進一步處理,則將在下一批中處理。

1

總的答案你的代碼的描述有點含糊:當你需要比分配更多的堆棧

的StackOverflowError發生 - 這是微不足道的。在一堆嵌套方法調用中,無論它們是遞歸的還是不是,每個方法調用都需要一定數量的堆棧,由方法中的參數數量和局部變量決定。因此,爲了減少堆棧需求,您可以減少嵌套方法調用或減少方法中的參數和局部變量。兩者都需要重新設計您的軟件。

特別危險的是遞歸調用。如果不能預先知道多少嵌套的遞歸調用最多會發生,獲取StackOverflowError的風險非常高。

您的描述聽起來有點像深度優先搜索(由遞歸實現)在由url和鏈接組成的圖中。如果您可以將其更改爲廣度優先搜索(通常通過迭代實現),那麼再沒有理由再使用StackOverflow。當然,這兩個搜索都需要一個終止條件,所以你不會永遠陷入一個循環。

相關問題