C＃で同じスコープに対して複数のusingステートメントを使用する場合、Dispose（）メソッドが呼び出される順序が保証されていますか？

usingステートメントは他のブロックレベルのステートメントと同じです。次のようなコードを書いた場合：

if (...)
    if (...)
    {

    }

物事がどのような順序で起こるかはあなたには分かりますが（これは私がその特定の構造を推奨するものではありません）、それはまさにこれと同じです。

if (...)
{
    if(...)
    {

    }
}

したがって、 using があります。あなたのコードは以下のものと変わりありません：

using (...)
{
    using(...)
    {

    }
}

ここでは、内部使用ブロックが最初に終了することが完全にはっきりしているので、リソースは最初に処理する必要があります。

はい、stf2.Disposeが最初に呼び出され、その後stf1.Dispose

とにかく、usingステートメントはtry-finallyに変換されます。その構文的な砂糖..あなたの例はコンパイル時に次のように翻訳されるので、正しいです：

try
{
    Stuff1 stf1 = new Stuff1());
    try
    {
        Stuff2 stf2 = new Stuff2();
    }
    finally
    {
        stf2.Dispose();
    }
}
finally
{
    stf1.Dispose();
}

Stuff2は内部ブロックにあるため、Stuff1の前に配置されます。

Stuff1の外側のブロックにカッコを使用していないにもかかわらず、それはあなたが行ったのと同じです。

可能な再注文による保証はありません。 Disposeは、中かっこ（またはあなたの例では暗黙のもの）で呼び出されます。最適化されていないデバッグビルドでは、常に予想される注文が表示されます。 Thread.MemoryBarrier を使用すると、操作の順序。

using (Stuff1 stf1 = new Stuff1(...))//Allocation of stf1
using (Stuff2 stf2 = new Stuff2(...))//Allocation of stf2
{ {
    try
    {
       //... do stuff with stf1 and stf2 here ...
    }
    catch (Stuff1Exception ex1)
    {
       //...
    }
    catch (Stuff2Exception ex2)
    {
       //...
    }
} Thread.MemoryBarrier(); }

Release-mode optimizations are done in such a way as to guarantee predictable results on this thread after all instructions complete. Everything else (view from a different thread on a separate core) is up for grabs. It's not against the rules to have a situation where stf2 is not yet disposed, but stf1 is disposed, as observed from another thread. Unless you force the order of operations. Try writing some asserts and running under Jinx

はい。Disposeメソッドはusingスコープの最後で呼び出されるため、Dispose（）メソッドはそのオブジェクトが属するオブジェクトの割り当ての逆の順序で呼び出されます