Чи може «використання» більше ніж одного ресурсу спричинити витік ресурсу?

C # дозволяє мені зробити наступне (приклад з MSDN):

using (Font font3 = new Font("Arial", 10.0f),
            font4 = new Font("Arial", 10.0f))
{
    // Use font3 and font4.
}

Що станеться, якщо font4 = new Fontкидає? З того, що я розумію, font3 просочиться ресурсами і не буде утилізований.

• Це правда? (font4 не буде утилізований)
• Чи using(... , ...)варто цього взагалі уникати на користь вкладеного вкладеного?

Немає.

Компілятор генерує окремий finallyблок для кожної змінної.

Специфікації (§8.13) говорить:

Коли придбання ресурсів має форму локальної змінної-декларації, можливо придбати кілька ресурсів заданого типу. usingзатвердження виду

using (ResourceType r1 = e1, r2 = e2, ..., rN = eN) statement 

точно еквівалентний послідовності вкладених з використанням операторів:

using (ResourceType r1 = e1)
   using (ResourceType r2 = e2)
      ...
         using (ResourceType rN = eN)
            statement

ОНОВЛЕННЯ : я використав це питання як основу для статті, яку можна знайти тут ; див. для додаткового обговорення цього питання. Дякую за гарне запитання!

Хоча відповідь Шабсе, безумовно, правильна і відповідає на запитання, яке було задано, у вашому питанні є важливий варіант, якого ви не задавали:

Що станеться, якщо font4 = new Font()викиди після того, як некерований ресурс був призначений конструктором, але до того, як ctor повернеться і заповнить font4посилання?

Дозвольте зробити це трохи більш зрозумілим. Припустимо, у нас є:

public sealed class Foo : IDisposable
{
    private int handle = 0;
    private bool disposed = false;
    public Foo()
    {
        Blah1();
        int x = AllocateResource();
        Blah2();
        this.handle = x;
        Blah3();
    }
    ~Foo()
    {
        Dispose(false);
    }
    public void Dispose() 
    { 
        Dispose(true); 
        GC.SuppressFinalize(this);
    }
    private void Dispose(bool disposing)
    {
        if (!this.disposed)
        {
            if (this.handle != 0) 
                DeallocateResource(this.handle);
            this.handle = 0;
            this.disposed = true;
        }
    }
}

Зараз у нас є

using(Foo foo = new Foo())
    Whatever(foo);

Це те саме, що

{
    Foo foo = new Foo();
    try
    {
        Whatever(foo);
    }
    finally
    {
        IDisposable d = foo as IDisposable;
        if (d != null) 
            d.Dispose();
    }
}

ГАРАЗД. Припустимо, Whateverкидки. Потім finallyблок запускається і ресурс розміщується. Нема проблем.

Припустимо, Blah1()кидки. Тоді викид відбувається до виділення ресурсу. Об'єкт виділено, але ctor ніколи не повертається, тому fooніколи не заповнюється. Ми ніколи не входили tryтак, ми ніколи не вводимо finallyжодне. Посилання на об'єкт осиротіла. Врешті-решт, GC виявить це і поставить його до черги фіналізатора. handleдосі дорівнює нулю, тому фіналізатор нічого не робить. Зауважте, що фіналізатор повинен бути надійним перед об'єктом, який доопрацьовується, конструктор якого так і не завершився . Ви повинні написати фіналізатори, які є сильними. Це ще одна причина, чому ви повинні залишити писати фіналізатори експертам, а не намагатися зробити це самостійно.

Припустимо, Blah3()кидки. Кидок відбувається після виділення ресурсу. Але знову ж таки, fooніколи не заповнюється, ми ніколи не входимо вfinally в об'єкт, і об'єкт очищається потоком фіналізатора. Цього разу ручка не дорівнює нулю, і фіналізатор очищає її. Знову фіналізатор працює на об'єкті, конструктор якого ніколи не вдавався, але фіналізатор все одно працює. Очевидно, що це мусить, бо цього разу йому довелося попрацювати.

Тепер припустимо, Blah2()кидки. Кидок відбувається після виділення ресурсу, але до того, як handle буде заповнено! Знову фіналізатор запуститься, але зараз handleще нуль, і ми просочимо ручку!

