菜单 学习猿地 - LMONKEY

VIP

开通学习猿地VIP

尊享10项VIP特权 持续新增

知识通关挑战

打卡带练!告别无效练习

接私单赚外块

VIP优先接,累计金额超百万

学习猿地私房课免费学

大厂实战课仅对VIP开放

你的一对一导师

每月可免费咨询大牛30次

领取更多软件工程师实用特权

入驻
235
0

[翻译] 编写高性能 .NET 代码--第二章 GC -- 减少大对象堆的碎片,在某些情况下强制执行完整GC,按需压缩大对象堆,在GC前收到消息通知,使用弱引用缓存对象

原创
05/13 14:22
阅读数 62008

减少大对象堆的碎片

如果不能完全避免大对象堆的分配,则要尽量避免碎片化。
对于LOH不小心就会有无限增长,但LOH使用的空闲列表机制可以减轻增长的影响。利用这个空闲列表,我们可以在两块分配区域中间找到你所想要的可分配区域。
要做到这一点,就需要保证你在LOH里的分配都按照同一个尺寸或者同一个尺寸的倍数进行。例如,一个常见的需求是在LOH里分配缓冲区。要确保分配的每个缓冲区都是一个大小,或者是一个知名数字(1M)的倍数,而不要创建大小不一的缓冲区。这样做的话,如果一个缓冲区被回收,那么下一个缓冲区在分配的时候,很大概率不会在堆结尾分配,而是会在被回收的地方重新分配。

继续用前面的MemoryStreams的的故事。我们的第一个实现我们只对PooledMemoryStream进行的池化,它的缓冲区增长还是沿用MemoryStreams的默认算法,当超过容量是,会按照当前的缓冲区大小加倍申请。这虽然解决分配问题,但是又造成了碎片问题。第二次迭代的时候,我们抛弃了这种申请算法,我们倾向于实现一个流的抽象类,将多个128K直接的缓冲区合并使用,将这些小的缓冲区用链接的方式组成一个大的缓冲区,他们大小为1MB的倍数(最大为8MB)。这个新的实现大大减少了我们的碎片问题,当然我们偶尔还会不得不将一些128KB的数据复制到1MB的缓冲区里,但这样的改进也是值得的。

在某些情况下强制执行完整GC

在几乎所有的正常情况下,你是不应该主动执行完整GC操作的,这可能会打乱GC的自动处理流程,导致一些不好的结果。但是,在一些高性能系统里存在一些情况,我们还是会建议你进行一次完整GC。
通常,在有合适的时间窗口下进行完整GC,可以避免在今后不好的时间段执行GC。注意,这里讨论的只是耗时比较多完整GC,对于0代和1代的回收还是应该频繁出发,以避免构建的0代内存区太大。

在下面情况可以做一次完整的完整GC:

  1. 你如果使用了低延迟模式,在这种模式下,堆的大小会一直增长,这个时候你需要在合适的时间点来执行一次完成GC。

  2. 如果会偶尔大量分配一些长生命周期的对象(初始化对象池),在对象创建后,可以执行一次完整GC,将对象尽快转为2代对象。或者当你不再使用这些对象,也最好在删除引用后强制回收他们。

  3. 如果你现在所处的状态,因为碎片太多,必须要做大对象堆做压缩的时候。

对于情况1,2都是在特定时间里通过强制执行GC来避免在不合适的时机被执行GC。情况3,如果你在LOH里有很大的碎片,则可以帮助你减少堆的大小。如果不是上面的情况,你最好另外想一些其它优化方案。

要执行完整GC,可以使用GC.Collect来回收所希望的代纪。还可以通过GCCollectionMode的枚举参数告诉GC是否立即执行。参数有3个值
Default--(默认)当前,强制
Forced--(强制)告诉GC立即开始收集
Optimized--(优化)由GC决定现在是否是要的时机执行回收


GC.Collect(2);
// 等价于 
GC.Collect(2, GCCollectionMode.Forced);

按需压缩大对象堆

即使使用了对象池,仍然可能会在大对象堆里分配对象,随着时间的推移,在里面会存在很多碎片。从.NET 4.5.1 开始,你可以告诉GC在下一次做完整GC时顺便也对LOH做一次压缩。

GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;

根据LOH的大小,这个压缩过程可能会很慢,甚至会用到好几秒。你最好是在你的程序能够长时间暂停的时候,才让垃圾回收器做一次这样的完整GC。修改该设置值,只会在下一次完整GC时会触发压缩,一旦完成了LOH的压缩,GCSettings.LargeObjectHeapCompactionMode就会被重新设置为GCLargeObjectHeapCompactionMode.Default。
因为这个过程很耗时,我还是建议你减少对LOH的分配或者使用对象池。这样将大大减少压缩的数据。压缩LOH功能只能作为碎片过多,分配的堆太大时的最后手段。

在GC前收到消息通知

