你可能不知道的陷阱, IEnumerable接口

1. IEnumerable 与 IEnumerator

IEnumerable枚举器接口的重要性，说一万句话都不过分。几乎所有集合都实现了这个接口，Linq的核心也依赖于这个万能的接口。C语言的for循环写得心烦，foreach就顺畅了很多。

IEnumerable只有一个抽象方法：GetEnumerator()，而IEnumerator又是一个迭代器接口，真正实现了访问集合的功能。 IEnumerator只有一个Current属性，两个方法MoveNext和Reset。

有个小问题，只搞一个访问器接口不就得了？为什么要两个看起来很容易混淆的接口呢？一个叫枚举器，另一个叫迭代器。因为

　　(1) 实现IEnumerator是个脏活累活，白白加了两个方法一个属性，而且这两个方法其实并不好实现（后面会提到）。

　　(2) 它需要维护初始状态，知道如何Move,如何结束，同时返回迭代的上一个状态，这些并不容易。

(3)迭代显然是非线程安全的，每次IEnumerable都会生成新的IEnumerator，从而形成多个互相不影响的迭代过程。在迭代过程中，不能修改迭代集合，否则不安全。

所以只要你实现了IEnumerable，编译器就会帮我们实现IEnumerator。何况绝大多数情况都是从现有集合继承，一般不需要重写MoveNext和Reset方法。 IEnumerable当然还有泛型实现，这个不影响问题的讨论。

IEnumerable让我们想起了单向链表，C中需要一个指针域保存下一个节点的信息，那么在IEnumerable中，谁帮忙保存了这个信息？这个过程占用内存么？是占在程序区，还是堆区？

反正你知道，如果在某个过程中再调用一次IEnumerable的枚举，枚举其实是从头开始的。所以，每次枚举，生成的都是新的IEnumerator对象。

但是，IEnumerable也有它致命的缺点，它没法后退（确实是单向的），没法跳跃（只能一个一个的跳过去），而且实现Reset并不容易。想想看，如果是一个实例集合的枚举过程，直接返回到第0个元素就可以了，但是如果这个IEnumerable是漫长的访问链条，想找到最初的根，难度如何之大！所以CLR via C#的作者告诉你，其实很多Reset的实现根本就是谎言，知道有这个东西就行了，不要太过依赖它。

　　2. foreach和MoveNext有区别吗

IEnumerable最大的特点是将访问的过程，交给了被访问者本身控制。在C语言中数组控制权是外部完全掌握的。这个接口却在内部封装访问了的过程，进一步提升了封装性。比如下面：

public class People  //定义一个简单的实体类
    {
        public string Name { get; set; }
        public int Age { get; set; }
    }

    public class PersonList
    {
        private readonly List<People> peoples;

        public PersonList()  //为了方便，构造过程中插入元素
        {
            peoples = new List<People>();
            for (int i = 0; i < 5; i++)
            {
                peoples.Add(new People {Name = "P" + i, Age = 30 + i});
            }
        }

        public int OldAge = 31;
        public IEnumerable<People> OlderPeoples
        {
            get
            {
                foreach (People people in _people)
                {
                    if (people.Age > OldAge)
                        yield return people;
                }
                yield break;
            }
        }
    }

IEnumerable的本质是状态机，它有点类似事件的概念，将实现丢到外面，实现代码间的穿越（想想星际穿越），实现了访问链，这是Linq的基础。酷炫的迭代器，真的有我们想象的那么简单么？

在C语言中，数组就是数组，实实在在的内存空间，那么IEnumerable到底是什么意思呢？如果它由一个真正的集合（比如List）实现，那么没问题，也是实实在在的内存，可是如果是上述的例子呢？筛选返回的yield return 只返回了元素，但可能并不存在这个实际的集合，想到这里，你肯定明白，这个接口代表了一种“状态”。如果你将简单的枚举器的yield return 反编译后看，会发现其实是一组switch-case, 编译器在后台为我们做了大量的工作。

生成的新迭代器，如果不MoveNext，其实Current是空的，这是为什么呢？为什么一个迭代器不直接指向头元素呢？（留给大家思考，我也没想清楚）

foreach每次往前移动一格，到头了就停止。等等，你确定它到头了就会停止么？我们来做个试验：

public IEnumerable<People> Peoples1   //直接返回集合
        {
            get { return peoples; }
        }
        public IEnumerable<People> Peoples2  //没有yield break;
        {
            get
            {
                foreach (var people in peoples)
                {
                    yield return people;
                }
            }
        }
       
        public IEnumerable<People> Peoples3  //包含yield break;
        {
            get
            {
                foreach (var people in peoples)
                {
                    yield return people;
                }
                yield break;
            }
        }

以上三种，是我们常见的方式，注意第三种实现，ReSharper把yield break标成灰色（重复），真的是没有必要的么？

我们再写下如下的测试代码，peopleList集合只有五个元素，但尝试去MoveNext 8次。可以把peopleList.Peoples1换成2,3，分别测试。

