一个关于序列化的有趣现象

  这是一个在使用CacheManager做二级缓存的时候发现的蛋疼问题。起因是我准备使用这个组件往缓存中存入一个HashSet类型的数据，该Set拥有一个自定义的Comparer，用来对里面的数据做增删比较。正常情况下，这个Set里面的数据不会很多，因为我会在某些场合取出Set进行更新删除再放回去。但是在测试的时候就出现异常了，存放到里面的数据越来越多。
  在排除了未调用删除方法后，这个问题就指向了HashSet的Remove方法了。该方法的是通过判断数据的hashcode和equal来区分两个数据之间是否相等，进而删除。因为我的数据是值类型，也就是说这个自定义的Comparer不起作用了。
  单步调试后发现，当携带了Comparer的HashSet存入Redis再取出来后，这个Comparer就变成了默认的比较器，也就是对地址进行比较，导致数据无法删除。那么为什么Comparer会消失掉？
  简单看了下CacheManager的源码，发现在将数据存入Redis时，会使用newtonsoft.json先将其序列化，取出时再反序列化回来。这么看来，序列化也许就是主因。再看一下HashSet的源码，可以看到Comparer属性是只读的：

/// 

        /// Gets the IEqualityComparer that is used to determine equality of keys for 
        /// the HashSet.
        /// 
        public IEqualityComparer Comparer {
            get {
                return m_comparer;
            }
        }

m_comparer是私有变量，该变量仅能在构造方法中赋值。而HashSet包含了多个带参的构造方法以及一个默认的，带参的函数也并没有使用序列化相关标记。简单实验就能基本了解反序列化原理：当无构造函数带标记时，将使用默认构造函数进行创建；若无默认构造函数，将会使用带参构造；若带参构造函数有多个，将报异常。
以下的Name为无默认构造函数且含多个带参函数普通类：

string str = Newtonsoft.Json.JsonConvert.SerializeObject(new Name("first") { LastName = "last" });
var der = Newtonsoft.Json.JsonConvert.DeserializeObject(str);

以上代码将报异常：

Unable to find a constructor to use for type Repository.Framework.Name. A class should either have a default constructor, one constructor with arguments or a constructor marked with the JsonConstructor attribute. 

由此可知当HashSet反序列化时，仅会调用默认构造函数，此时Comparer就被置为默认值了，也就发生了丢失。
解决方法：
1、当从内存Get回来后，新建成另外一个HashSet，再操作。
2、不用比较器了，直接使用hashset的RemoveWhere方法。

插曲：
  后续验证还发现，当某个key第一次存进去再取出来后，HashSet的Comparer依然存在；当更新后，就变回了默认值.....真是个骚操作。回头再看了以下CacheManager源码，发现在使用SystemRuntimeCache缓存时，他并不会序列化数据，而我刚好做了多级缓存，有一个就是SystemRuntimeCache。并且调整了一下配置的顺序后，这个现象就消失了。所以猜测和CacheManager内部机制有关，就不再深入了研究了。