Вам потрібно написати надзвичайно розумний код, щоб не допустити цього витоку. Тепер, що стосується вашого Fontресурсу, хто до біса піклується? Ми просочуємо ручку шрифту, велика справа. Але якщо ви абсолютно позитивно вимагаєте, щоб кожен некерований ресурс був очищений, незалежно від часу винятків тоді у вас дуже складна проблема.

CLR має вирішити цю проблему із замками. Оскільки C # 4, блоки, які використовують lockоператор, реалізовані так:

bool lockEntered = false;
object lockObject = whatever;
try
{
    Monitor.Enter(lockObject, ref lockEntered);
    lock body here
}
finally
{
    if (lockEntered) Monitor.Exit(lockObject);
}

Enterбуло дуже ретельно написано так, що незалежно від того, які винятки викидаються , lockEnteredвстановлено значення "true", якщо і лише тоді, коли блокування було зроблено насправді. Якщо у вас є подібні вимоги, тоді вам потрібно написати:

    public Foo()
    {
        Blah1();
        AllocateResource(ref handle);
        Blah2();
        Blah3();
    }

і пишіть AllocateResourceрозумно Monitor.Enterтак, щоб незалежно від того, що відбувається всередині AllocateResource, handleзаповнюється, якщо і лише тоді, коли його потрібно буде розмістити.

Опис прийомів цього виходить за межі цієї відповіді. Якщо у вас є ця вимога, зверніться до експерта.

Як додаток до відповіді @SLaks, ось ІЛ для вашого коду:

.method private hidebysig static 
    void Main (
        string[] args
    ) cil managed 
{
    // Method begins at RVA 0x2050
    // Code size 74 (0x4a)
    .maxstack 2
    .entrypoint
    .locals init (
        [0] class [System.Drawing]System.Drawing.Font font3,
        [1] class [System.Drawing]System.Drawing.Font font4,
        [2] bool CS$4$0000
    )

    IL_0000: nop
    IL_0001: ldstr "Arial"
    IL_0006: ldc.r4 10
    IL_000b: newobj instance void [System.Drawing]System.Drawing.Font::.ctor(string, float32)
    IL_0010: stloc.0
    .try
    {
        IL_0011: ldstr "Arial"
        IL_0016: ldc.r4 10
        IL_001b: newobj instance void [System.Drawing]System.Drawing.Font::.ctor(string, float32)
        IL_0020: stloc.1
        .try
        {
            IL_0021: nop
            IL_0022: nop
            IL_0023: leave.s IL_0035
        } // end .try
        finally
        {
            IL_0025: ldloc.1
            IL_0026: ldnull
            IL_0027: ceq
            IL_0029: stloc.2
            IL_002a: ldloc.2
            IL_002b: brtrue.s IL_0034

            IL_002d: ldloc.1
            IL_002e: callvirt instance void [mscorlib]System.IDisposable::Dispose()
            IL_0033: nop

            IL_0034: endfinally
        } // end handler

        IL_0035: nop
        IL_0036: leave.s IL_0048
    } // end .try
    finally
    {
        IL_0038: ldloc.0
        IL_0039: ldnull
        IL_003a: ceq
        IL_003c: stloc.2
        IL_003d: ldloc.2
        IL_003e: brtrue.s IL_0047

        IL_0040: ldloc.0
        IL_0041: callvirt instance void [mscorlib]System.IDisposable::Dispose()
        IL_0046: nop

        IL_0047: endfinally
    } // end handler

    IL_0048: nop
    IL_0049: ret
} // end of method Program::Main

Зверніть увагу на вкладені блоки спробуйте / нарешті.

Цей код (заснований на оригінальній вибірці):

using System.Drawing;

public class Class1
{
    public Class1()
    {
        using (Font font3 = new Font("Arial", 10.0f),
                    font4 = new Font("Arial", 10.0f))
        {
            // Use font3 and font4.
        }
    }
}

Він створює наступний CIL (у Visual Studio 2013 , орієнтований на .NET 4.5.1):

