为什么结构对齐取决于字段类型是原始类型还是用户定义的？

In 野田时间 http://nodatime.orgv2，我们正在转向纳秒分辨率。这意味着我们不能再使用 8 字节整数来表示我们感兴趣的整个时间范围。这促使我研究 Noda Time 的（许多）结构体的内存使用情况，这反过来又引导我发现 CLR 对齐决策中的一点奇怪之处。

首先，我意识到这is实施决策，并且默认行为可以随时更改。我意识到我can修改它使用[StructLayout] http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.structlayoutattribute and [FieldOffset] http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.fieldoffsetattribute，但我宁愿想出一个如果可能的话不需要的解决方案。

我的核心场景是我有一个struct其中包含一个引用类型字段和另外两个值类型字段，其中这些字段是简单的包装器int. I had hoped这将在 64 位 CLR 上表示为 16 个字节（8 个用于参考，4 个用于其他每个字节），但由于某种原因它使用 24 个字节。顺便说一句，我正在使用数组来测量空间 - 我知道布局在不同情况下可能会有所不同，但这感觉像是一个合理的起点。

这是演示该问题的示例程序：

using System;
using System.Runtime.InteropServices;

#pragma warning disable 0169

struct Int32Wrapper
{
    int x;
}

struct TwoInt32s
{
    int x, y;
}

struct TwoInt32Wrappers
{
    Int32Wrapper x, y;
}

struct RefAndTwoInt32s
{
    string text;
    int x, y;
}

struct RefAndTwoInt32Wrappers
{
    string text;
    Int32Wrapper x, y;
}    

class Test
{
    static void Main()
    {
        Console.WriteLine("Environment: CLR {0} on {1} ({2})",
            Environment.Version,
            Environment.OSVersion,
            Environment.Is64BitProcess ? "64 bit" : "32 bit");
        ShowSize<Int32Wrapper>();
        ShowSize<TwoInt32s>();
        ShowSize<TwoInt32Wrappers>();
        ShowSize<RefAndTwoInt32s>();
        ShowSize<RefAndTwoInt32Wrappers>();
    }

    static void ShowSize<T>()
    {
        long before = GC.GetTotalMemory(true);
        T[] array = new T[100000];
        long after  = GC.GetTotalMemory(true);        
        Console.WriteLine("{0}: {1}", typeof(T),
                          (after - before) / array.Length);
    }
}

我的笔记本电脑上的编译和输出：

c:\Users\Jon\Test>csc /debug- /o+ ShowMemory.cs
Microsoft (R) Visual C# Compiler version 12.0.30501.0
for C# 5
Copyright (C) Microsoft Corporation. All rights reserved.


c:\Users\Jon\Test>ShowMemory.exe
Environment: CLR 4.0.30319.34014 on Microsoft Windows NT 6.2.9200.0 (64 bit)
Int32Wrapper: 4
TwoInt32s: 8
TwoInt32Wrappers: 8
RefAndTwoInt32s: 16
RefAndTwoInt32Wrappers: 24

So:

• 如果您没有引用类型字段，CLR 很乐意打包Int32Wrapper字段在一起（TwoInt32Wrappers尺寸为 8)
• 即使有引用类型字段，CLR 仍然乐意打包int字段在一起（RefAndTwoInt32s尺寸为 16)
• 将两者结合起来，分别Int32Wrapper字段似乎已填充/对齐为 8 字节。 （RefAndTwoInt32Wrappers大小为 24。）
• 在调试器中运行相同的代码（但仍然是发布版本）显示大小为 12。

其他一些实验也得出了类似的结果：

• 将引用类型字段放在值类型字段之后没有帮助
• Using object代替string没有帮助（我希望它是“任何引用类型”）
• 使用另一个结构作为引用的“包装器”没有帮助
• 使用通用结构作为引用的包装器没有帮助
• 如果我继续添加字段（为了简单起见成对添加），int字段仍然占 4 个字节，并且Int32Wrapper字段占 8 个字节
• Adding [StructLayout(LayoutKind.Sequential, Pack = 4)]看到的每个结构都不会改变结果

有没有人对此有任何解释（最好有参考文档）或建议我如何向 CLR 提示我希望打包这些字段without指定恒定的字段偏移量？

我认为这是一个错误。您会看到自动布局的副作用，它喜欢将重要字段与 64 位模式下 8 字节的倍数的地址对齐。即使您明确应用该方法，也会发生这种情况[StructLayout(LayoutKind.Sequential)]属性。这是不应该发生的。

您可以通过将结构成员公开并附加测试代码来查看它，如下所示：

    var test = new RefAndTwoInt32Wrappers();
    test.text = "adsf";
    test.x.x = 0x11111111;
    test.y.x = 0x22222222;
    Console.ReadLine();      // <=== Breakpoint here

当断点命中时，使用 Debug + Windows + Memory + Memory 1. 切换到 4 字节整数并放入&test在地址字段中：

 0x000000E928B5DE98  0ed750e0 000000e9 11111111 00000000 22222222 00000000 

0xe90ed750e0是我机器上的字符串指针（不是你的）。您可以轻松地看到Int32Wrappers，加上额外的 4 个字节的填充，将大小变为 24 个字节。返回结构并将字符串放在最后。重复，你会看到字符串指针是still第一的。违反LayoutKind.Sequential， 你得到了LayoutKind.Auto.

说服微软解决这个问题是很困难的，这种方式已经运行太久了，所以任何改变都会被破坏某物。 CLR 只是尝试兑现[StructLayout]对于结构的托管版本并使其可blittable，它通常很快就会放弃。对于任何包含 DateTime 的结构来说都是臭名昭著的。只有在封送结构时才能获得真正的 LayoutKind 保证。编组版本肯定是 16 字节，如下所示Marshal.SizeOf()会告诉你的。

Using LayoutKind.Explicit修复它，而不是你想听到的。