内存管理的90/10规则？

Question

大多数程序员都认为垃圾收集是一件好事,在大多数应用程序中都非常值得花费.但是,我个人的观察是,大多数对象的内存管理都是微不足道的,并且可能有10%-20%的内存管理需要考虑诸如引用计数和一般非常复杂的内存管理方案等问题.在我看来,只需一小部分开销就可以获得垃圾收集的所有好处,保守地手动删除大对象,其中对象的生命周期很明显,让GC收集其余的,假设GC实现支持这样的事情.这将允许GC运行频率降低,并消耗更少的多余内存,同时仍然避免实际难以手动管理的情况.

int myFunc() {
    Foo[] foo = new Foo[arbitraryNumber];  // May be too big to stack allocate.
    // do stuff such that the compiler can prove foo doesn't escape.
    // foo is obviously no longer needed, can be automatically deleted here.
    return someInteger;
}

当然,这可能不适用于复制GC,但是为了这个帖子,我们假设我们的GC没有复制.为什么这种混合内存管理方案在主流编程语言中显然如此罕见？

Answer 1

因为这种情况太罕见了。几乎没有一种方法是孤立的。它们都从外部接受对象或者创建对象并将其传递出去。

不访问任何字段、没有参数、不返回任何内容的方法无法执行任何操作。

相反，GC 专注于最常见的情况（90%）并尝试控制这 90%（短暂的临时对象）。这意味着在常见情况下，您需要检查的对象较少，其余的并不那么重要。接下来，您使用增量扫描（这样您就可以运行小冲刺，仅中断一小会儿）。

我曾经尝试想出一个更好的 GC 算法，但惨遭失败。他们使用一种近乎神秘的方法。关于Java 5 GC Performance Tuning 的文档应该会给你一些想法。当然，维基百科上也有关于 GC 的文章。

归结为：使用 GC 甚至比传统的内存分配和释放模式更快。想想经典算法，它只是定位任何可到达的对象并将其复制到新位置。如果您刚刚忘记了很多对象（例如，所有已分配对象的 90%），则该算法只需要检查其余对象（10%）。任何它无法达到的东西，无论达到多少，都无关紧要。现在你可能会说复制成本很高，但是a）这不是真的；如今，普通台式机 CPU 可以在不到 100 毫秒的时间内复制 40MB，并且 b) 复制将保护您免受碎片的影响，因此这实际上是一件好事。