unity尧明的博客

虽然所有其他收集类型都没有改变它们产生的垃圾量，但至少它们使用的垃圾量都不比 Unity 5.2 中的垃圾量多。Dictionary、HashSet、LinkedList、Queue 和 Stack 现在在第一个循环上创建相同的 8 或 16 字节更少的垃圾，并在之后的任何循环上创建零垃圾。一年前，我写了一篇文章，标题为使用 Unity 5.2 进行 Foreach 循环创建垃圾，并使用各种集合测试了 foreach：列表、字典、数组等。所有代码和运行它的步骤仍然适用。

这很重要的原因是，在内部，String.Format() 实际上创建了一个 StringBuilder 并调用 StringBuilder.AppendFormat()！正如您所看到的，了解何时使用 String.Format 以及何时使用 StringBuilder.AppendFormat() 非常重要。而且，删除对 String.Format 的调用还可以提高性能。如果您试图避免通过使用 String.Format() 连接字符串来创建 StringBuilder，了解这一点也很重要。

在 .NET Core 中处理字符串时，您会经常使用的两个流行类是 String 和 StringBuilder 类。在使用这两个类构建最小化分配且高性能的应用程序时，您应该了解最佳实践。本文讨论在 C# 中使用字符串时可以遵循的最佳实践。

在这篇文章中，我们进行了理论练习，并进一步了解了 ReadOnlySequence 类型。我保留对我的“SequenceReader 简介”博文中评论的最初回答。我认为我所展示的代码对于所提出的实际问题来说并不是一个明智的选择。然而，我喜欢这样的问题，因为它让我意识到，我实际上并没有考虑过 ReadOnlySequence 是如何创建的。通过小样本的调查，我更多地了解了这种类型的行为方式，我认为这是值得投入的时间。我希望您发现阅读这篇文章同样有用或至少有趣！

可能值得首先解决这个问题，因为这是 .NET Core 中相当新的类型，并且您会遇到它的情况有限。不久前，添加了 Span 和 Memory 类型。它们都支持通过一致的 API 处理各种类型的连续内存区域。从那时起，许多新的构造都建立在这些类型提供的基础上。System.IO.Pipelines 就是一个这样的例子，它是一种用于处理 IO 的高性能 API。传统上，许多 IO 操作都使用流。流的一个问题是，它们让你负责管理缓冲区和在缓冲区之间复制数据。

大家好，我叫 Dmitrii Ivashchenko，是 MY.GAMES 的软件工程师。在本文中，我们将讨论 Unity 和 .NET 中垃圾收集之间的差异。C# 编程语言的主要优点之一是自动内存管理。它消除了开发人员手动释放未使用对象的内存的需要，并显着缩短了开发时间。然而，这也可能导致大量与内存泄漏和意外应用程序崩溃相关的问题。

在 .NET 领域，一个关键方面是有效的数据操作。当涉及到内存管理时，这种能力更加重要。Span、Memory 和 ReadOnlySequence 结构提供了用于优化数据管理的高级工具。这些结构不仅提供了高度的控制性和灵活性，而且还大大提高了运营效率。

Span（之前称为 Slice）是 C# 7.2 和 .NET Core 2.1 中引入的一种值类型，开销几乎为零。Span 类型表示驻留在托管堆、栈甚至非托管内存中的连续内存块。如果创建基本类型的数组，它将在栈上分配，并且不需要垃圾回收来管理其生命周期。Span 能够指向分配在栈或堆上的一块内存。但是，由于 Span 被定义为引用结构，因此它应该仅驻留在堆栈上。值类型低或零开销高性能提供内存和类型安全ArraysStringsArraysPointers。

今天我们来谈谈 Span，它已经被讨论了好几年了，因为它是随 C#7.2 引入的，并在 .NET Core 2.1 及更高版本的运行时中得到支持。在本文中，我们将通过一些示例来介绍如何使用 Span ，并讨论为什么在编写下一行代码时应该考虑使用它。

考虑到这些信息，很容易建议不要逐帧使用 LINQ，因为在大多数游戏中，GC 分配即使不是完全禁止，通常也应该保持在最低限度。在最糟糕的情况下，OrderBy 的分配量高达 0.5 KB，而 ToDictionary 的情况也差不多糟糕，分配了 434 字节。其中 10 个函数分配了不止一次，而其余 7 个函数只分配了一次。对于今天的测试，我们将使用每种方法的一个重载，以保持事情简单明了。然后，只需在 CPU 使用情况剖析器的层次结构视图的 GC 分配列和内存剖析器的每帧 GC 分配中记录帧即可。

很常见的是，有人问有关避免垃圾收集器的问题，但得到的答案却是“只需使用池”，就好像这立即完全解决了问题一样。虽然池通常会让垃圾收集器陷入困境，但它们也会带来一系列你必须处理的新问题。今天的文章将讨论其中的几个问题，以便您了解所涉及的权衡，并希望避免一些陷阱。

