Question

我已经理解堆和垃圾收集器是如何工作的：垃圾收集发生在几代中，内存分配顺序发生，垃圾收集期间自由/未使用空间通过移位数据和形成连续块等来压缩等。

是否存在已分配的内存块的标头以及它们有多大（我听说它是.NET CLR的8-16个字节）以及是否存在字节，字或四字对齐？我对x86和x64处理器体系结构的JIT（Java）和CLR（.NET Framework或Mono）实现的任何信息感兴趣。

Answer 1

我认为标题大小是两个字 - 一个用于类型引用，一个用于同步块和其他标志。填充（我相信）足以将总大小四舍五入到整数个单词。

例如，只有“int”的引用类型在x86上占用12个字节，如下所示：

using System;

public class Foo
{
    int x;

    public Foo(int x)
    {
        this.x = x;
    }
}

public class Test
{
    static void Main(string[] args)
    {
        int length = int.Parse(args[0]);

        Foo x = new Foo(0);
        Foo[] array = new Foo[length];
        // Make sure that JITting the string constructor doesn't
        // change things
        long start = GC.GetTotalMemory(true);
        for (int i=0; i < length; i++)
        {
            array[i] = new Foo(i);
        }
        long end = GC.GetTotalMemory(true);

        GC.KeepAlive(array);
        GC.KeepAlive(x);

        decimal totalDecimal = end-start;
        Console.WriteLine(totalDecimal / length);
    }
}

一个有趣的观点 - 由于某种原因，System.Object的实例需要12个字节（在x86上）而不是我预测的8个字节。就好像最小大小是12个字节，但是你可以获得实际数据的前四个字节：）

我不知道为什么报告的大小不是一个整数，顺便说一下 - 我怀疑它与托管堆中每页所需的一些额外内存有关，或类似的东西。有时结果有点超过12，有时略低于12 - 这似乎取决于给定的长度。（这个答案的先前版本有一个错误，它将解析第一个命令行arg但后来忽略它。我已经修复了。）无论如何，我不相信这种轻微的不准确性与大小有关在记忆中的一个单独的对象。

Answer 2

问题的完整答案实际上相当复杂：与对象分配相关的开销不仅取决于特定虚拟机的实现细节，而且还取决于对象恰好在其中的生成（在换句话说，与特定对象关联的开销可能会在对象的生命周期内发生变化。）

可以使用几个简单的实用程序来估计特定对象的开销，但没有任何强大的功能（请查看示例http://java.sun.com/docs/books/performance/1st_edition/html/JPRAMFootprint.fm.html）。

在Java中，还有一个可能为您提供包括开销在内的对象大小的接口，请参阅http://download-llnw.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#GetObjectSize。

Answer 3

我不了解Java，但对于CLR，每个引用类型分配了1个本机字开销。在32位系统上，它将是4字节，64位系统将是8字节。

Java和.NET堆开销

3 个答案: