之后忽然想到了这个话题：你愿意相信机器，还是人

（一）

春节的时候，陪老爸去配了一副眼镜。

因为前不久我也正好花重金配了一副，在之前做了很多的功课，诸如眼镜的前倾角、面弯、镜间距、单眼瞳高、单眼瞳距之类的知识，了解了一些配镜过程中应该注意的事项。

老家是一个小县城，虽然眼镜店遍地都是，但专业的还真没几个。在配镜的过程中，能注意到这些细节的眼镜店几乎没有。蔡司专业的三维定位的仪器，更是全县城都没有。

当我提出需要仪器辅助测量这些参数的时候，一个配镜师傅跟我说，他们可以用最原始的方法，通过手动测量来得出这些值。

我的犹豫引起了他的反感，他说，如果你只相信这些参数，那么就没法配这个系列了。

我相信我们县城有很厉害的师傅，可以通过手动测量和计算得出这些参数。但是我不相信在茫茫人海中，我能有幸遇到这个师傅。

蔡司的专业设备是投入大量的人力物力研发的，而且我相信研发这些设备的工程师的能力也不低。所以这样的设备，他的上限和下限都极其逼近于其平均水平。我们可以期待他有一个稳定且正常的发挥。

一个专业的配镜师傅，他的上限和下限是相差极大的。智者千虑必有一失，愚者千虑必有一得。但这个师傅的稳定水平，可能会收到很多因素的影响，包括但不限于：今天天气怎么样、出门的时候是否跟老婆吵架了、甚至都不能期待他的发挥是他的平均水平。

但同样还是人，如果是研发蔡司的设备的眼光配镜的师傅，我可能会更相信于这个人。因为我知道，他有超出这个设备的能力。

（二）

最近十年，去银行柜台的次数，基本上一只手数得过来。

十年前，存钱、取钱，大部分还是要去柜台。虽然有ATM机，但是存钱的时候的识别率并不高，去柜台的效率高于ATM机。

十年后，纸币在日常生活里的作用逐渐的弱化。微信、支付宝的流行，甚至让市井小偷都面临职业危机。

会想最近一次去银行柜台，感觉偌大的银行大厅甚至有些冷清。而且，在柜台，也没有看到存取钱的客户。

之前有新闻说要取消高速公路口处的收费人员，全部采用类似ETC的方式来代替。大概也是这样吧。

（三）

这几年网购东西，越来越少的去咨询客服了。因为我知道， 对面大概率也是一个机器人，回复一些正确且无用的答案。

刚开始网购的时候，互联网的测评并不流行，产品页的描述提供的信息可未必详细。想知道一个参数，跟客服沟通会是一个最佳的选择。

那时候的客服也很热情，会有一种类似线下购物的交流感。

如今，评测剧透，甚至优先于产品发布。你对产品的了解，甚至多过对面的人工客服。

此刻的你，可能既不需要人，也不需要机器。

缓存穿透

是啥

当请求试图访问一个在缓存和数据库都不存在的 key时，因为缓存没有，所以请求会直接转发到数据库上。然而数据库里面也没有这个 key 的记录，所以也就没有办法将这个数据写入缓存。当下一次同样的请求来了的时候，还是会转发到数据库上。

在这种情况下，缓存基本上也就没用了，就像被穿透了一样，请求每次都会走到数据库，流量大时数据库可能会扛不住。

咋整

1. 对请求进行校验。一些明显不合理的参数直接前端过滤掉就好了，就不要让他进来了。
2. 将空值缓存起来。查完之后，即使数据库没有这条记录，也把这个 key 和没有记录的情况缓存起来，这样下次就不会再查数据库了。
3. 布隆过滤器。挺有意思的一个东西，值得单独讲讲。

布隆过滤器

介绍

布隆过滤器是一种概率型的数据结构，它可以告诉你某条记录一定不存在或者有可能存在。

正常我们考虑一个东西是否存在的判断的时候，大家下意识的反应可能会是哈希。但是哈希需要保存所有的对象，以便后续哈希冲突的时候找到特定的值。所以这也导致了哈希对大量数据的时候，内存是非常大的。

所以就有个小天才，尝试我们用多个哈希，来讲存在变成一个概率性的事情：

