好长时间没有写博文了,今天继续。
这次跟大家分享的内容起因于对一个枚举值列表的序列化,下面简化后的代码即能重现。为了明确起见,我显式指定了枚举的基础类型。
// 定义一个枚举类型。 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