如果你的应用完全不希望受到2代的的GC影响,你可以在GC快来临前收到一个通知。这样可以给你一个机会,暂停现有的业务处理,将请求分流到其它服务器,或者进入某种对你更合理的状态。
但是我建议你谨慎使用,这个GC通知机制可能会给你产生一些意料之外的情况。你应该在所有的优化手段都使用后才考虑它。如果你有下面的情况,你可以利用GC通知功能。

  1. 系统在进行一次完整GC时耗时太长,你完全无法接受
  2. 你可以完全关闭进程。(可以动态将相应请求交给其它进程)
  3. 你可以快速停止当前的业务处理。(暂停逻辑处理时间不要比执行GC的时间更多)
  4. 2代GC发生的几率很少,值得你这样处理。

2代的回收起始很少发生,更多的时候是在很多0代小对象分配时会达到触发的阈值,所以在收到GC的通知时,你还有很多工作需要做。
不幸的是,由于GC通知触发的不精确性,你只能在1-99范围你指定一个合适的触发时机。如果数字比较小,你可能会在里真正GC前才会收到消息,没有足够的时间做相应处理。但如果你的数字太高,这可能会被频繁触发而不会触及真正的GC。这两个选择取决你当前内存的分配率与内存负债。注意,这里会指定2个阈值数字,一个用于2代对象,一个用于LOH。与其它功能一样,GC会尽最大努力给你通知,但它不会保证你能不做这次GC。
要使用此功能,请按照一下步骤进行。

  1. 使用 GC.RegisterForFullGCNotification 方法,设置2个触发用的阈值
  2. 轮询的方式使用 GC.WaitForFullGCApproach 方法,你可以一直等待,或者配置超时返回值
  3. 如果 WaitForFullGCApproach 返回Success,请将程序的状态设置为可以进行完整GC状态(例如:暂停请求处理)
  4. 使用 GC.Collect 方法强制进行回收
  5. 调用 GC.WaitForFullGCComplete(可传入超时时间) 方法,等待GC完成。
  6. 重新打开对外的访问请求
  7. 如果你不再需要收到GC的通知,可以使用 GC.CancelFullGCNotification 方法进行取消。

因为通知需要一个轮询的机制,你需要有一个线程定期的检查状态。如果你的程序里已经有这样的定时检查功能,你可以将它嵌入到检查流程里。当然也可以单独为GC检查创建一个独立的线程。
下面的是一个 GCNotification 的完整例子。它会不断的分配内存用来测试通知过程。

internal class Program
    {
        private static void Main(string[] args)
        {
            const int ArrSize = 1024;
            var arrays = new List<byte[]>();
            GC.RegisterForFullGCNotification(25, 25);
            // Start a separate thread to wait for GC notifications 
            Task.Run(() => WaitForGCThread(null));
            Console.WriteLine("Press any key to exit");
            while (!Console.KeyAvailable)
            {
                try
                {
                    arrays.Add(new byte[ArrSize]);
                }
                catch (OutOfMemoryException)
                {
                    Console.WriteLine("OutOfMemoryException!");
                    arrays.Clear();
                }
            }
            GC.CancelFullGCNotification();
        }

        private static void WaitForGCThread(object arg)
        {
            const int MaxWaitMs = 10000;
            while (true)
            {
                // There is also an overload of WaitForFullGCApproach
                // that waits indefinitely 
                GCNotificationStatus status = GC.WaitForFullGCApproach(MaxWaitMs);
                bool didCollect = false;
                switch (status)
                {
                    case GCNotificationStatus.Succeeded:
                        Console.WriteLine("GC approaching!");
                        Console.WriteLine("-- redirect processing to another machine -- ");
                        didCollect = true;
                        GC.Collect();
                        break;
                    case GCNotificationStatus.Canceled:
                        Console.WriteLine("GC Notification was canceled");
                        break;
                    case GCNotificationStatus.Timeout:
                        Console.WriteLine("GC notification timed out");
                        break;
                }
                if (didCollect)
                {
                    do
                    {
                        status = GC.WaitForFullGCComplete(MaxWaitMs);
                        switch (status)
                        {
                            case GCNotificationStatus.Succeeded:
                                Console.WriteLine("GC completed");
                                Console.WriteLine("-- accept processing on this machine again --");
                                break;
                            case GCNotificationStatus.Canceled:
                                Console.WriteLine("GC Notification was canceled");
                                break;
                            case GCNotificationStatus.Timeout:
                                Console.WriteLine("GC completion notification timed out");
                                break;
                        }
                        // Looping isn't necessary, but it's useful if you want 
                        // to check other state before waiting again. 
                    } while (status == GCNotificationStatus.Timeout);
                }
            }
        }
    }

另外一种触发方式是压缩LOH堆,但是基于内存使用触发更合适一些。

使用弱引用缓存对象

被弱引用对象引用的对象时可以在GC的时候被回收的。这与强引用形成对别,强引用后的对象是不会被回收的。弱引用主要用来缓存你想保留的不是很重要的对象,一旦应用有内存上的压力,就有可能被回收。

WeakReference weakRef = new WeakReference(myExpensiveObject);
… 
// Create a strong reference to the object, 
// now no longer eligible for GC 
var myObject = weakRef.Target;
if (myObject != null)
{
    myObject.DoSomethingAwesome();
}


发表评论

0/200
235 点赞
0 评论
收藏
为你推荐 换一批