比如说：

• 我们初始化一个值为0，容量为10的数组：[0, 0, 0, 0, 0, 0, 0, 0, 0, 0] 然后设定两个不同的哈希方法：
• 哈希1 => %5
• 哈希2 => %7

现在，我们要存放 25 这个值，我们来看一下： 25：哈希1得到0，我们将0这个下标对应的值标记成1；哈希2得到4，我们将4这个下标对应的值修改成1；此时数组为：[1, 0, 0, 0, 1, 0, 0, 0, 0, 0]

当我们尝试获取25的时候，我们还是按照哈希1和哈希2，取得对应的下标，然后获取下标对应的值。如果下标的值一旦有0值，那么我们就认为这条记录是不存在的，但即便是都是1，也不一定百分百存在，为什么呢？

假设说我们现在要存 60 这个值，哈希1返回下标0，哈希2返回下标4，跟25是一样的结果。所以0和4的下标都是1的时候，可能是25带来的，也可以能是60带来的，这并不能确定，只能说，有概率存在。

但这个种并不是很精准筛查，在某些条件下，已经可以帮我们解决很大程度上的问题了。

哈希函数个数和布隆过滤器长度

布隆过滤器长度越长，误报概率越小。 哈希函数越多，一个值写的1也越多。

经典应用

用布隆过滤器减少磁盘 IO 和网络请求。

缓存击穿

是啥

某一热门的 key，在它过期的一瞬间，突然来了对它的好多请求。因为缓存已经过期了，所以这些请求就都转到了数据库，那个可怜的数据库又扛不住了。

咋整

1. 加互斥锁。比如 Redis 分布式锁。
2. 设置热点数据不过期。

缓存雪崩

是啥

大量热点 key 设置了相同的过期时间，在他们过期的一瞬间，出现了大量的请求，然后那个数据库应该更扛不住了。可以简单的理解，缓存击穿时一个 key，缓存雪崩是一堆 key。

咋整

基本上跟缓存击穿一样，无法时加了一个打散过期时间来处理一组的问题。

1. 打散过期时间
2. 加互斥锁
3. 热点数据不过期

托管代码就是执行过程交由运行时管理的代码。运行时一般是指 CLR，公共语言运行时。

CLR 负责提取托管代码、将其编译成机器代码，然后执行它。除此之外，运行时还负责自动内存管理、安全边界、类型安全等等。

如果在 .Net 里面直接调用 C/C++ 程序，此类代码也称为“非托管代码”。在非托管代码的环境中，操作系统将程序加载进内存，然后调用内部的二进制代码，所以从内存管理到安全等诸多因素都需要程序员自己处理。

正常使用 .Net 编写的代码，会先编译成中间语言 （IL）。执行的时候，CLR 会接管编译后的 IL，然后通过实时编译（JIT）将 IL 编译成可以在CPU上执行的机器码。这样 CLR 就能知道代码的确切作用，并管理代码。

分配内存

初始化新进程时，运行时会为进程创建托管堆。

托管堆是一个连续的地址空间区域，托管堆内维护着一个指针，用它指向将在堆中分配的下一个对象的地址。最初的时候，该指针指向托管堆的基址。

当应用程序创建第一个引用类型时，将为托管堆的基址中的类型分配内存。 应用程序创建下一个对象时，垃圾回收器在紧接第一个对象后面的地址空间内为它分配内存。 只要地址空间可用，垃圾回收器就会继续以这种方式为新对象分配空间。

严格来说，必须在托管堆上分配所有非 null 引用类型对象和所有装箱值类型对象。

从托管堆中分配内存要比非托管内存分配速度快。 由于运行时通过为指针添加值来为对象分配内存，所以这几乎和从堆栈中分配内存一样快。 另外，由于连续分配的新对象在托管堆中是连续存储，所以应用程序可以快速访问这些对象。

释放内存

垃圾回收器的优化引擎根据所执行的分配决定执行回收的最佳时间。

每个应用程序都有一组根。每个根或者指向托管堆中的对象，或者为空。 应用程序的根包含线程堆栈上的静态字段、局部变量和参数以及 CPU 寄存器。

