1

メソッドの呼び出し中に IDisposable を実装するオブジェクトをインスタンス化するとどうなりますか?

例えば

return MyMethod(new MyIDisposableObject());

MYIDisposableObject の Dispose メソッドが呼び出されることはありますか?

OK、MyIDisposableObject に次のコードがある場合、IDBConnection は閉じられて適切に破棄されますか、それとも安全ではありませんか?

protected IDbConnection _db;
    bool _disposed;

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    ~MyIDisposableObject()
    {
        Dispose(false);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (_disposed)
            return;

        if (disposing)
        {
            // free other managed objects that implement
            // IDisposable only
            if (_db != null)
            {
                _db.Close();
                _db.Dispose();
            }
        }

        // release any unmanaged objects
        // set the object references to null
        _db = null;

        _disposed = true;
    }
4

4 に答える 4

3

Dispose()が通常の方法です。
他のメソッドと同様に、それを呼び出すコードを記述しない限り呼び出されません。

たとえば、using()ステートメントはDispose()メソッドを呼び出すコードを生成します。

Dispose(false)ネイティブ リソースを所有するクラスには、それらを解放するために呼び出すファイナライザーが必要であることに注意してください (Dispose()パターンを参照)。
オブジェクトが GC されると、ファイナライザーが実行されます (決して起こらない可能性があります) 。

于 2013-10-11T20:37:28.150 に答える
0

そのパラメーターMyMethodのメソッドを呼び出さない限り、いいえ、そうはなりません。Dispose()そして、それは素晴らしいパターンではありません。リソースを所有するコードにリソースを破棄させます。あなたのコードは、より慣用的に次のように書く必要があります。

using (var o = new MyIDisposableObject())
{
    return MyMethod(o);
}
于 2013-10-11T21:25:54.397 に答える
0

オブジェクトの有効期間とそのリソースのクリーンアップが密接に関連している C++ とは異なり、.NET ではそれらはほとんど切り離されています。.NET のオブジェクトは、システムがそのオブジェクトについて「認識」している限り存続します。または、それらへの参照が、システムが認識している他のオブジェクトに保持されます。オブジェクトへの最後の参照が上書きされると、オブジェクトは存在しなくなります。システムは特定のオブジェクトへの「非表示の」参照を保持していますが (たとえば、登録されているすべてのオブジェクトのリストがあります)Finalizeメソッド)、多くの場合、特定のオブジェクトが存在したことを示す唯一の証拠は、そのオブジェクトへのユーザー コード参照です。たとえば、GC が認識しているものによって使用されていない 1024 バイトの範囲のメモリがある場合、GC は、その領域が 16 個の 64 バイト オブジェクト、12 個の 84 バイト オブジェクト、および16 バイト オブジェクト、またはその他のオブジェクトの組み合わせ。

このアプローチは、メモリの管理に非常に適しています。これに関する 1 つの問題は、追って通知があるまで、オブジェクトが他のエンティティに何かを行うように要求する場合 (ファイルへの排他的アクセスを許可するなど) に発生します。ファイルへの排他的アクセスを要求するオブジェクトが、そのようなアクセスが不要になったことを誰にも知らせずに単に存在しなくなった場合、そのファイルは不必要に他の人からアクセスできなくなります。このIDisposableインターフェースは、この問題をいくらか解決します。メソッドが呼び出されるオブジェクトDisposeは、そのようなサービスを必要としないことを、通知があるまで、自分に代わって何かを行うように要求したすべてのエンティティに通知する必要があります。

適切に使用するための鍵IDisposableは、クリーンアップを必要とするすべてのオブジェクトが常に 1 つの「所有者」を持つようにすることです。usingその所有者は、またはtry/ブロックを介して保護されるローカル変数、finallyまたは を実装するオブジェクトのフィールドである必要があり、独自のメソッドが呼び出されたときにフィールドにIDisposableなります。を所有するローカル変数を持つメソッドが、呼び出しを行わずにその変数を返す場合、所有権はメソッドの呼び出し元に転送されます。C# には、メソッド内で作成されたオブジェクトがメソッドから返された後に不要になる場合を除いて、所有権を認識するための言語構造がないことに注意してください (DisposeDisposeIDisposableDisposeusingブロックはそのケースを適切に処理します)。それ以外の場合、プログラマはオブジェクトの所有権を手動で追跡する必要があります。そうしなくてもコンパイル エラーは発生しませんが、多くの場合、プログラムが動作しなくなったり、サービスが不要になったという通知を外部のエンティティが不必要に待ったりする原因になります。

の場合はreturn new MyIDisposableObject();、上記のパターンのいずれにも完全には適合しませんが、try/finally によって保護されている場合は次のようになるため、許容されます。

bool ok = false;
MyIDisposableObject ret = null;
try
{
  ret = new MyIDisposableObject();
  ok = true;
  return ret;
}
finally
{
  if (!ok && ret != null)
    ret.Dispose();
}

ステートメントが実行される唯一の方法は、store toと次の return のret.Dispose()間で例外が発生した場合です。retコードがreturn new MyIDisposableObject();のように記述されている場合、そこで例外が発生する可能性はありません。

ただし、別の関数呼び出しを追加するため、コードは異なります。ただし、そのパターンはMyMethod、渡されたオブジェクトをカプセル化するオブジェクトを返すことが約束されている場合、またはDispose例外のためにカプセル化できない場合にのみ安全です。MyMethod通常はそうではないため、 が渡された参照をカプセル化するオブジェクトを返すかどうかに応じて、正しいパターンは次のいずれかになります。

using (var myObject = new MyDisposableObject())
  return MyMethod(myObject);

がによって返されるオブジェクトにカプセル化されMyDisposableObjectず、MyMethod返された後はそれ以上使用されない場合、またはそうでない場合

MyIDisposableObject innerObject = new MyDisposableobject;
try
{
  var ret = MyMethod(innerObject);
  innerObject = null; // Note that `ret` still has an encapsulated reference to it
  return ret;
}
finally
{
  if (innerObject != null) // Reference wasn't yet encapsulated in `ret`
    innerObject.Dispose();
}

の呼び出しがMyMethod成功した場合、innerObject変数はクリアされますが、オブジェクトは外部エンティティにサービスを中止するよう通知するように指示されないことに注意してMyMethodくださいinnerObject。それらの外部エンティティのサービスが必要になります。への呼び出しMyMethodで例外がスローされた場合、innerObject変数はクリアされず、finallyブロック コードは への唯一の参照を保持していることinnerObject、その参照が消えようとしていることがわかり、他のコードは を使用しなくなりますinnerObject。したがって、finallyブロックは、innerObject外部エンティティにサービスが不要になったことをすぐに通知するように依頼する必要があります。、そうしない場合は、他に何もしません。

于 2013-10-13T16:20:49.990 に答える