Java堆分配比C ++更快

我已经在SO上发布了这个问题，它的确可以。不幸的是它关闭了（只需要一票就可以重新打开），但是有人建议我将它发布在这里，因为它更合适，因此以下内容实际上是该问题的粘贴内容

我正在阅读对此答案的评论，并且看到了这句话。

对象实例化和面向对象功能使用起来非常快（在许多情况下，它们比C ++更快），因为它们是从一开始就设计的。且收集速度很快。即使在大多数优化的C代码方面，标准Java在这一领域也优于标准C / C ++。

一位用户（我可能会添加非常高的代表）大胆地捍卫了这一主张，并指出

1. Java中的堆分配比C ++更好

2. 并添加了该语句来捍卫Java中的集合

   与Java集合相比，Java集合与C ++集合相比速度更快，这在很大程度上归因于内存子系统的不同。

所以我的问题是，这是否真的是真的，如果是的话，为什么Java的堆分配这么快？

这是一个有趣的问题，答案很复杂。

总体而言，我认为可以说JVM垃圾收集器的设计非常好并且非常高效。它可能是最好的通用内存管理系统。

C ++可以通过专门用于特定目的的专用内存分配器来击败JVM 。例如：

• 每帧内存分配器，可定期擦除整个内存区域。这些在C ++游戏中经常使用，例如，每帧使用一个临时存储区域并立即丢弃该区域。
• 自定义分配器，用于管理固定大小的对象池
• 基于堆栈的分配（尽管请注意，JVM在各种情况下也会执行此操作，例如通过转义分析）

当然，专用内存分配器受定义的限制。它们通常对对象生命周期有限制，并且/或者对可以管理的对象类型有限制。垃圾收集更加灵活。

从性能的角度来看，垃圾回收还为您提供了一些重要的优势：

• 对象实例化确实非常快。由于在内存中顺序分配新对象的方式，通常只需要添加一个指针即可，这肯定比典型的C ++堆分配算法快。
• 您避免了生命周期管理成本的需要 -例如，从性能的角度来看，引用计数（有时用作GC的替代方法）非常差，因为频繁增加和减少引用计数会增加很多性能开销（通常比GC多得多） 。
• 如果使用不可变对象，则可以利用结构共享来节省内存并提高缓存效率。JVM上的功能语言（例如Scala和Clojure）大量使用此功能。没有GC就很难做到这一点，因为管理共享对象的生存期非常困难。如果您像我一样相信不变性和结构共享是构建大型并发应用程序的关键，那么可以说这就是GC的最大性能优势。
• 如果所有类型的对象及其各自的生命周期都由同一垃圾收集系统管理，则可以避免复制。与C ++相反，在C ++中，由于目标需要不同的内存管理方法或对象生命周期不同，因此您通常必须获取完整的数据副本。

Java GC的主要缺点之一是：由于垃圾收集工作被推迟并按一定的时间间隔在大量工作中完成，因此它会导致GC偶尔暂停以收集垃圾，这可能会影响延迟。对于典型的应用程序，这通常不是问题，但是在需要硬实时的情况下（例如，机器人控制），可以排除Java 。软实时（例如游戏，多媒体）通常可以。

这不是科学依据。在这个问题上，我只是想一想。

一个视觉类比是：给您一个铺有地毯的公寓（一个住宅单元）。地毯很脏。什么是最快的方式（以小时为单位），以使公寓的地板闪闪发光？

答：简单地把旧地毯卷起来；丢弃; 然后铺开新地毯。

我们在这里忽略了什么？

• 搬出现有个人物品然后搬入的费用。
  • 这被称为垃圾收集的“世界停止”成本。
• 新地毯的成本。
  • 巧合的是，对于RAM，它是免费的。

垃圾回收是一个巨大的话题，在Programmers.SE和StackOverflow中都存在很多问题。

从侧面讲，一个称为TCMalloc的C / C ++分配管理器与对象引用计数一起在理论上能够满足任何GC系统的最佳性能要求。

主要原因是，当您向Java请求新的内存块时，它会直接到达堆的末尾并为您提供一个块。通过这种方式，内存分配与在堆栈上的分配一样快（这是您大多数时候在C / C ++中执行的方式，但是除此之外。）

因此分配的速度很快，但是...这还不算释放内存的成本。仅仅因为您直到很晚才释放任何东西，并不意味着它不会花费很多，就GC系统而言，其花费比“正常”堆分配要多得多-不仅GC必须遍历所有对象以查看它们是否仍然存在，然后还必须释放它们，并且（花费较大）复制内存以压缩堆-因此您可以在最后进行快速分配机制（否则您将耗尽内存，例如C / C ++将在每次分配时遍历堆，以寻找下一个可以容纳该对象的可用空间块）。

这就是Java / .NET基准测试表现出如此出色的性能，而实际应用程序却表现出如此糟糕的性能的原因之一。我只需要看看我的手机上的应用程序-的真快，反应灵敏的有所有书面使用NDK，以至于即使我很惊讶。

如果所有对象都是本地分配的，例如在一个连续的块中，那么如今的收集可能会很快。现在，在Java中，您根本就不会获得连续的块，因为从堆的自由端开始一次分配一个对象。您可以使它们愉快地连续，但只能靠运气（例如，紧随GC压缩例程及其复制对象的方式）。另一方面，C / C ++明确支持连续分配（显然是通过堆栈）。通常，C / C ++中的堆对象与Java的BTW没有什么不同。