垃圾回收器可以访问由实时 (JIT) 编译器和运行时维护的活动根的列表。垃圾回收器对照此根列表检查应用程序的根，并在此过程中创建一个图表，在其中包含所有可从这些根中访问的对象。

如果有一个对象，不在上面创建的图表中，那意味着这个对象将无法从应用程序的根中访问。这个时候，垃圾回收器就可以考虑释放为它们分配的内存。

回收的时候，垃圾回收器会检查托管堆，查找无法访问的对象所占据的地址块。当发现无法访问的对象的时候，GC 会通过内存复制的方法来压缩内存中可以访问的对象，并释放分配给不可访问对象的地址空间块。在压缩可访问的对象之后，GC 会更正原来指向这个对象的指针，使应用程序的根指向新地址中的对象。在 GC 完成之后，会将托管堆指针指向最后一个可访问的对象。

只有在发现了大量无法访问的对象的时候，才会压缩内存。

托管堆的级别和性能

为了提高 GC 的性能，托管堆被划分为3代：第0代、第1代和第2代。

划分不同代的依据：

1. 压缩托管堆的一部分内存比压缩整个托管堆速度快
2. 较新的对象生存期较短，较旧的对象生存期较长
3. 较新的对象趋向于互相关联，并且大致同时由应用程序访问

新创建的对象储存在第0代。在第0代满了的时候，GC 会执行回收，尝试释放第0代中的地址空间。在第0代的回收执行之后，GC 会将第0代的内存对象升级到第1代。

如果第0代托管堆的回收没有回收足够的内存，不能使应用程序成功完成创建新对象的尝试，垃圾回收器就会先执行第1代托管堆的回收，然后再执行第2代托管堆的回收。如果这样仍不能回收足够的内存，垃圾回收器将执行第2、1 和 0 代托管堆的回收。

每次回收后，垃圾回收器都会压缩第0代托管堆中的可访问对象并将它们升级至第1代托管堆。 第1代托管堆中未被回收的对象将会升级至第2代托管堆。 由于垃圾回收器只支持三个级别，因此第2代托管堆中未被回收的对象会继续保留在第2代托管堆中，直到在将来的回收中确定它们为无法访问为止。

如果新创建的对象是大型对象，它们将延续到大型对象堆 (LOH)，这有时称为第 3 代。 第 3 代是在第 2 代中逻辑收集的物理生成。

非托管资源的内存释放

非托管资源需要显式清除。

最常用的非托管资源类型是包装操作系统资源的对象（例如文件句柄、窗口句柄或网络连接）。GC 可以跟踪封装非托管资源的托管对象的生存期，但却无法具体了解如何清理资源。

创建封装非托管资源的对象时，建议在公共 Dispose 方法中提供必要的代码以清理非托管资源。 通过提供 Dispose 方法，对象的用户可以在使用完对象后显式释放其内存。 使用封装非托管资源的对象时，应该了解 Dispose 并在必要时调用它。

还必须提供一种释放非托管资源的方法，以防类型使用者忘记调用 Dispose。 可以使用安全句柄来包装非托管资源，也可以重写 Object.Finalize() 方法。

内存的基本知识

• 每个进程都有其单独的虚拟地址空间
• 同一台计算机上的所有进程共享相同的物理内存和页文件（如果有）
• 默认情况下，32位计算机上的每个进程都具有 2 GB的用户模式虚拟地址空间
• 程序开发人员，默认只能使用虚拟地址空间。GC 会为你分配和释放托管堆上的虚拟内存
• 虚拟内存的三种状态：
  • Free：该内存块没有引用关系，可用于分配
  • Reserved：给你用，其他人不能用。但是在提交之前，无法存储数据
  • Committed：内存块已指派给物理存储
• 如果没有足够的可供保留的虚拟地址空间或可供提交的物理空间，则可能会用尽内存
• 托管堆可以看做大对象推和小对象堆的集合
• 大对象堆包含大小不小于 85,000 个字节的对象，这些对象通常是数组。 非常大的实例对象是很少见的。（可以配置阈值大小）

即使在物理内存压力（即物理内存的需求）较低的情况下也会使用页文件。 首次出现物理内存压力较高的情况时，操作系统必须在物理内存中腾出空间来存储数据，并将物理内存中的部分数据备份到页文件中。 该数据只会在需要时进行分页，所以在物理内存压力较低的情况下也可能会进行分页。