虽然我们只进入了第四章，但关于内存管理的各个方面，我们已经经历了相当长的旅程。对它们进行了一般性讨论，以便对该主题进行更具理论性的介绍。对 .NET 的具体引用非常罕见，毕竟这就是本书的主题。是时候改变这个频率了。从本章到本书结束，.NET 将一直伴随着我们。在本章中，我们将从更广泛的角度来看待它，我们将学习它背后的一些机制，并且我们将开始深入研究与它如何管理内存相关的主题。我强烈建议您在继续阅读本章之前先从前三章中获取知识，但将其视为一种可选方法。

Linux 的兴起和发展是开源社区无数贡献者的非凡创造。它并不是像 Windows 操作系统那样从一开始就由一家公司设计和实现。某些领域缺乏严格的标准化也就不足为奇了。其中一个方面是监控和跟踪我们特别感兴趣的应用程序。有许多可用的机制；其中一些正在慢慢失去人气，而另一些则刚刚开始流行。在这种情况下，Linux 中的监控基础设施变得不如 Windows 环境中的同质化。没有在所有发行版和系统内核中使用的广泛接受的诊断跟踪标准。将 CoreCLR 迁移到 Linux 环境时，必须决定使用什么机制。

从适用于 Windows 10 的 Windows Performance Toolkit 版本中，有一种方法可以根据事件负载绘制自己的图表。换句话说，我们可以绘制 Y 轴来自选定事件字段之一的图表。X 轴将自动成为事件的时间。唯一的要求是所选字段具有整数值。不幸的是，这个限制对我们来说非常不利。垃圾收集器领域中的绝大多数有趣事件均以十六进制格式给出。这适用于各种大小、内存使用等等。这使得该机制目前没有多大用处，我们根本不会使用它。

Windows监控和跟踪基础设施已经相当成熟，包括.NET环境的上下文。有两个主要可用组件：提供测量时间序列的指标驱动性能计数器和称为 Windows 事件跟踪 (ETW) 的事件驱动机制。这两个工具几乎涵盖了所有的监控和诊断需求。还有一个 Windows Management Instrumentation 机制，但它根本没有用于我们的目的（因为正如其名称所示，它更致力于管理和管理）。开发 .NET 时，所使用的诊断机制领域的选择是显而易见的。

Operating System（操作系统）  到目前为止，我们已经花了很多时间非常接近硬件。 我最初也答应看操作系统。 现在是这样做的最佳时机。 实际上，操作系统的设计者必须非常认真地对待所有先前仅简要介绍的事实。 正如您很快就会看到的那样，它仍然只是更广泛现实的一个片段。  由于操作系统和硬件架构的不同，物理内存限制从 2 GB 到 24 TB 不等。 现在典型的商品硬件配备了 4 到 8 GB 的内存。 如果给定的程序必须直接使用物理内存，它就需要管理它创建和删除的所有内存区域。 这样的内存管理逻

低级内存管理  要了解内存管理的工作原理，我们需要获得更广泛的背景知识。 在上一章中，我们了解了该主题的理论基础。 我们现在可以直接了解自动内存管理的细节、垃圾收集器的工作原理以及可能发生内存泄漏的位置。 但是，如果我们真的想“感受”这个话题，就值得多花一些时间来基本提醒这个话题的另一个方面。 这将使我们能够更好地理解垃圾收集器创建者在 .NET（以及其他托管运行时环境）中做出的各种设计决策。 这种机制的创造者并不是生活在真空中，而是必须适应存在的状态——支配计算机硬件和操作系统的限制和机制。 这就是我们

自动内存管理  为了克服手动内存管理的问题并为程序员提供更愉快的处理方式，已经提出了不同的自动内存管理方法。 有趣的是，与第二古老的高级编程语言 LISP 一样古老，大约在 1958 年提出（仅比 FORTRAN 晚几年），在该领域可以提供很多东西。 由于在很大程度上基于列表处理的主要函数式语言中 - 手动内存管理会非常不舒服。 函数式编程范式将程序视为对组合函数的评估，并强烈避免数据修改（突变）和副作用。 分配和释放内存是高度可变的并且有明显的副作用。 在函数式代码中以这种方式处理内存会使它充满命令式气

基本概念  让我们从一个简单但非常重要的问题开始。 如果 .NET 内存管理全部自动化，您什么时候应该关心它？ 你应该关心吗？ 正如您可能对我写了这样一本书所期望的那样——我强烈建议您记住每个开发人员处境中的内存。 这只是我们专业性的问题。 我们如何开展工作的结果。 我们是在努力做到最好还是只是制造？ 如果我们关注我们工作的质量，我们不应该只担心我们的工作只是工作。 我们应该担心它是如何工作的。 它在 CPU 和内存使用方面是否最佳？ 它是否可维护、可测试、为扩展而开放但为修改而关闭？ 我们的代码可靠吗？

  在计算机科学中，内存一直存在——从打孔卡到磁带，再到如今复杂的 DRAM 芯片。 它会一直存在，可能以科幻全息芯片的形式出现，或者甚至是我们现在无法想象的更神奇的事物。 当然，记忆在那里不是没有原因的。 众所周知，计算机程序被认为是结合在一起的算法和数据结构。 我非常喜欢这句话。 可能每个人都至少听说过 Niklaus Wirth（Prentice Hall，1976 年）写的 Algorithms + Data Structures = Programs 一书，这句名言就是出自于此。  从软件工程领