Chromium's documentation says:
NOTE: Both Singleton and base::LazyInstance provide "leaky" traits to leak the global on shutdown. This is often advisable (except potentially in library code where the code may be dynamically loaded into another process's address space or when data needs to be flushed on process shutdown) in order to not to slow down shutdown.
在哪种情况下可以接受？
最佳答案
“可接受”很难定义，因为我个人更喜欢避免这种做法。例如，我们使用泄漏检测工具，除非另外加以抑制，否则最终会在这种实践中显示出误报(尽管我在Chromium的文档中注意到其漏泄特征会抑制误报:我不这样做，并将误报警告视为可以解决的问题)而不是压制)。
自然，这仅在目标操作系统在关闭进程时回收单例所获取的资源时才可以接受。尽管大多数现代操作系统都是针对最常见的资源类型执行此操作。自然，如果您的单例创建了某种大规模的临时文件，明智的做法是使用明确的关机过程销毁它。
关机速度
提到的避免简单地手动回收资源以快速关闭资源的理由是合法的，但是它通常伴随着一种心态，即在最小的块中分配大量的内存。
当使用链接结构或针对通用分配器分别分配的许多抽象对象时，通常会发生这种情况。如果有数百万个小小的内存块要单独释放，那将转化为痛苦的停机时间，跨越数秒。
然而，启动，加载输入数据和关闭的速度往往相互之间非常相关。如果我们想加快它们的速度，则批量分配和缓冲内存可能会有所帮助。
通过这种大容量资源分配和池化策略，应用程序可以启动和关闭，并且总体上可以快速运行。这可能很难应用，但是如果您有此需要，即使加载了千兆字节的数据，应用程序通常也仍然可以立即关闭，并且可能只是泄漏资源似乎比优化技术更懒惰。并可能将其更多地推向“无法接受”的审美观。 YMMV。
但是，在实际需要性能的情况下，您可以做自己需要做的事情。我想象Chromium开发人员在设计泄漏检测器的泄漏特征和抑制器之前，对代码库进行了自然的构造。每个人都在考虑不同的情况。
关机正确性
在某些非常复杂的代码库中，很多插件在关机时都会被加载和卸载，例如，仅使该死的应用程序正确关闭实际上会非常困难。
我曾经看过一个代码库，在那里我们以这种方式努力工作，实际上有大量与应用程序在关机时崩溃有关的错误(最少的用户关键崩溃时间，但仍然非常烦人)。
对于我们来说，问题是加载插件时会创建单例和其他类型的全局变量，这些全局变量在创建时会触发外部状态(其他全局变量或其他位于不同模块中的单个实例)的副作用。在这些情况下，存在对称的愿望，即在销毁此类全局变量时扭转这些副作用(例如:如果构建全局变量，则从全局集合中删除)。这就引入了销毁顺序的问题(由于众多作者编写的分散代码以及分散在众多插件中的全局状态，在这里这非常困难)。
当销毁过程中全局变量开始依赖于其他全局变量(无论是否构造的)时，事情会变得很尴尬，只是确保以正确的顺序销毁事物，以使全局变量最终不会在关闭时依赖于另一个全局变量无效(甚至在卸载了dylib的情况下)。
几乎可以肯定，我们在那里做着各种各样的事情(从使用过多的单例和全局变量开始，并且以没有统一设计心态的即席方式将它们分散在各个插件之间)，这种经历使我不喜欢各种单例和全局变量。这类复杂的情况(不是为了降低灵活性，而是为了编写正确的关闭代码而带来的困难)，但是如果我们不花心思使这些全局变量与其他全局变量产生相反的副作用，可能会容易得多。在破坏时，只需将它们留在那儿，然后让操作系统清理资源即可。在那里，我可以理解只是泄漏而不去破坏事物的诱惑，或者即使我们确实破坏了事物，也不想将副作用扭转到其他全局变量上。对于非常错误的设计来说，这是一个丑陋的解决方法，但是与通过泄漏解决性能问题相比，我可以理解这种问题要容易一些。
无论如何，“可接受的”变化很大。范围从美学一直到便携性问题。这是我第一次遇到关于仅泄漏单例泄漏的效率争论，但是我可以理解是哪种情况导致了这种情况。
关于c++ - 优先考虑内存泄漏，以免减慢关机速度，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34397839/