垃圾回收的过程

垃圾回收分为以下几个阶段：

• 标记阶段：找到并创建所有活动对象的列表。
• 重定位阶段：用于更新对将要压缩的对象的引用。
• 压缩阶段：用于回收由死对象占用的空间，并压缩幸存的对象。 压缩阶段将垃圾回收中幸存下来的对象移至段中时间较早的一端。

因为第 2 代回收可以占用多个段，所以可以将已提升到第 2 代中的对象移动到时间较早的段中。 可以将第 1 代幸存者和第 2 代幸存者都移动到不同的段，因为它们已被提升到第 2 代。

通常，由于复制大型对象会造成性能代偿，因此不会压缩大型对象堆 (LOH)。 但是，在 .NET Core 和 .NET Framework 4.5.1 及更高版本中，可以根据需要使用 GCSettings.LargeObjectHeapCompactionMode 属性按需压缩大型对象堆。

确定活动对象

垃圾回收器使用以下信息来确定对象是否为活动对象：

• 堆栈根。 由实时 (JIT) 编译器和堆栈查看器提供的堆栈变量。 JIT 优化可以延长或缩短报告给垃圾回收器的堆栈变量内的代码的区域。
• 垃圾回收句柄。 指向托管对象且可由用户代码或公共语言运行时分配的句柄。
• 静态数据。 应用程序域中可能引用其他对象的静态对象。 每个应用程序域都会跟踪其静态对象。

挂起

在垃圾回收启动之前，除了触发垃圾回收的线程以外的所有托管线程均会挂起。

//todo 内存虚拟地址和物理地址的转换过程

题目

Consider n packages, where packageWeights[i] represents the weight of the i th package, You can combine i th and i+1 th package if packageWeights[i] <packageWeights[i+1] and then discard the i th package. After this operation number of packages reduces by 1 and weight of i+1 th package increases by packageWeights[i]. You can merge as many times as you want. Find the max possible weight of the package that can be achieved after any sequence of merge operations

Eg packageWeights =[2,9,10,3, 7] optimal order:

• iteration 1 combine packages at index 2 and 3 ->new packageWeights =[2,19,3,7]
• iteration 2 combine packages at index 1 and 2 ->new packageWeights =[21,3,7]
• iteration 3 combine packages at index 2 and 3 ->new packageWeights =[21,10]
• No more packages can be combined. The weight of the heaviest package is 21 Result:21

分析

其实例子中给出来的分析已经足够。在理解这个问题的时候，可以直接尝试着用程序化的语言来理解，比如：

1. packageWeights =[2,9,10,3, 7]; var max = 0;
2. var index = 4; value = 7; current = 7; max = 7;
3. index = 3; value = 3; value < current; current = 7 + 3; max = 10;
4. index = 2; value = 10; value !< current; current = value(10); max = 10;
5. index = 1; value = 9; value < current; current = 10 + 9; max = 19;
6. index = 0; value = 2; value < current; current = 19 + 2; max = 21;
7. return max;

代码

var packageCount = packageWeights.Length;
var max = 0;
if (packageCount == 0) { return max; }

var current = packageWeights[^1];
for (int index = packageCount - 1; index >= 0; index--)
{
    var value = packageWeights[index];
    current = value < current
        ? current + value
        : value;
    max = Math.Max(max, current);
}

return max;

有没有发现，在上一步中，当你用程序化的思维去理解这个问题的时候，编程就成了一种自然而然的语言转换了。 时间复杂度：O(n) 空间复杂度：O(1)

测试案例

如果你是在面对面的跟面试官沟通的话，往往面试官会问你要怎么设计测试用例。 其实这个也是考察你对编码的严谨性的。

本题的测试案例可以这样逐步来想：

1. 只有一条重量数据：[TestCase(new[] { 2 }, ExpectedResult = 2)]
   1. 增加一个大重量的包在前面：[TestCase(new[] { 10, 2 }, ExpectedResult = 10)]
      1. 增加一个相同重量的包在前面：[TestCase(new[] { 10, 10, 2 }, ExpectedResult = 10)]
      2. 增加一个相同重量的包在后面：[TestCase(new[] { 10, 2, 2 }, ExpectedResult = 10)]
   2. 增加一个大重量的包在后面：[TestCase(new[] { 2, 10 }, ExpectedResult = 12)]
