0

そこでFile、Ruby のクラスについて調べていました。File掘り下げていたときに、 が のサブクラスであることを知りましたIO。私の理解では、IOオブジェクト (またはFileオブジェクト) を作成すると、そのファイルに対してバッファーが開かれ、そのファイルを読み書きできるようになります。#closeバッファとは何かを完全には理解していませんが、オブジェクトのメソッドを呼び出すまで開いたままになっているようです。私の理解では、このバッファは、あなたが呼び出した場合でも開かれFile.newた場合でも開かれますFile.open(これについて間違っている場合は修正してください)。

Fileしたがって、次のようなパスやものにクラスを使用したいとします。

f = File.new('spec/tmp/testfile.md')
File.basename(f)

しかし、あなたは決して電話しませんf.close。このバッファを開いたままにするとメモリリークが発生しますか? ファイルシステムのツリーに対してこれを数百回呼び出すと、深刻な問題が発生しますか?

返信ありがとうございます。

PS代わりに使用できることはわかっています。File.basename('spec/tmp/testfile.md')これを例として使用しているだけです

4

1 に答える 1

1

はい

一連の操作を除いてsys*、Ruby の IO ops は最終的にファイル記述子とバッファーの両方を割り当てます。

オブジェクトを閉じないIO場合は正しいです...ほとんどの場合、fdとバッファーの両方がリークします。

ここで、上書きするか、古い参照の有効期間を終了するような方法でそれを割り当てると、Ruby はオブジェクト全体を g/c できます。これにより、バッファが確実に解放され、最終的には FD も解放されます。

ただし、すべての言語で、ag/c によってトリガーされるファイナライザーに依存することは非常に悪い習慣であると考えられています。これは、かかる時間と、一度に未処理の OS レベルのリソースがいくつ存在するかを予測できないためです。g/c 機構が起動する前に、ローカルの制限を超える場合があります。

一般的なルールは、OS リソースの割り当てと解放を同期的に行うことです。

そして、私が対象を打ち負かしている限り、例外があります。固定数の記述子または何かを割り当てていて、いずれにせよすべてが一度に存在する必要があり、プログラムが作業の終了後に終了しようとしている場合は、それらをそのままにしておいてかまいません。OSはすべてをクリーンアップします。たとえば、終了直前にメモリを解放しないことをお勧めします。プログラムが終了しようとしている場合、ヒープを管理するために必要な処理は完全に無駄になります。OS は、プログラムのすべてのページを空きリストに載せようとしています。そして例外には例外があります。宿題なら全部解放します。

于 2012-11-13T05:34:52.287 に答える