テキスト ファイルから読み取る場合、通常は を作成しFileReader、それを にネストしBufferedReaderます。読み終わったら、2 つのリーダーのどちらを閉じる必要がありますか? それは問題ですか？

例外安全性に関しては、私は少し妄想的です。BufferedReaderコンストラクターが例外をスローするとどうなりますか? ネストされたリーダーを閉じますか? それとも、投げないことが保証されていますか？

このMSDNページ の最後の文によると、useよりも優先されusingます。私は他の場所でそれを聞いたことがあります（たとえば、この答え）。どうしてこれなの？後で追加されたことに気づきuseました。しかし、違いは何ですか？表面的には、が呼び出されるタイミングを制御でき、必要に応じてバインドされた値（たとえば）を明示的に無視できるusingため、より便利なようです。Dispose()(fun _ -> ...)

Executor executor;アプリケーションのどこかに があるとします。setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);いつものように言って「システム」に処理させるだけで十分ですか、それともリスナーを登録しexecutor.shutdown();てアプリケーションが終了する前に手動で呼び出す必要がありますか?

オプションにリソースオブジェクトが保存されています。

プログラム実行中のある時点で、ochanはに設定されSome(channel)ます。close（メソッドを呼び出して）チャネルを閉じ、オプションをNone1回の致命的な急降下でに設定したいと思います。

現在私は持っています：

そして以前私は持っていました：

これを行うためのより良い方法はありますか？

基本的には、ファイルを開いて、いくつかのバイトを読み取ってから、ファイルを閉じます。これは私が思いついたものです：

たぶん私はRAIIに甘やかされていますが、Javaでこれを行うためのより良い方法があるはずですよね？

動的に割り当てられた10個の要素の配列へのポインターがあるとします。

後で、その配列を解放したいと思います。

Tデストラクタの1つが例外をスローした場合はどうなりますか？他の要素はまだ破壊されていますか？メモリは解放されますか？例外は伝播されますか、それともプログラムの実行は終了しますか？

同様に、astd::vector<T>が破壊され、T破壊者の1人が投げるとどうなりますか？

特定のポートでリッスンしているソケットを割り当て、それを使って何かを実行し、異常終了するプロセスがあると仮定します。ここで、2番目のプロセスが開始し、以前にcrahsedプロセスによって保持されていたのと同じポートでリッスンしているソケットを割り当てたいと考えています。このソケットは再割り当てに使用できますか？

• オペレーティングシステムは、適切に解放されなかったリソースをどのように回復しますか？OSは、割り当てられた各リソースとともにプロセスIDを追跡しますか？

• このクリーンアップは、すべてのPOSIX準拠システムに期待できることですか？

Locks自動クローズ可能ですか？つまり、次の代わりに：

...言ってもいい：

... Java 7では？