2. 合并之后有两个包：[TestCase(new[] { 2, 9, 10, 3, 7 }, ExpectedResult = 21)]
3. 合并之后只有一个包：[TestCase(new[] { 2, 9, 10, 3, 8 }, ExpectedResult = 32)]

发布-订阅模式

有些时候，发布-订阅模式也会被称为观察者模式，但其实，如果细分的话，这两者之间还是有些细微的差别的。

观察者模式是在主题者（Subject）内部，维护一个观察者（Observer）列表。然后当主题者的状态发生变更的时候，主题者可以通知观察者发生了变化。观察者可以主动访问主题者，获得变更。也可以在通知观察者的时候，直接带上变更的消息。

在观察者模式中，主题者和观察者还是存在部分的耦合。因此，我们可以引入一个中介，来接触这种耦合。

类 A（发布者）发生了变化，将这个变化以消息或者事件的形式，发送给中介类，然后中介类将这个消息，转发给订阅这个消息的类 B（订阅者），这样发布者和订阅者并不直接产生依赖，他们都仅依赖于中介类（这个类可以是一个消息队列，也可以是你自定义的一个类型）。

代码

发布者基类：

public class EventPublisher  
{  
    private CustomEventHub EventHub { get; }  

    public EventPublisher()  
    {
        EventHub = CustomEventHub.GetInstance();  
    }  

    public void PublishEvent<T>(EventType eventType, T value)  
    {
        EventHub.Publish(new CustomEvent { Type = eventType, Value = value});  
    }
}

订阅者基类：

public class EventSubscriber
{
    private CustomEventHub EventHub { get; }

    public EventSubscriber()
    {
        EventHub = CustomEventHub.GetInstance();
    }

    public void Subscribe(EventType eventType, Action<CustomEvent> action)
    {
        EventHub.AddSubscriber(eventType, action);
    }
}

中介类：（为保证只有一个，这里额外加入了单例模式）

public class CustomEventHub
{
    private static readonly CustomEventHub Instance = new();
    private readonly Dictionary<EventType, IList<Action<CustomEvent>>> _eventTypeAndSubscribers = new();

    public static CustomEventHub GetInstance() => Instance;

    private CustomEventHub() { }

    public void Publish(CustomEvent customEvent)
    {
        var eventType = customEvent.Type;
        if (!_eventTypeAndSubscribers.ContainsKey(eventType)) { return; }

        var subscribers = _eventTypeAndSubscribers[eventType];
        foreach (var subscriberAction in subscribers)
        {
            subscriberAction.Invoke(customEvent);
        }
    }

    public void AddSubscriber(EventType eventType, Action<CustomEvent> action)
    {
        if (_eventTypeAndSubscribers.ContainsKey(eventType))
        {
            _eventTypeAndSubscribers[eventType].Add(action);
        }
        else
        {
            _eventTypeAndSubscribers.Add(eventType, new List<Action<CustomEvent>> { action });
        }
    }
}

自定义事件：

public class CustomEvent
{
    public EventType Type { get; set; }
    public object Value { get; set; }
}

事件类型：

public enum EventType
{
    TimeChanged
}

实际应用

时间变化时，发出事件通知：

public class TimeProvider : EventPublisher
{
    private Timer _timer = null!;

    public double Interval { get; set; }
    public DateTime CurrentTime { get; set; }

    public void Init()
    {
        CurrentTime = new DateTime(1900, 1, 1);
        _timer = new Timer(Interval)
        {
            AutoReset = true
        };
        _timer.Elapsed += OnTimeChanged;
    }

    private void OnTimeChanged(object? sender, ElapsedEventArgs e)
    {
        Console.Write($"TimeChanged From {CurrentTime :HH:mm:ss}");
        CurrentTime = CurrentTime.Add(TimeSpan.FromMilliseconds(Interval));
        Console.WriteLine($" To {CurrentTime :HH:mm:ss}");
        PublishEvent(EventType.TimeChanged, CurrentTime);
    }

    public void Start()
    {
        _timer.Enabled = true;
        GC.KeepAlive(_timer);
    }

