开启LOH压缩？

我们知道.NET CLR的GC堆中有一种特殊的堆，它专门存放超过85000byte的对象（详见这里），这就是大对象堆（LOH）。

在.NET Framework 4.5.1之前，微软并没有提供对LOH的压缩操作，这是因为移动大对象的开销是很可观的。不能压缩LOH也会带来一些问题，比如LOH的内存碎片化。不过在.NET Framework 4.5.1种，微软加入了对LOH堆压缩的开关。对于为什么会加入这个开关，个人猜测应该是考虑到计算机性能足以支撑这种操作。具体使用参照以下代码：

GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect();    

对于GCLargeObjectHeapCompactionMode.CompactOnce的解释是，在下一次回收gen2时压缩LOH。也就是说这个设置每执行一次只起一次效果，这种设计是很合理的，毕竟如果作为永久开关则会造成不必要的压缩操作。虽然计算机性能足以支持LOH的压缩操作，但这并不意味着不会影响性能。

那么，我怎么知道这个操作达到了预期的效果呢？这就要上调试神器WinDbg了，虽然类似CLRProfiler也可以看出来，但就信息量来说WinDbg要胜一筹。

首先上测试代码：

class Program
{
    static void Main(string[] args)
    {
        //在LOH堆上放一个大对象，调用完后该对象即被认作是垃圾
        MakeALohObject();

        //在LOH堆上再放一个大对象，此时该对象会被保持
        var bytes = new byte[1024*1024];

        //注释和取消注释以下开关，并分别dump内存用于分析
        GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
        //触发all gc
        GC.Collect();

        Console.Read();
    }

    static void MakeALohObject()
    {
        var obj = new byte[1024 * 1024];
    }
}

下面是未打开压缩LOH开关的dump信息节选：

0:000> !eeheap
---------------省略部分信息
Number of GC Heaps: 1
generation 0 starts at 0x000001450b255b90
generation 1 starts at 0x000001450b251018
generation 2 starts at 0x000001450b251000
ephemeral segment allocation context: none
         segment             begin         allocated              size
000001450b250000  000001450b251000  000001450b255ba8  0x4ba8(19368)
Large object heap starts at 0x000001451b251000
         segment             begin         allocated              size
000001451b250000  000001451b251000  000001451b4599f0  0x2089f0(2132464)
Total Size:              Size: 0x20d598 (2151832) bytes.
------------------------------
GC Heap Size:            Size: 0x20d598 (2151832) bytes.

0:000> !dumpheap -stat
Statistics:
              MT    Count    TotalSize Class Name
----------------省略部分信息
00007ff8edfa2160        2          706 System.Char[]
00007ff8edfa61a8        2         1072 System.Globalization.CultureData
00007ff8edfa2360       17         1112 System.String[]
00007ff8edfa2f10       26         1456 System.RuntimeType
00007ff8edfa1010      154         6696 System.String
00007ff8edfa1688        5        35144 System.Object[]
00007ff8edfa7248        3      1048904 System.Byte[]
00000145095abf40       24      1051068      Free
Total 294 objects

0:000> !DumpHeap /d -mt 00000145095abf40
         Address               MT     Size
000001450b251000 00000145095abf40       24 Free
000001450b251018 00000145095abf40       24 Free
000001450b251030 00000145095abf40       24 Free
----------------省略部分信息
000001451b259980 00000145095abf40  1048662 Free

从!eeheap命令结果可以看出LOH共2132464byte，约2mb，也就是说虽然回收了一个1mb的byte数组，但是内存并未压缩。从!dumpheap -stat中的Free里面可以找到被释放的1mb空间。

接下来看看打开压缩LOH开关的内存dump：

0:000> !eeheap
----------------省略部分信息
Number of GC Heaps: 1
generation 0 starts at 0x0000015300005390
generation 1 starts at 0x0000015300001018
generation 2 starts at 0x0000015300001000
ephemeral segment allocation context: none
         segment             begin         allocated              size
0000015300000000  0000015300001000  00000153000053a8  0x43a8(17320)
Large object heap starts at 0x0000015310001000
         segment             begin         allocated              size
0000015310000000  0000015310001000  00000153101099b8  0x1089b8(1083832)
Total Size:              Size: 0x10cd60 (1101152) bytes.
------------------------------
GC Heap Size:            Size: 0x10cd60 (1101152) bytes.

0:000> !dumpheap -stat
Statistics:
              MT    Count    TotalSize Class Name
----------------省略部分信息
000001536ca7be30       16          414      Free
00007ff8edfa8520        1          432 System.Collections.Generic.Dictionary`2+Entry[[System.Type, mscorlib],[System.Security.Policy.EvidenceTypeDescriptor, mscorlib]][]
00007ff8edfa39d8        6          524 System.Int32[]
00007ff8edfa2160        2          706 System.Char[]
00007ff8edfa61a8        2         1072 System.Globalization.CultureData
00007ff8edfa2360       17         1112 System.String[]
00007ff8edfa2f10       26         1456 System.RuntimeType
00007ff8edfa1010      154         6696 System.String
00007ff8edfa1688        5        35144 System.Object[]
00007ff8edfa7248        3      1048904 System.Byte[]
Total 286 objects

从上面可以看出LOH的size未1083832，即约1mb，这说明的确是将LOH压缩了，且!dumpheap -stat里的Free里也找不到这块空区域了。

说了这么多其实都不是重点，重点是既然我们用了LOH压缩，那么LOH压缩对性能会产生多大影响呢？首先我们要明白，启用LOH压缩并不是直接影响我们所编写的代码的执行性能，而是影响的GC回收性能。而GC回收的前奏就是挂起所有工作线程，所以GC每次执行的时间决定着整个系统将挂起多长时间。

那么接着贴一段代码，该段代码用于统计在启用和关闭LOH压缩的平均耗时：

class Program
{
    static void Main(string[] args)
    {
        var cycle = 1000;
        var total = 0l;
        //预热
        MakeGrabage();

        for (int j = 0; j < cycle; j++)
        {
            total += MakeGrabage();
        }
        Console.WriteLine("平均耗时{0}毫秒", total / (double)cycle);
        Console.Read();
    }

    static long MakeGrabage()
    {
        var objs = new byte[1000][];
        //初始化1000个1mb的byte数组
        for (int i = 0; i < 1000; i++)
        {
            objs[i] = new byte[1024 * 1024];
        }
        //将其中一半置为垃圾对象
        for (int i = 0; i < objs.Length; i++)
        {
            if (i % 2 == 0)
            {
                objs[i] = null;
            }
        }
        var sw = Stopwatch.StartNew();
        //开启或关闭LOH压缩
        GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
        GC.Collect();
        sw.Stop();
        var elasped = sw.ElapsedMilliseconds;

        objs = null;
        GC.Collect();
        return elasped;
    }
}

在上述条件下，我的机器跑出的结果是：不开启LOH压缩平均回收需要0.705毫秒，而开启后平均回收需要325.369毫秒，差了461倍。内存占用情况不开启LOH压缩平均在1400mb左右，开启后平均在850mb左右，内存是纯眼看，所以可能差距比较大。

就上述数据而言，LOH压缩还是在有必要的时候再用吧。

原创文章，转载请注明： 转载自xdlysk的博客

本文链接地址: 开启LOH压缩？[http://www.xdlysk.com/article/5826c1d2b16bc40409d5cac8]