c# - 什么时候 using 语句框它的参数，当它是一个结构？

Question

我对以下代码有一些疑问:

using System;

namespace ConsoleApplication2
{
    public struct Disposable : IDisposable
    {
        public void Dispose() { }
    }

    class Program
    {
        static void Main(string[] args)
        {
            using (Test()) { }
        }

        static Disposable Test()
        {
            return new Disposable();
        }
    }
}

我的问题是:

• 从 Test() 返回的对 Disposable 结构进行操作的 using 语句是否会将结构装箱？
• 我怎样才能自己找到答案？

为了自己找出答案，我检查了上述代码生成的 IL，这是 Main(...) 方法的 IL:

.method private hidebysig static void Main(string[] args) cil managed
{
    .entrypoint
    .maxstack 1
    .locals init (
        [0] valuetype ConsoleApplication2.Disposable CS$3$0000)
    L_0000: call valuetype ConsoleApplication2.Disposable ConsoleApplication2.Program::Test()
    L_0005: stloc.0 
    L_0006: leave.s L_0016
    L_0008: ldloca.s CS$3$0000
    L_000a: constrained ConsoleApplication2.Disposable
    L_0010: callvirt instance void [mscorlib]System.IDisposable::Dispose()
    L_0015: endfinally 
    L_0016: ret 
    .try L_0006 to L_0008 finally handler L_0008 to L_0016
}

我怀疑在 L_0010 上调用虚方法会引入装箱操作，但实际的 box 指令不在这里。

我问的原因是不久前，大概 1-2 年，我在网上看到有人评论过对 using 语句的“优化”。这种情况是 using 语句用作对象上的短时锁定的语法，在方法中获取锁定，并返回一个结构，在处理后将释放锁定，代码如下:

using (LockTheObject())
{
    // use the object
}

评论是通过将 LockTheObject 方法的返回类型从 IDisposable 更改为实际使用的结构，避免了装箱。

但我想知道这是不是真的，或者仍然是真的。

谁能指出我正确的方向？如果，为了查看框操作，我将不得不检查运行时汇编代码，请告诉我要查找的内容的示例，我精通汇编代码，所以这不是问题，但没有跳出当我看着那个时，也看着我。

Answer 1

似乎任何放入 using 语句中的值类型都不会被装箱。这似乎是 C# 优化，因为仅当实现 IDisposable 的值类型位于 using 语句中时才会省略装箱，而不是在任何其他上下文中。

有关详细信息，请参阅 The Using Statement And Disposable Value Types :

A while ago Ian Griffiths wrote about an improvement to his TimedLock class in which he changed it from a class to a struct. This change resulted in a value type that implements IDisposable. I had a nagging question in the back of my mind at the time that I quickly forgot about. The question is wouldn’t instances of that type get boxed when calling Dispose?

还有Oh No! Not the TimedLock Again! :

John Sands points out a flaw in the code I showed in a recent blog for using timeouts on locks without abandoning most of the convenience of C#'s lock keyword .