    public void Stop()
    {
        _timer.Enabled = false;
    }
}

收到时间变化的事件后，打印一个“Hello World”：

public class SimulatorSystem : EventSubscriber
{
    private CustomEventHub _eventHub;

    public void Init()
    {
        Subscribe(EventType.TimeChanged, OnTimeChanged);
    }

    private void OnTimeChanged(CustomEvent customEvent)
    {
        if (customEvent.Type != EventType.TimeChanged) { throw new ArgumentException("Invalid event type"); }
        Console.WriteLine("Hello World");
    }
}

Documnet：

1. https://www.diskgenius.cn/exp/about-4k-alignment.php
2. https://study.qqcf.com/web/445/73426.htm

扇区

扇区的概念来自于物理硬盘，扇区是硬盘最小的物理存储单元。

之前的硬盘比较小，扇区的大小是512B。后来硬盘容量变大了，扇区的大小变成了4K。

但是为了兼容以前的系统读写，又发明了一个逻辑扇区的概念。 所谓的逻辑扇区就是硬盘内部，将4K的物理扇区在逻辑上划分为多个扇区片段，并将其作为普通的扇区（一般为512字节大小）报告给操作系统及应用软件。实际读写时，由硬盘内的程序（固件）负责在逻辑扇区与物理扇区之间进行转换，上层程序“感觉”不到物理扇区的存在。

所以逻辑扇区是一个人为制造的概念，在操作系统要读写某个逻辑扇区时，硬盘底层在实际操作时都会读写逻辑扇区所在的整个物理扇区。

簇

文件系统是操作系统和硬盘之间的接口。当我们需要读取一个文件的时候，会请求相应的文件系统打开一个文件。但是操作系统无法对数目众多的扇区（逻辑扇区）进行寻址，所以操作系统就会将相邻的扇区组合在一起，形成一个簇（Cluster）。

而且操作系统为了更好地管理磁盘空间和更高效地从硬盘读取数据，规定一个簇中只能放置一个文件的内容。因此文件所占用的空间，只能是簇的整数倍。

==即使文件实际大小小于一个簇的大小，它也要占一个簇的空间==。

所以，一般情况下文件所占空间要略大于文件的实际大小，只有在少数情况下，即文件的实际大小恰好是簇的整数倍时，文件的实际大小才会与所占空间完全一致。

计算文件所占空间时，可以用如下公式：

簇数=取整(文件大小/簇大小)+1 所占空间=簇数×磁盘簇大小

分区和格式化

分区是指从磁盘上划分出来的一大片连续的扇区。

格式化则是对分区范围内扇区的使用进行规划。 比如文件数据的储存如何安排、文件属性储存在哪里、目录结构如何存储等等。

格式化程序会将分区里面的所有扇区从头至尾进行分组，划分为固定大小的“簇”，并按顺序进行编号。每个“簇”可固定包含一个或多个扇区，其扇区个数总是2的n次方。格式化以后，分区就会以“簇”为最小单位进行读写。文件的数据、属性等等信息都要保存到“簇”里面。

分区对齐

划分分区时，是以逻辑扇区为单位进行划分的，分区可以从任意编号的逻辑扇区开始。

如果分区的起始位置没有对齐到某个物理扇区的边缘，格式化后，所有的“簇”也将无法对齐到物理扇区的边缘。

如下图所示，每个物理扇区由4个逻辑扇区组成。分区是从3号扇区开始的。格式化后，每个簇占用了4个扇区，这些簇都没有对齐到物理扇区的边缘，也就是说，每个簇都跨越了2个物理扇区。

由于磁盘总是以物理扇区为单位进行读写，在这样的分区情况下，当要读取某个簇时，实际上总是需要多读取一个物理扇区的数据。比如要读取0号簇共4个逻辑扇区的数据，磁盘实际执行时，必须要读取0号和1号两个物理扇区共8个逻辑扇区的数据。同理，对“簇”的写入操作也是这样。显而易见，这样会造成读写性能的严重下降。

下面再看对齐的情况。如下图所示，分区从4号扇区开始，刚好对齐到了物理扇区1的边缘，格式化后，每个簇同样占用了4个扇区，而且这些簇都对齐到了物理扇区的边缘。

