好长时间没有写博文了，今天继续。
这次跟大家分享的内容起因于对一个枚举值列表的序列化，下面简化后的代码即能重现。为了明确起见，我显式指定了枚举的基础类型。
// 定义一个枚举类型。
public enum SomeEnum ：int
{
First,
Second,
Third,
... ...
}
// 重现问题的代码。
var list = new List<SomeEnum>();
for (int i = 0; i < 1000; ++i)
{
list.Add((SomeEnum)(i % 3));
}
var formatter = new BinaryFormatter();
var stream = File.OpenWrite("c:\\a.data");
formatter.Serialize(stream, list);
stream.Close()
你预料生成的a.data文件大约有多大？
- 如果你估计的结果是12K以上，那么你应该知道我要说什么了，可以洗洗睡了；
- 如果你估计的结果是4K多一些，那么请继续看本文后面的内容。
得到4K结果的同学，我想是这样估计的，SomeEnum枚举用int表示，每个值占用4字节，1000个大约就是4K左右，加上其它一些序列化信息，可能就4K多一些吧。最初我也是这么想的，直到在软件中这样的列表占用了几十兆的内存时，问题才暴露出来。我想我还是比较天真，以为那么简洁的类型应该有相应简洁的序列化方式，我甚至天真到从来没有意识到这是个问题。
我用Reflector跟踪了具体的持久化过程，才发现原来在.NET framework内部，对枚举值并没有像基本类型那样进行处理，而是直接当成普通的值对象处理的。更糟糕的是，对于值对象的处理，居然也要像引用对象那样保存objectId和mapId。我用了“居然”这个词，因为我真的认为值对象（ValueType）就只是数据，不会存在两个reference引用同一个值对象的情况（我知道这样说有些奇怪，但希望你能明白我的意思）——直到现在我也这么认为。
下面是 formatter.Serialize(stream, list) 这句代码执行过程中某一时刻的堆栈状态，为了避免大量的折行影响你的心情，我只保留了函数名部分。
mscorlib.dll!System.Runtime.Serialization.Formatters.Binary.BinaryObject.Write(...) mscorlib.dll!System.Runtime.Serialization.Formatters.Binary.__BinaryWriter.WriteObject(...) mscorlib.dll!System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write(...) mscorlib.dll!System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write(...) mscorlib.dll!System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteArrayMember(...) mscorlib.dll!System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteArray(...) mscorlib.dll!System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write(...) mscorlib.dll!System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize(...) mscorlib.dll!System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(...) mscorlib.dll!System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(System.IO.Stream serializationStream, object graph)
在栈顶上是.NET framework二进制序列化中BinaryObject.Write方法，其实现如下：
public void Write(__BinaryWriter sout)
{
sout.WriteByte(1);
sout.WriteInt32(this.objectId);
sout.WriteInt32(this.mapId);
}
也就是说每写一个枚举值，系统都会先写入1 + 4 + 4 = 9个字节的额外数据！这样算起来，开始处代码产生的文件就大约是 1K * (9 + 4) = 13K ！
这几天我一直在想：为什么对值对象也要写入objectId和mapId呢？根据框架的代码的实际输出来看，系统不会“对值相等的多个值对象只保存一份数据”，那么为什么还要写入这些额外的数据呢？对此我仍不得其解，如果有人知道，还请不吝赐教。
为了解决这个问题，我在类型内部使用了List<int>来保存数据，而在对外接口中完成int和SomeEnum的转换，这样做一来不会影响其它模块的代码，二来也可以将此处理进行屏蔽。
基于同样的原因，对于如下一个值类型来说，要直接使用.NET提供的序列化机制，则每保存一个对象，将额外消耗一倍多的空间。是的，对于引用类型来说也是一样，但还是那句话——我只是没有意识到这个问题，或者说现在还不能接受framework那么粗糙的实现！
[Serializable]
public struct Point
{
private float x, y;
}
为了避免这样的问题，最直接的方法是在包含此类成员的类型上实现ISerializable接口，然后存储转换到基本类型的数据。如果类中要序列化的成员比较多的话，这样做可能会导致其它成员也要手工处理。如果感兴趣，也可以参考我的另一篇博文《深入挖掘.NET序列化机制——实现更易用的序列化方案》看看能不能实现一个统一的机制。
最后再次呼吁：有谁能告诉我微软为什么要如此处理值类型的序列化？
.NET陷阱之六：从枚举值持久化带来大量空间消耗谈起,布布扣,bubuko.com