var peopleList = new PeopleList();  //内部构造函数插入了五个元素
            IEnumerator<People> e1 = peopleList.Peoples1.GetEnumerator();
            if (e1.Current == null)
            {
                Console.WriteLine("迭代器生成后Current为空");
            }
            int i = 0;
            while (i<8)  //总共只有五个元素，看看一直迭代会发生什么效果
            {
                e1.MoveNext();
                if (e1.Current == null)
                {
                    Console.WriteLine("迭代第{0}次后为空",i);
                }
                else
                {
                    Console.WriteLine("迭代第{0}次后为{1}",i,e1.Current.Name);
                }
                i++;
            }

//PeopleEnumerable1   (直接返回集合)
迭代器生成后Current为空
迭代第0次后为P0
迭代第1次后为P1
迭代第2次后为P2
迭代第3次后为P3
迭代第4次后为P4
迭代第5次后为空
迭代第6次后为空
迭代第7次后为空

//PeopleEnumerable2 （不加yield break）
迭代器生成后Current为空
迭代第0次后为P0
迭代第1次后为P1
迭代第2次后为P2
迭代第3次后为P3
迭代第4次后为P4
迭代第5次后为P4
迭代第6次后为P4
迭代第7次后为P4


//PeopleEnumerable2 （加上yield break）
迭代器生成后Current为空
迭代第0次后为P0
迭代第1次后为P1
迭代第2次后为P2
迭代第3次后为P3
迭代第4次后为P4
迭代第5次后为P4
迭代第6次后为P4
迭代第7次后为P4

越界枚举测试结果

真让人吃惊，返回原始集合，越界之后就返回null了，但如果是MoveNext，不论有没有加yield break, 越界迭代后还是返回最后一个元素！为什么会这样呢？这个过程中发生了什么？也许就是我们在第1节里提到的，迭代器只返回上一次的状态，因为无法后移，所以就重复返回，那为什么List集合就不会这样呢？问题留给大家。

不过各位看官尽管放心，在foreach的标准枚举过程下，枚举是肯定能枚举完的，这就说明了MoveNext和foreach两种在实现上的不同，显然foreach更安全。同时还注意，不能在yield过程中实现try-catch代码块，为什么呢？因为yield模式组合了来自不同位置的代码和逻辑，怎么可能靠编译给每个引用的代码块加上try-catch？这太复杂了。

枚举的特性在处理大数据的时候很有帮助，就是因为它的状态性，一个超大的文件，我只要每次读一部分，就可以顺次的读取下去，直到文件结束，由于不需要实例化集合，内存占用是很低的。对数据库也是如此，每次读取一部分，就能应对很多难以应付的情况。

　　3.在枚举中修改枚举器参数？

在枚举过程中，集合是不能被修改的，比如在foreach循环中，如果插入或者删除一个元素，肯定会报运行时异常。有经验的程序员告诉你，此时用for循环。但你想过没有，for和foreach的本质区别是什么呢？

在MoveNext中，我突然改变了枚举的参数，使得它的数据量变多或者变少了，又会发生什么？

注意第一个代码段里：

public int OldAge = 31;
        public IEnumerable<People> OlderPeoples
        {
            get
            {
                foreach (People people in _people)
                {
                    if (people.Age > OldAge)  //内部变量控制着迭代的数量
                        yield return people;
                }
                yield break;
            }
        }

那么在访问过程中，修改OldAge的值，会怎样呢？

   Console.WriteLine("不修改OldAge参数");
            foreach (var olderPeople in peopleList.OlderPeoples)
            {
                Console.WriteLine(olderPeople);
              
            }

            Console.WriteLine("修改了OldAge参数");
            i = 0;
            foreach (var olderPeople in peopleList.OlderPeoples)
            {
                Console.WriteLine(olderPeople);
                i++;
                if (i > 0)
                    peopleList.OldAge = 33;  //只枚举一次后，修改OldAge 的值
            }

测试结果是：

不修改OldAge参数
ID:2,NameP2,Age32
ID:3,NameP3,Age33
ID:4,NameP4,Age34

修改了OldAge参数
ID:2,NameP2,Age32
ID:4,NameP4,Age34

可以看到，在枚举过程中修改了控制枚举的值，能动态改变枚举的行为。上面是在一个yield结构中改变变量的情况，我们再试试在迭代器和Lambda表达式的情况：

            int age = 31;
            Console.WriteLine("在迭代中修改变量值");
            i = 0;
            IEnumerable<People> e4 = peopleList.PeopleEnumerable1.Where(d => d.Age > age);
            IEnumerator<People> e5 = e4.GetEnumerator();
            i = 0;
            while (e5.MoveNext())
            {
                Console.WriteLine(e5.Current);
                i++;
                if (i > 0)
                    age = 33;
            }


            age = 31;
            Console.WriteLine("在Lambda表达式中修改变量值");
            foreach (People b in e4)
            {
                Console.WriteLine(b);
                i++;
                if (i > 0)
                    age = 33;
            }

得到结果是：

在迭代中修改变量值
ID:2,NameP2,Age32
ID:4,NameP4,Age34
在Lambda表达式中修改变量值
ID:2,NameP2,Age32
ID:4,NameP4,Age34