现在，使用C / C ++，您可以得到比旨在节省内存并有效使用内存的默认分配器更好的功能。您可以用一组固定块池替换分配器，因此您始终可以找到与要分配的对象大小正好合适的块。遍历堆只是查看位图以查看空闲块在哪里的问题，而解除分配只是在该位图中重新设置位。代价是您在固定大小的块中分配时使用了更多的内存，因此，您有一个4字节块的堆，另一个为16字节块的堆，等等。

伊甸园空间

所以我的问题是，这是否真的是真的，如果是的话，为什么Java的堆分配这么快？

我一直在研究Java GC的工作方式，因为这对我来说很有趣。我一直在尝试用C和C ++扩展我的内存分配策略集合（有兴趣尝试在C中实现类似的东西），这是一种非常快速的方法，可以从内存中以突发方式分配很多对象。实用的观点，但主要是由于多线程。

Java GC分配的工作方式是使用一种非常便宜的分配策略，将对象最初分配给“ Eden”空间。据我所知，它使用的是顺序池分配器。

就算法和减少强制性页面错误而言，这比malloc使用C语言或operator newC语言中的通用语言要快得多。

但是顺序分配器有一个明显的缺点：他们可以分配大小可变的块，但不能释放任何单独的块。它们只是以填充的直接顺序方式进行对齐填充，并且只能清除一次分配的所有内存。它们通常在C和C ++中用于构造仅需要插入而无需删除元素的数据结构，例如搜索树，该搜索树仅在程序启动时需要构建一次，然后重复搜索或仅添加新键（未删除任何键）。

它们甚至还可以用于允许删除元素的数据结构，但是由于我们无法单独取消分配它们，因此实际上不会从内存中释放这些元素。这种使用顺序分配器的结构只会消耗越来越多的内存，除非它经过一些延迟的传递，即使用单独的顺序分配器将数据复制到新的压缩副本中（如果固定分配器获胜，这有时是非常有效的技术）出于某种原因而做不到-只是按顺序向上分配数据结构的新副本并转储旧结构的所有内存）。

采集

就像上面的数据结构/顺序池示例中一样，如果Java GC仅以这种方式分配，即使对于许多单个块的突发分配而言，它的超快速度也将是一个巨大的问题。在软件关闭之前，它将无法释放任何内容，此时它可以一次释放（清除）所有内存池。

因此，取而代之的是，在单个GC周期之后，遍历“ Eden”空间（顺序分配）中的现有对象，然后使用能够释放单个块的通用分配器分配仍被引用的对象。不再引用的对象将在清除过程中被简单地释放。因此，基本上就是“如果仍然引用对象，则将它们从Eden空间复制出来，然后清除”。

这通常会非常昂贵，因此它是在单独的后台线程中完成的，以避免显着停止最初分配所有内存的线程。

一旦将内存从Eden空间中复制出来并使用这种更昂贵的方案分配，该方案可以在初始GC周期后释放单个块，则对象将移至更持久的内存区域。如果这些单独的块不再被引用，则在随后的GC周期中释放它们。

速度

因此，粗略地说，Java GC在直接堆分配中可能会非常好于C或C ++的原因是因为它在请求分配内存的线程中使用了最便宜的，完全简化的分配策略。然后，它节省了我们在使用更通用的分配器（例如，malloc对另一个线程进行简化）时通常需要做的更昂贵的工作。

因此，从概念上讲，GC实际上实际上必须做更多的工作，但是它是在线程之间分配的，因此，单个线程不会预先支付全部费用。它使分配内存的线程能够以超便宜的价格进行分配，然后推迟正确执行操作所需的实际开销，以便可以将各个对象实际上释放给另一个线程。在C或C ++中，当我们malloc调用时operator new，我们必须在同一线程内预先支付全部费用。

这是主要区别，这就是为什么Java仅使用天真调用malloc或operator new单独分配一堆小块就可以胜过C或C ++的原因。当然，当GC周期开始时，通常会有一些原子操作和一些潜在的锁定，但是可能已经做了很多优化。

基本上，简单的解释可以归结为在单个线程（malloc）中支付较重的成本，而不是在单个线程中支付较便宜的成本，然后在可以并行运行的另一个线程（）中支付较重的成本GC。不利的是，这种方式意味着您需要根据需要从对象引用到对象两个间接访问，以允许分配器在不使现有对象引用无效的情况下复制/移动内存，并且一旦对象内存被占用，您可能会失去空间局部性。移出“伊甸园”空间。

最后但并非最不重要的一点是，该比较有点不公平，因为C ++代码通常不会在堆上单独分配大量对象。体面的C ++代码倾向于为连续块或堆栈中的许多元素分配内存。如果它一次在免费商店中分配一小批小对象，那么代码就很糟糕。

这完全取决于谁来衡量速度，他们要衡量哪种实现的速度以及他们想证明什么。和他们比较。

如果只看分配/取消分配，则在C ++中，可能有1,000,000个调用malloc，有1,000,000个调用free（）。在Java中，您将有1,000,000次对new（）的调用，并有一个垃圾回收器在循环中运行，查找可以释放的1,000,000个对象。循环可能比free（）调用快。

另一方面，malloc / free改善了其他时间，通常，malloc / free仅在单独的数据结构中设置一位，并且针对同一线程中发生的malloc / free进行了优化，因此在多线程环境中没有共享内存变量在许多情况下都使用（并且锁定或共享内存变量非常昂贵）。

第三，没有引用收集，您可能需要像引用计数这样的东西，并且这不是免费的。