私が取り組んでいる C++/CLI (および C#) プロジェクトの早い段階で呼び出されているように見えるファイナライザーに問題があります。これは非常に複雑な問題のようで、コードから多くの異なるクラスと型について言及します。幸いなことに、これはオープン ソースであり、次のリンクをたどることができます: Pstsdk.Net (mercurial リポジトリ) また、必要に応じてファイル ブラウザーに直接リンクすることも試みたので、読みながらコードを表示できます。扱うコードのほとんどはpstsdk.mcpp、リポジトリのフォルダーにあります。

現在、コードはかなりひどい状態にあり (私はそれに取り組んでいます)、私が取り組んでいるコードの現在のバージョンはFinalization fixes (UNSTABLE!)ブランチにあります。そのブランチには 2 つの変更セットがあり、私の長々とした質問を理解するには、両方に対処する必要があります。(変更セット: ee6a002df36fおよびa12e9f5ea9fe )

背景として、このプロジェクトは C++ で書かれたアンマネージ ライブラリの C++/CLI ラッパーです。私はプロジェクトのコーディネーターではありません。また、コードを見た多くの人が同意するであろうと確信しているように、私が同意しない設計上の決定がいくつかありますが、余談になります。元のライブラリのレイヤーの多くを C++/CLI dll にラップしていますが、使いやすい API は C# dll で公開しています。これは、プロジェクトの目的がライブラリ全体をマネージ C# コードに変換することであるためです。

コードをコンパイルできる場合は、このテスト コードを使用して問題を再現できます。

問題

というタイトルの最新の変更セットは、moved resource management code to finalizers, to show bug私が抱えていた元の問題を示しています。このコードのすべてのクラスは、同じパターンを使用してアンマネージ リソースを解放します。以下に例を示します (C++/CLI):

このコードには 2 つの利点があります。まず、このようなクラスがusingステートメントにある場合、リソースはすぐに適切に解放されます。第 2 に、ユーザーが破棄を忘れた場合、GC が最終的にクラスのファイナライズを決定したときに、管理されていないリソースが解放されます。

ここに、このアプローチの問題点があります。私が理解できないのは、時折、ファイル内のデータを列挙するために使用されるクラスの一部を GC がファイナライズすることを決定することです。これは多くの異なる PST ファイルで発生し、クラスがまだ使用されているにもかかわらず、Finalize メソッドが呼び出されたことに関係があると判断できました。

このファイル (ダウンロード) ¹で一貫して発生させることができます。早期に呼び出されるファイナライザーは、 DBAccessor.cppファイル内のNodeIdCollectionクラスにあります。上記にリンクされたコードを実行できる場合 (このプロジェクトは、boost ライブラリへの依存関係のためにセットアップが難しい場合があります)、アプリケーションは例外で失敗します。これは、リストが null に設定され、ポインターがファイナライザーの実行の結果としてリセットされます。_nodes_db_

1) クラスの列挙コードに、NodeIdCollection使用中に GC がこのクラスをファイナライズするような明らかな問題はありますか?

以下で説明する回避策を使用して、コードを適切に実行することしかできませんでした。

見苦しい回避策

!classnameここで、すべてのリソース管理コードを各ファイナライザー ( ) からデストラクタ ( )に移動することで、この問題を回避することができました~classname。これで問題は解決しましたが、なぜクラスが早期にファイナライズされるのかという私の好奇心は解決されませんでした。

ただし、アプローチには問題があり、それよりも設計の問題であることは認めます。コード内でポインターが頻繁に使用されるため、ほぼすべてのクラスが独自のリソースを処理し、各クラスを破棄する必要があります。これにより、列挙型の使用が非常に見苦しくなります (C#):

コレクション内のアイテムに作用する using ステートメントは、私には間違っているように思えますが、このアプローチでは、メモリ リークを防ぐことが非常に必要です。これがないと、pst クラスの dispose メソッドが呼び出されても、dispose が呼び出されず、メモリが解放されません。

私はこのデザインを変更しようとするあらゆる意図を持っています。このコードが最初に書かれたときの根本的な問題は、私が C++/CLI についてほとんどまたはまったく知らなかったという事実に加えて、ネイティブ クラスをマネージ クラス内に配置できなかったことです。クラスが使用されなくなったときにメモリを自動的に解放するスコープ付きポインターを使用できると思いますが、それが有効な方法であるかどうか、または機能するかどうかはわかりません。だから、私の2番目の質問は次のとおりです。

2) 管理されたクラスの管理されていないリソースを簡単に処理するための最良の方法は何ですか?

詳しく説明すると、ネイティブ ポインターをclr_scoped_ptr最近コードに追加されたラッパー (このstackexchangeの質問の clr_scoped_ptr.h )に置き換えることができますか? または、ネイティブ ポインターを or のようなものでラップする必要がありますか?scoped_ptr<T>smart_ptr<T>

これをすべて読んでくれてありがとう、私はそれがたくさんあったことを知っています。私よりも少し経験豊富な人からいくつかの洞察を得ることができるように、私は十分に明確であったことを願っています. それは非常に大きな質問です。私も可能であれば報奨金を追加するつもりです。うまくいけば、誰かが助けることができます。

ありがとう！

¹このファイルは、自由に利用できるPST ファイルのエンロン データセットの一部です。