在这样对齐的情况下，当要读取某个簇，磁盘实际执行时并不需要额外读取任何扇区，可以充分发挥磁盘的读写性能。显然这正是我们需要的。

由此可见，对于物理扇区大小与逻辑扇区大小不一致的磁盘，分区4K对齐才能充分发挥磁盘的读写性能。而不对齐就会造成磁盘读写性能的下降。

yield return

理解及应用

yield就是生成了一个值之后，控制回到了调用方继续执行，执行完成后，需要下一个值的时候，会重新回到yield return之后的语句处，继续执行。

结合下面的程序，理解了这点之后，跟yield相关的知识基本就都了解了。

代码：

public static void Main()
{
    var testClass = new TestClass();
    Console.WriteLine("[Main] BeginTest");
    foreach (var value in testClass)
    {
        Console.WriteLine($"[Main] Got Value {value}");  
        Console.WriteLine("[Main] Do some logic here");  
        Console.WriteLine("[Main] Try to get next value");  
    }
}

public class TestClass : IEnumerable<int>  
{  
    public IEnumerator<int> GetEnumerator()  
    {        
        Console.WriteLine("[Class] Begin Generate");  
        for (var index = 0; index < 3; index++)  
        {   
            Console.WriteLine($"[Class] Generate {index}");  
            yield return index;  
            Console.WriteLine($"[Class] Finished send {index}");  
        }  
        Console.WriteLine("[Class] Finished Generate");  
    }  

    IEnumerator IEnumerable.GetEnumerator()  
    {   
        return GetEnumerator();  
    }
}

程序执行日志：

[Main] BeginTest
[Class] Begin Generate
[Class] Generate 0
[Main] Got Value 0
[Main] Do some logic here
[Main] Try to get next value
[Class] Finished send 0
[Class] Generate 1
[Main] Got Value 1
[Main] Do some logic here
[Main] Try to get next value
[Class] Finished send 1
[Class] Generate 2
[Main] Got Value 2
[Main] Do some logic here
[Main] Try to get next value
[Class] Finished send 2
[Class] Finished Generate

递归迭代器

代码：

public static void Main()  
{  
    var testClass = new TestClass();  
    testClass.Value = 1;  
    testClass.SubClasses = new List<TestClass>  
    {   
        new()  
        {   
            Value = 2,  
            SubClasses = new List<TestClass>  
            {   
                new() { Value = 3 },  
                new() { Value = 4 }  
            }
        },
        new() { Value = 5 }  
    };  
    foreach (var item in testClass)  
    {
        Console.WriteLine(item);  
    }
}

public class TestClass : IEnumerable<int>  
{  
    public IList<TestClass> SubClasses { get; set; }  
    public int Value { get; set; }  
    public IEnumerator<int> GetEnumerator()  
    {        
        yield return Value;  

        if (SubClasses is not { Count: > 0 }) { yield break; }  

        foreach (var subClass in SubClasses)  
        {            
            foreach (var item in subClass)  
            {    
                yield return item;  
            }
        }
    }  

    IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();  
}

程序执行日志：

1
2
3
4
5

注意

递归迭代器存在一定的风险，如果是不平衡二叉树的话，可能会很深，获取值的时候的递归迭代的成本较高。

原理

C# 编译器在遇到迭代器的时候，会根据枚举数模式（Iterator Pattern）将代码展开成CLI。

在生成的代码中，C# 编译器会首先创建一个嵌套的私有类来实现 IEnumerator<T> 接口，以及它的 Current 属性和 MoveNext() 方法。

Current 属性返回与迭代器的返回类型对应的一个类型。

C# 编译器检查包含在迭代器中的代码，并在 MoveNext() 方法和 Current 属性中创建必要的代码来模拟它的行为。

yield break

取消更多的迭代

注意

1. yield 语句只能在方法、用户自定义操作符、或者索引器或属性的 get 防蚊器方法中出现。成员不可以获取任何 ref 或 out 参数
2. yield 语句不能在匿名语句或者 lambda 方法中出现
3. yield 语句不能在 try 语句的 catch 和 final 子句中出现。除此之外，yield 语句能在 try 块中出现的前提是，它没有 catch 块