流行问题：哪种语言的原始分配性能更快，Java 语言还是 C/C++？答案可能令人惊讶 —— 现代 JVM 中的分配比执行得最好的 malloc 实现还要快得多。HotSpot 1.4.2 之后虚拟机中的 new Object() 常见代码路径最多 10 条机器指令，而用 C 语言实现的执行得最好的 malloc 实现，每个调用平均要求的指令在 60 到 100 条之间。而且分配性能在整体性能中不是一个微不足道的部分，测评显示：对于许多实际的 C 和 C++ 程序（例如 Perl 和 Ghostscript），整体执行时间中的 20% 到 30% 都花在 malloc 和 free 上，远远多于健康的 Java 应用程序在分配和垃圾收集上的开销。

    继续，弄得一团糟

    没有必要搜索众多的 blog 或 Slashdot 贴子，去寻找像“垃圾收集永远不会像直接内存管理一样有效”这样能够说服人的陈述。而且，从某个方面来说，这些话说的是对的 —— 动态内存管理并不一样快 —— 而是快得多。

    malloc/free 技术一次处理一个内存块，而垃圾收集机制则采用大批量方式处理内存管理，从而形成更多的优化机会（以一些可以预见到的损失为代价）。

    这条“听起来有理的意见” （以大批量清理垃圾要比一天到晚一点点儿清理垃圾更容易）得到了数据的证实。一项研究测量了在许多常见 C++ 应用程序中，用保守的 Boehm-Demers-Weiser（BDW）替换 malloc 的效果，结果是：许多程序在采用垃圾收集而不是传统的分配器运行时，表现出了速度提升。（BDW 是个保守的、不移动的垃圾收集器，严重地限制了对分配和回收进行优化的能力，也限制了改善内存位置的能力；像 JVM 中使用的那些精确的浮动收集器可以做得更好。）

    在 JVM 中的分配并不总是这么快，早期 JVM 的分配和垃圾收集性能实际上很差，这当然就是 JVM 分配慢这一说法的起源。

    在非常早的时候，我们看到过许多“分配慢”的意见 —— 因为就像早期 JVM 中的一切一样，它确实慢 —— 而性能顾问提供了许多避免分配的技巧，例如对象池。（公共服务声明：除了对最重量的对象之外，对象池现在对于所有对象都是严重的性能损失，而且要在不造成并发瓶颈的情况下使用对象池也很需要技巧。）但是，从 JDK 1.0 开始已经发生了许多变化；JDK 1.2 中引入的分代收集器（generational collector）支持简单得多的分配方式，可以极大地提高性能。

    分代垃圾收集

    分代垃圾收集器把堆分成多代；多数JVM使用两代，“年轻代”和“年老代”。对象在年轻代中分配；如果它们在一定数量的垃圾收集之后仍然存在，就被当作是”长寿的“，并晋升到年老代。

    HotSpot 提供了使用三个年轻代收集器的选择（串行拷贝、并行拷贝和并行清理），它们都采用“拷贝”收集器的形式，有几个重要的公共特征。拷贝收集器把内存空间从中间分成两半，每次只使用一半。

    开始时，使用中的一半构成了可用内存的一个大块；分配器满足分配请求时，返回它没有使用的空间的前 N 个字节，并把指针（分隔“使用”部分）从“自由”部分移动过来，如清单 1的伪代码所示。

    当使用的那一半用满时，垃圾收集器把所有活动对象（不是垃圾的那些对象）拷贝到另一半的底部（把堆压缩成连续的），然后从另一半开始分配。 清单 1. 在存在拷贝收集器的情况下，分配器的行为

    从这个伪代码可以看出为什么拷贝收集器可以实现这么快的分配 —— 分配新对象只是检查在堆中是否还有足够的剩余空间，如果还有，就移动指针。不需要搜索自由列表、最佳匹配、第一匹配、lookaside 列表 ，只要从堆中取出前 N 个字节，就成功了。