3

出力ストリームを閉じるのではなく null にした場合の結果を知りたいです。out=null を実行すると、リソース リークが発生しますか?

4

4 に答える 4

4

いつもcloseあなたのストリーム。

Stream通常の java のようにヒープ上の通常のオブジェクトであるだけでなく、object書き込み用の基になるオペレーティング システムを処理します。

その後、フラッシュは発生しません。参照を作成すると、null

close のドキュメントを参照してください

この出力ストリームをフラッシュし、バッファリングされた出力バイトを強制的に書き出します。フラッシュの一般的な契約は、それを呼び出すことは、以前に書き込まれたバイトが出力ストリームの実装によってバッファリングされた場合、そのようなバイトを意図した宛先にすぐに書き込む必要があることを示しているということです。

では、上記の手順はどうreferenceですかnull？

あなたの質問はjdk7から発生しません

java7 、つまりtry-with-resources ステートメントを使用している場合は、ストリームを明示的に閉じる必要はありません。

于 2013-10-08T14:07:34.160 に答える
3

もしそうならoutputStream = null、これはリソースリークを引き起こしますか?

おそらくそうですが、ストリームが（最終的に）何に接続されているかによって異なります。

もう一つの問題は、それが重要かどうかです。それも依存します...

  • nullストリームの出力パイプラインにバッファが含まれている場合、閉じるのではなく割り当てると、バッファされたデータが失われる可能性があります。

  • これを繰り返し行うと、リークしたリソースが蓄積され、最終的に「ファイル記述子」が不足してアプリケーションが失敗する可能性があります。

  • 一方、リソースのリークが遅い場合は、「ファイル記述子」が不足する前に、ストリームがガベージ コレクションされてファイナライズされる可能性があります。(finalize()メソッド呼び出しclose()...)

しかし、どちらの方法でも、 ...を呼び出して、 「try / finally」または「try with resources」を使用して、常にクローズが行われるようにすることがベスト プラクティスです。呼び出す代わりに割り当てることは、トラブルを求めています。close()nullclose()

于 2013-10-08T14:11:30.583 に答える
0

jsut で参照を設定してnullも、基になるファイル ハンドルは解放されません。これは、これを行うためにガベージ コレクターとファイナライズに依存していることを意味します。ファイナライズが追いつかない場合、OS がファイル ハンドルを使い果たすため、実行時エラーが発生する可能性が非常に高くなります。また、ストリームに書き込んだ内容がいつディスクに出力されるかは定かではありません。

于 2013-10-08T14:10:09.657 に答える
0

outputStream の実装を知らなければ、質問に答えることは困難です。ただし、変数を null に設定する場合、変数が最初に指していたオブジェクトを削除するわけではないことに注意してください。何かを null に設定することは、C++ で delete を呼び出したり、Objective-C で release を呼び出したりすることと同等ではありません。自動的に呼び出されるクリーンアップ コードはありません。それこそが、そもそも close() が存在する理由です。存在するので、それが言うことを正確に行うために使用されると想定できます-リソースのクリーンアップ。

要するに、答えは「はい」です。リソースがリークする可能性があります。クリーンアップのために呼び出されるはずだったメソッドを呼び出してください!

于 2013-10-08T14:08:29.500 に答える