C#的装箱和拆箱是什么？有什么区别？-C#.Net教程-PHP中文网

装箱是值类型转引用类型的隐式转换，需堆分配和复制，拆箱是显式转换并伴随类型检查，二者均带来性能开销；避免方式包括使用泛型、Span<T>等减少内存分配与类型转换。

c#的装箱和拆箱是什么？有什么区别？

C#中的装箱（Boxing）和拆箱（Unboxing）是两种将值类型和引用类型相互转换的机制。简单来说，装箱就是把一个值类型（比如

int

登录后复制

、

struct

登录后复制

）“包装”成一个引用类型（

object

登录后复制

），而拆箱则是反过来，把一个被装箱的引用类型“解包”回它原来的值类型。它们之间的核心区别在于，装箱是隐式的，将栈上的值复制到堆上并创建一个引用；而拆箱是显式的，需要明确的类型转换，并且伴随着运行时类型检查，是从堆上获取值并复制回栈上。

装箱和拆箱，从我的个人经验来看，是C#语言设计中一个既强大又需要谨慎对待的特性。它们允许值类型在需要作为

object

登录后复制

或接口类型处理时无缝地融入引用类型的世界，比如在旧的非泛型集合（如

ArrayList

登录后复制

）中存储各种数据。但这种便利性背后，往往隐藏着不小的性能开销，尤其是在高性能场景下，你必须对它们保持警惕。

C#装箱和拆箱的性能开销体现在哪里？

谈到装箱和拆箱，性能开销是一个绕不开的话题，甚至可以说，这是我们作为开发者最需要关注的痛点之一。这不仅仅是理论上的概念，在实际项目中，尤其是在循环密集型操作或者处理大量数据时，装箱和拆箱的开销累积起来，足以让你的程序运行效率大打折扣。

首先，最直接的开销是内存分配。当一个值类型被装箱时，CLR（Common Language Runtime）需要在托管堆（managed heap）上分配一块新的内存区域。这块内存足以容纳值类型的数据本身，以及一个指向其实际类型的额外开销（类型对象指针和同步块索引）。这可不是简单地把一个

int

登录后复制

放进一个

object

登录后复制

那么简单，它涉及到了堆内存的申请，这本身就是一项相对耗时的操作。相比于栈上的分配，堆分配要慢得多。

其次，是数据复制。值类型的数据会从栈上复制到新分配的堆内存中。如果你频繁地进行装箱操作，比如在一个大循环里，每一次装箱都意味着一次数据复制，这无疑增加了CPU的工作量。

再者，垃圾回收（Garbage Collection, GC）的压力。由于装箱在堆上创建了新的对象，这些对象最终都需要被垃圾回收器清理。频繁的装箱会产生大量的短生命周期对象，这会增加GC的工作负担，导致GC更频繁地运行，从而可能引发应用程序的“卡顿”或延迟，尤其是在GC暂停应用程序线程进行回收时。对于实时性要求高的应用，这简直是噩梦。

最后，拆箱时的运行时类型检查和数据复制。拆箱操作并非只是简单地把值从堆上取出来。它需要一个显式的类型转换，并且CLR会在运行时检查目标类型是否与被装箱对象的实际类型兼容。如果类型不匹配，就会抛出

InvalidCastException

登录后复制

。这个类型检查本身也有一定的开销，而且数据同样需要从堆复制回栈。

举个例子，假设你有一个

List<object>

登录后复制

或者旧的

ArrayList

登录后复制

，你往里面添加

int

登录后复制

类型：

List<object> numbers = new List<object>();
for (int i = 0; i < 100000; i++)
{
    numbers.Add(i); // 这里发生了装箱
}
// 访问时如果需要原始类型，会发生拆箱
foreach (object o in numbers)
{
    int num = (int)o; // 这里发生了拆箱和类型检查
}

登录后复制

这段代码看似无害，但在大规模数据操作时，它产生的性能影响是显著的。每一次

numbers.Add(i)

登录后复制

，

登录后复制

都会被装箱。每一次

(int)o

登录后复制

，

登录后复制

都会被拆箱。想想看，十万次甚至百万次的堆分配、数据复制和GC压力，足以拖慢你的程序。

在现代C#开发中，我们如何有效地避免或减少装箱和拆箱？

既然装箱和拆箱有性能开销，那么在现代C#开发中，我们自然要尽可能地避免或减少它们。这不仅仅是为了追求极致性能，更是为了写出更健壮、更可维护的代码。幸运的是，C#语言本身和.NET框架为我们提供了很多强大的工具来解决这个问题。

首先，也是最重要的一点，是使用泛型（Generics）。这是C# 2.0引入的杀手级特性，它的出现极大地缓解了装箱和拆箱的问题。当你使用

List<T>

登录后复制

、

Dictionary<TKey, TValue>

登录后复制

或者自定义泛型类和方法时，编译器在编译时就知道

登录后复制

的具体类型。这意味着，无论是存储值类型还是引用类型，都不需要进行装箱或拆箱操作。数据直接以其原始类型进行存储和访问，避免了堆分配和类型转换的开销。

// 避免装箱的例子：使用泛型List<int>
List<int> numbers = new List<int>();
for (int i = 0; i < 100000; i++)
{
    numbers.Add(i); // 不会发生装箱
}
// 访问时也不会发生拆箱
foreach (int num in numbers)
{
    // 直接使用int类型
}

登录后复制

其次，合理使用

struct

登录后复制

。对于那些小巧、经常被复制、且不涉及多态的值类型，使用

struct

登录后复制

而非

class

登录后复制

可以有效减少堆内存分配，从而降低GC压力。但要注意，

struct

登录后复制

也有其适用场景，过大的

struct

登录后复制

