2

サンによると：

Error は Throwable のサブクラスであり、適切なアプリケーションがキャッチしようと すべきではない重大な問題を示します。

キャッチされる可能性のあるエラーがあり、アプリケーションが続行される可能性があるため、この推奨事項には同意しません (ライブをスローしたErrorスレッドを放置するという意味ではありません。そのスレッドはデッドのままです。残りのアプリケーションは存続します)。このようなエラーは OutOfMemory です。
これを正しいと考えてください (ここで私が間違っていると思われる場合は、引数をここに記載してください) アプリケーション内に何らかの監視コードを実装しようとしているかどうか疑問に思っていました。
具体的な例を挙げると、既存のアプリケーション内に、ログからさまざまなエラーを検出し (例は OOM など)、状況が悪化した場合に JVM を再起動できるように何らかのヘルス統計を作成する小さなクラスを配置することを考えています。
たとえば、検出された OutOfMemoryError が多すぎる場合は、JVM を再起動します。また、多すぎると、ある種のしきい値になる可能性があります。正直なところ、このしきい値をどのように計算するのかわかりません。おそらく、他のエラーと似たようなものです。
私はそのようなメカニズムが有用であると思っていましたか？同様のことをしたことがありますか？はいの場合、アドバイスやサンプルコードはありますか? それとも、私は間違った道を進んでいて、これを別の方法で考えるべきですか?

4

2 に答える 2

2

通常、OutOfMemoryを押すと、かなり困惑します。JVM（メモリからは少し不正確になる可能性があります）は、完全なGCが実行され、十分なメモリを解放できなくなるまで、これをスローしません。

私があなたが探しているものに最も近いと思うのは、 -XX：printGCと-XX：printGCdetailsを使用してGCアクティビティを出力し、外部スクリプトからリセットをトリガーすることです。

ただし、アプリケーションで定期的にメモリが不足している場合は、修正する必要のある問題を示している可能性があります。

于 2012-08-04T19:05:44.323 に答える
0

これは便利かもしれませんが、私自身は使ったことがありません。私がやろうとしていることの 1 つは、クライアントの要求に応じてメモリを割り当てることを避けることです。

HTTP のチャンク エンコーディング用のプロセッサのようなものを考えてみてください。各チャンクには長さがプレフィックスとして付けられます。その長さのバッファーを割り当ててから、データをそこに読み込むことができます。これは、高速で簡単なため、実際にほとんどのサーバーで行われていることです。

しかしByteArrayOutputStream、必要に応じて成長できる のようなものを使用することを好みます。解析を開始するとき、入力ストリームを長さ制限デコレータでラップします。このデコレータは、読み取ったデータの合計量が過度に大きい場合に例外をスローします。

制限は、アプリケーションに対して構成可能です。たとえば、フォームを処理している場合、入力を数キロバイトに制限することがあります。画像のアップロードをサポートしている場合、おそらく数メガバイトです。しかし、ジョーカーが数ギガバイトのチャンクを送信していると主張する場合、サーバーがやみくもにバッファを割り当てようとするのは望ましくありません。

于 2012-08-07T14:01:46.573 に答える