.method public hidebysig specialname rtspecialname
        instance void  .ctor() cil managed
{
    // Code size       82 (0x52)
    .maxstack  2
    .locals init ([0] class [System.Drawing]System.Drawing.Font font3,
                  [1] class [System.Drawing]System.Drawing.Font font4,
                  [2] bool CS$4$0000)
    IL_0000:  ldarg.0
    IL_0001:  call       instance void [mscorlib]System.Object::.ctor()
    IL_0006:  nop
    IL_0007:  nop
    IL_0008:  ldstr      "Arial"
    IL_000d:  ldc.r4     10.
    IL_0012:  newobj     instance void [System.Drawing]System.Drawing.Font::.ctor(string,
                                                                                  float32)
    IL_0017:  stloc.0
    .try
    {
        IL_0018:  ldstr      "Arial"
        IL_001d:  ldc.r4     10.
        IL_0022:  newobj     instance void [System.Drawing]System.Drawing.Font::.ctor(string,
                                                                                      float32)
        IL_0027:  stloc.1
        .try
        {
            IL_0028:  nop
            IL_0029:  nop
            IL_002a:  leave.s    IL_003c
        }  // end .try
        finally
        {
            IL_002c:  ldloc.1
            IL_002d:  ldnull
            IL_002e:  ceq
            IL_0030:  stloc.2
            IL_0031:  ldloc.2
            IL_0032:  brtrue.s   IL_003b
            IL_0034:  ldloc.1
            IL_0035:  callvirt   instance void [mscorlib]System.IDisposable::Dispose()
            IL_003a:  nop
            IL_003b:  endfinally
        }  // end handler
        IL_003c:  nop
        IL_003d:  leave.s    IL_004f
    }  // end .try
    finally
    {
        IL_003f:  ldloc.0
        IL_0040:  ldnull
        IL_0041:  ceq
        IL_0043:  stloc.2
        IL_0044:  ldloc.2
        IL_0045:  brtrue.s   IL_004e
        IL_0047:  ldloc.0
        IL_0048:  callvirt   instance void [mscorlib]System.IDisposable::Dispose()
        IL_004d:  nop
        IL_004e:  endfinally
    }  // end handler
    IL_004f:  nop
    IL_0050:  nop
    IL_0051:  ret
} // end of method Class1::.ctor

Як бачите, try {}блок не починається до першого розподілу, який відбувається в IL_0012. На перший погляд, це, здається, виділяє перший елемент у незахищеному коді. Однак зауважте, що результат зберігається у розташуванні 0. Якщо другий розподіл потім не вдається, зовнішній finally {} блок виконується, і він отримує об'єкт з місця 0, тобто першого розподілу font3, і викликає його Dispose()метод.

Цікаво, що декомпіляція цієї збірки за допомогою dotPeek створює наступне відновлене джерело:

using System.Drawing;

public class Class1
{
    public Class1()
    {
        using (new Font("Arial", 10f))
        {
            using (new Font("Arial", 10f))
                ;
        }
    }
}

Декомпільований код підтверджує, що все правильно і що по usingсуті розширено на вкладені usings. Код CIL трохи заплутано дивитись, і мені довелося дивитись на нього добрі кілька хвилин, перш ніж я правильно зрозумів, що відбувається, тому я не здивований, що деякі «казки про старих дружин» почали проростати це. Однак згенерований код - це правда, яка недоступна.

Ось зразок коду для підтвердження відповіді @SLaks:

void Main()
{
    try
    {
        using (TestUsing t1 = new TestUsing("t1"), t2 = new TestUsing("t2"))
        {
        }
    }
    catch(Exception ex)
    {
        Console.WriteLine("catch");
    }
    finally
    {
        Console.WriteLine("done");
    }

    /* outputs

        Construct: t1
        Construct: t2
        Dispose: t1
        catch
        done

    */
}

public class TestUsing : IDisposable
{
    public string Name {get; set;}

    public TestUsing(string name)
    {
        Name = name;

        Console.WriteLine("Construct: " + Name);

        if (Name == "t2") throw new Exception();
    }

    public void Dispose()
    {
        Console.WriteLine("Dispose: " + Name);
    }
}