可以看出，外部修改变量能够控制内部的迭代过程，动态改变了“集合的元素”。这是一个好事，因为它的行为确实是对的；也是坏事：它带来了陷阱，保存了一个枚举的引用，在迭代过程中，修改了变量的值，上下文语境变化，可是如果还按之前的语境进行处理，显然就会酿成大错。这件事以后深入讨论，比如ETL。这里和闭包没关系。

如果你把两个集合A,B用Concat函数顺次拼接起来，也就是A-B, 而且不实例化，那么在枚举A的阶段中，修改集合B的元素，会报错么？为什么？

这个答案绝对出乎你的想象！如果你想知道，可以自己做个试验（在我附件里也有这个例子）。留给大家讨论。

4. 更多LINQ的讨论

你可以在yield中插入任何代码，这就是延迟（Lazy）的表现，只是需要执行的时候才执行。我们不难想象Linq很多函数的实现方式，比较有意思的包括Concat,它将两个集合连在了一起，就像下面这样：

public static IEnumerable<T> Concat<T>(this IEnumerable<T> source, IEnumerable<T> source2)
       {
           foreach (var r in source)
           {
               yield return r;
           }
           foreach (var r in source2)
           {
               yield return r;
           }
       }

还有Select, Where都好实现，就不讨论了。

Skip怎么实现的呢？它跳过了集合中的一部分元素，我猜是这样的：

public static IEnumerable<T> Skip<T>(this IEnumerable<T> source, int count)
       {
           int t = 0;
           foreach (var r in source)
           {
               t++;
               if(t<=count)
                   continue;
               yield return r;
           }
       }

那么，被跳过的元素，到底被访问过没有？它的代码被执行了么？

 Console.WriteLine("Skip的元素是否会被访问到？");
 IEnumerable<People> e6 = peopleList.PeopleEnumerable1.Select(d =>
       {
              Console.WriteLine(d);
              return d;
       }).Skip(3);
 Console.WriteLine("只枚举，什么都不做：");
 foreach (var  r in e6){}  

 Console.WriteLine("转换为实体集合，再次枚举");
 IEnumerable<People> e7 = e6.ToList();
 foreach (var r in e7){}

测试结果如下：

只枚举，什么都不做：
ID:0,NameP0,Age30
ID:1,NameP1,Age31
ID:2,NameP2,Age32
ID:3,NameP3,Age33
ID:4,NameP4,Age34
转换为实体集合，再次枚举
ID:0,NameP0,Age30
ID:1,NameP1,Age31
ID:2,NameP2,Age32
ID:3,NameP3,Age33
ID:4,NameP4,Age34

可以看出，Skip虽然是跳过，但还是会“访问”元素的，因此会执行额外的操作，比如lambda表达式，这不论是枚举器还是实体集合都是如此。这个角度说，要优化表达式，应当尽可能在linq中早的Skip和Take，以减少额外的副作用。

对一般的大数据枚举下，Skip的意义并不大。但对于Linq to SQL的实现中，显然Skip是做过额外优化的。我们是否也能优化Skip的实现，使得上层尽可能提升海量数据下的Skip性能呢？

5. 有关IEnumerable枚举的更多问题

(1) 枚举过程如何暂停？有暂停这一说么？如何取消？

(2) PLinq的实现原理是什么？它改变的到底是IEnumerable接口的哪种特性？是否产生了乱序枚举？这种乱序枚举到底是怎么实现？

(3) IEnumerable实现了链条结构，这是Linq的基础，但这个链条的本质是什么？

(4) 因为IEnumerable代表了状态和延迟，因此就不难理解很多异步操作的本质就是IEnumerable。我有一次面试时候，问到了异步的实质，你说异步的实质是什么？异步不是多线程！异步的精彩，本质上是代码的重新组合，因为长时间的异步操作就是状态机。。。比如CCR库。此处不准备展开说，因为暂时超过了作者的知识储备，下次再说。

(5) 你可以将一个IEnumerable赋值到另外一个枚举上，那么两个枚举到底是不是一个东西呢？应该是一个，因为枚举接口显然是引用类型

(6) 如果用C语言来实现同样的枚举器，同样酷炫的Linq,不靠编译器能实现么？先不提Lambda的梗，我们用函数指针。

(7) IEnumerable写MapReduce? Linq for MapReduce?

(8) 函数式编程，闭包和IEnumerable？

(9) IEnumerable如何Sort? 实例化为一个集合再排序么？如果是一个超大的虚拟集合,如何优化？

下一篇我们详细讨论这些内容。附件是整个测试代码，如果你觉得有帮助，请帮忙点推荐，谢谢.

完整测试代码。

我的相似的一篇博文：你可能不知道的陷阱：C#委托和事件的困惑

6.参考文献：

CLR via C#

http://www.codeproject.com/Articles/34405/WPF-Data-Virtualization

可惜Java中没有yield return

如何设计一门语言（八）——异步编程和CPS变换

posted @ 2014-12-05 18:45 FerventDesert 阅读(15462) 评论(20) 编辑收藏举报

刷新页面返回顶部

沙漠之鹰

开发笔记，理解和思考