或者频繁作为方法参数传递的

struct

登录后复制

，其复制开销可能会抵消堆分配的优势。

Sider

多功能AI浏览器助手，帮助用户进行聊天、写作、阅读、翻译等

3159

查看详情

再次，关注

object.ToString()

登录后复制

的陷阱。当你在值类型上调用

ToString()

登录后复制

方法时，通常会先发生一次装箱，然后才调用

object

登录后复制

上的

ToString()

登录后复制

方法（或者其重写版本）。为了避免这种情况，你可以直接使用

string.Format

登录后复制

或者C# 6.0及更高版本中的字符串插值（Interpolated Strings），它们通常会提供更优化的路径，避免不必要的装箱。

int value = 123;
// 可能发生装箱
string s1 = value.ToString(); 

// 更好的方式，通常避免装箱
string s2 = string.Format("{0}", value); 
string s3 = $"{value}"; // C# 6.0+，通常更优

登录后复制

此外，在处理某些特定的API时，比如当你需要将值类型作为

IComparable

登录后复制

或

IEquatable

登录后复制

接口的参数传递时，如果这些接口本身不是泛型的，也可能会导致装箱。在这种情况下，优先考虑使用泛型版本的接口，如

IComparable<T>

登录后复制

和

IEquatable<T>

登录后复制

。

最后，对于一些更底层的性能优化场景，C# 7.2及更高版本引入的

Span<T>

登录后复制

和
Memory<T>
登录后复制
等类型，提供了对内存的更直接、更安全的访问方式，可以帮助我们在不进行复制或装箱的情况下处理大量数据，尤其是在处理字节数组或字符串切片时，效果显著。这些类型允许你直接操作内存区域，而无需创建新的对象，从而彻底避免了装箱带来的开销。

装箱和拆箱失败会引发哪些运行时错误？

装箱本身是一个相对“安全”的操作，它只是将值类型包装成

object

登录后复制

。但拆箱就不同了，它是一个潜在的危险点，如果操作不当，很容易在运行时引发错误，最常见的就是

InvalidCastException

登录后复制

。

InvalidCastException

登录后复制

通常发生在以下情况：当你尝试将一个被装箱的

object

登录后复制

类型，拆箱回一个与其原始值类型不兼容的类型时。记住，拆箱操作不仅仅是取出值，它还包含了一个严格的运行时类型检查。CLR会检查你尝试拆箱的目标类型是否与最初装箱时的值类型完全匹配。如果不匹配，即使数据本身可能在内存中，CLR也会为了类型安全而拒绝这个操作，并抛出异常。

这就像你把一个

int

登录后复制

类型的数字装进了一个写着“通用对象”的盒子，然后你试图从这个盒子里面拿出一个“字符串”。系统会告诉你，这个盒子里面根本不是字符串，所以你拿不出来。

来看一个具体的例子：

int originalInt = 123;

// 装箱：将int值类型装箱成object引用类型
object boxedObject = originalInt; // boxedObject现在实际上是一个包含int值的object

// 成功的拆箱：将boxedObject拆箱回int类型
int unboxedInt = (int)boxedObject; 
Console.WriteLine($"成功拆箱：{unboxedInt}"); // 输出：成功拆箱：123

// 失败的拆箱：尝试将boxedObject（实际上是int）拆箱回long类型
try
{
    long unboxedLong = (long)boxedObject; // 这里会抛出InvalidCastException
    Console.WriteLine($"尝试拆箱为long：{unboxedLong}"); 
}
catch (InvalidCastException ex)
{
    Console.WriteLine($"拆箱失败！错误信息：{ex.Message}");
    // 输出：拆箱失败！错误信息：Specified cast is not valid.
}

// 另一个失败的例子：尝试将boxedObject（实际上是int）拆箱回string类型
try
{
    string unboxedString = (string)boxedObject; // 同样会抛出InvalidCastException
    Console.WriteLine($"尝试拆箱为string：{unboxedString}");
}
catch (InvalidCastException ex)
{
    Console.WriteLine($"拆箱失败！错误信息：{ex.Message}");
    // 输出：拆箱失败！错误信息：Specified cast is not valid.
}

登录后复制

在这个例子中，

boxedObject

登录后复制

内部存储的是一个

int

登录后复制

类型的值。当你尝试将其拆箱为

long

登录后复制

或

string

登录后复制

时，即使

int

登录后复制

可以隐式转换为

long

登录后复制

（在非装箱情况下），或者你可以调用

ToString()

登录后复制

来获取字符串表示，但在拆箱的语境下，CLR会坚持类型必须精确匹配。一个被装箱的

int

登录后复制

只能被拆箱回

int

登录后复制

。

这种严格的类型检查机制，虽然在某些情况下可能显得有些“不近人情”，但它却是C#类型安全的重要组成部分。它确保了在程序运行时，你不会意外地将一个类型的数据当作另一个完全不兼容的类型来使用，从而避免了更难以调试的潜在数据损坏或逻辑错误。因此，在进行拆箱操作时，务必确保你知道被装箱对象的真实类型，并将其拆箱回正确的类型。如果实在不确定，可以考虑使用

is

登录后复制

运算符或

as

登录后复制

运算符进行类型检查，以避免直接的异常抛出。例如：

if (boxedObject is long)
{
    long safeUnboxedLong = (long)boxedObject;
    Console.WriteLine($"安全拆箱为long：{safeUnboxedLong}");
}
else
{
    Console.WriteLine("boxedObject不是long类型，无法安全拆箱。");
}

登录后复制

这能够让你在运行时更优雅地处理类型不匹配的情况，而不是让程序直接崩溃。

以上就是C#的装箱和拆箱是什么？有什么区别？的详细内容，更多请关注php中文网其它相关文章！