4

だから私はかなりピクルスにいます。最初に DFS アルゴリズムを作成したとき、再帰を使用しました。これにより、StackOverflow エラーが発生しました。まあ...大したことはありません。それを反復に変換します。そこで、コードを反復に変換し、Stack を使用してメソッド呼び出しを複製しました。ただし、今は OutOfMemoryError が発生しています。

私は実際に私の問題を発見しました.循環依存関係がありました. (愚かな私)しかし、循環依存関係がなければ、他の誰かがこれにどのようにアプローチしたか興味があります。また、これはJavaで行われたことにも言及する必要があります。

私の質問は、無限ループがないことがわかっているが、DFS 検索からのスタックが原因で OutOfMemoryError が発生した場合にどうするかということです。

4

3 に答える 3

3

スタック オーバーフローとメモリ不足エラーの一般的な原因は、プログラムが O(n) ストレージ (またはそれ以上) を必要とするアルゴリズムを使用していることです。最適なアクションは、O(n) のように、より少ないストレージを使用するアルゴリズムまたはトリックを見つけることです。 (1) または O(log n)。最も一般的な例は、O(n) である最初に完全にメモリに読み込むのではなく、一定サイズのブロック、つまり O(1) ストレージで大きなファイルを処理することです。

これらのエラーのもう 1 つの一般的な原因は単純なミスです。不要になったガベージを蓄積したり、アルゴリズムが存在するオブジェクトを再利用する必要があるときに新しいオブジェクトを作成したりします。この場合も、適切な解決策はバグを見つけて修正することです。

-Xssアルゴリズムが合理的にできる限りメモリを保守的であり、メモリのバグがないことが確実な場合にのみ、JVM メモリ パラメータ (スタック サイズ-Xms-Xmx設定し、初期ヒープ サイズと最大ヒープ サイズを設定する) を操作するのが理にかなっています)。

于 2013-07-18T22:15:15.883 に答える
1

ほとんどの場合、メモリ関連の例外が発生した場合、最初にすべきことは、自分が何をしているのかについて長く真剣に考えることです (おそらくメモリ プロファイラーの助けを借りて)。不要になったデータを保持している可能性が非常に高くなります。

そうは言っても、プログラムが効率的に動作していて、問題の原因が単純にデータ セットのサイズや複雑さにある場合は、アプリケーションで使用されるスタックまたはヒープを増やすことができます。

-Xss64m

スタック サイズを 64 MB に設定します

-Xmx1024m

ヒープ サイズを 1 ギガに設定します。

于 2013-07-18T22:17:58.777 に答える
1

stackOverflow は、再帰アルゴリズムを使用していたため、まさにその意味を意味します。これは、(関数呼び出しの) メモリ スタックがオーバーフローしたことを意味します。コール スタック ドキュメントを見て、スタック ポインター、フレーム、およびリターン ポインターがどのように機能するかを理解してください:コール スタック

反復アルゴリズムを作成すると、格納している変数がコール スタック上になく、関数自体のメモリに (同じスタック フレーム内に) 格納されるため、メモリが不足します。

もちろん、技術的にはどちらのエラーもメモリが残っていないことを意味しますが、それぞれが異なる方法で発生しました。1 つはメソッドへの終了しない再帰呼び出しによるもので、もう 1 つはメモリのオーバーフローによるものです。

編集 編集された質問に関しては、システムに十分なメモリがない限り、無限ループや再帰なしでstackOverflowが発生することはないと思います。多分RAMを追加しますか?

于 2013-07-18T21:57:30.550 に答える