6
ガベージコレクションがメモリのみに拡張され、他のリソースタイプには拡張されないのはなぜですか？
手動のメモリ管理にうんざりしているようで、ガベージコレクションを発明し、生活はかなり良かったです。しかし、他のすべてのリソースタイプはどうですか？ファイル記述子、ソケット、またはデータベース接続などのユーザー作成データですか？ これは素朴な質問のように思えますが、誰かが質問した場所はどこにもありません。ファイル記述子について考えてみましょう。プログラムが起動時にのみ4000 fdsを使用できるようになることをプログラムが知っているとします。ファイル記述子を開く操作を実行するときはいつでも、 間もなく実行されることを確認してください。 そうであれば、ガベージコレクターをトリガーして、大量のメモリを解放します。 解放されたメモリの一部がファイル記述子への参照を保持していた場合は、それらをすぐに閉じます。リソースに関連付けられているメモリは、最初に開かれたときに、より適切な用語がないため、「ファイル記述子レジストリ」に登録されていたため、メモリはリソースに属していることがわかります。 新しいファイル記述子を開き、それを新しいメモリにコピーし、そのメモリ位置を「ファイル記述子レジストリ」に登録して、ユーザーに返します。 したがって、リソースはすぐには解放されませんが、リソースが完全に使用されていない場合、少なくともリソースがなくなる直前に、gcが実行されるたびに解放されます。 そして、それは多くのユーザー定義のリソースクリーンアップ問題には十分だと思われます。私はここで、リソースへの参照を含むスレッドでC ++でこれと同様のクリーンアップを実行することを参照する単一のコメントを見つけ、単一の参照のみが残っている場合に（クリーンアップスレッドから）クリーンアップしますが、これがライブラリまたは既存の言語の一部であることの証拠を見つけます。