c# - 重型 WPF 控件如何以一种确定的方式使用一个空闲内存？

Question

当使用来自 UI 的输入事件销毁和重建分配大量内存的控件时，我一直遇到问题。

显然，将窗口的内容设置为空不足以释放所包含的控件正在使用的内存。它最终会被GCed。但是随着用于销毁和构造控件的输入事件越来越频繁，GC 似乎会跳过一些对象。

我把它分解成这个例子:

XAML:

<Window x:Class="WpfApplication1.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="MainWindow" Height="350" Width="525" x:Name="window" MouseMove="window_MouseMove">
</Window>

C#:

using System;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;

namespace WpfApplication1
{
    public partial class MainWindow : Window
    {
        private class HeavyObject : UserControl
        {
            private byte[] x = new byte[750000000];

            public HeavyObject()
            {
                for (int i = 0; i++ < 99999999; ) { } // just so we can follow visually in Process Explorer
                Content = "Peekaboo!"; // change Content to el cheapo re-trigger MouseMove
            }
        }

        public MainWindow()
        {
            InitializeComponent();

            //Works 1:
            //while (true)
            //{
            //    window.Content = null;
            //    window.Content = new HeavyObject();
            //}
        }

        private void window_MouseMove(object sender, MouseEventArgs e)
        {
            if (window.Content == null)
            {
                GC.Collect();
                GC.WaitForPendingFinalizers();
                // Works 2:
                //new HeavyObject();
                //window.Content = "Peekaboo!"; // change Content to el cheapo re-trigger MouseMove
                //return;
                window.Content = new HeavyObject();
            }
            else
            {
                window.Content = null;
            }
        }
    }
}

这确实会在每个 MouseMove 事件中分配一个大约 750MB 的对象 (HeavyObject) 并将其作为主窗口的内容。如果 Cursor 在 Window 上保持静止，则 Content 更改将无休止地重新触发事件。对 HeavyObject 的引用在其下一次构造之前被清空，并触发对其剩余部分进行 GC 的徒劳尝试。

我们在 ProcessExplorer/Taskman 中看到的是，有时分配了 1.5GB 或更多。如果没有，请疯狂移动鼠标离开并重新进入窗口。如果您在没有 LARGEADDRESSAWARE 的情况下针对 x86 进行编译，您将得到一个 OutOfMemoryException(限制为 ~1.3GB)。

如果您在不使用鼠标输入的情况下在无限循环中分配 HeavyObject(取消注释部分“Works 1”)，或者如果您通过鼠标输入触发分配但不将对象放入视觉对象，则不会遇到此行为树(取消注释部分“Works 2”)。

所以我想这与视觉树延迟释放资源有关。但是还有一个奇怪的效果:如果光标在窗口外时消耗了 1.5GB，GC 似乎不会启动，直到再次触发 MouseMove。至少，只要没有进一步的事件被触发，内存消耗似乎就会稳定下来。因此，要么在某处留下了长期存在的引用，要么 GC 在没有事件时变得懒惰。

我觉得很奇怪。你能弄清楚发生了什么吗？

编辑:正如 BalamBalam 评论的那样:在销毁控件之前可以取消引用控件背后的数据。那将是 B 计划。不过也许有更通用的解决方案。

说这样的控件是糟糕的代码是没有帮助的。我想知道为什么如果我在取消引用后将 UI 单独放置几个 Ticks，那么我没有引用的对象会被 GCed，但如果另一个对象(必须由用户输入创建)立即接受它，那么它会永远徘徊地方。

Answer 1

好吧，我想我可能知道这里发生了什么。不过要加少许盐……

我稍微修改了你的代码。

Xaml

<Window x:Class="WpfApplication1.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525" x:Name="window" MouseDown="window_MouseDown">
</Window>

代码隐藏

using System;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;

namespace WpfApplication1
{
    public partial class MainWindow : Window
    {
        private class HeavyObject : UserControl
        {
            private byte[] x = new byte[750000000];

            public HeavyObject()
            {
                for (int i = 0; i < 750000000; i++ )
                {                    
                    unchecked
                    {
                        x[i] = (byte)i;       
                    }
                }

                // Release optimisation will not compile the array
                // unless you initialize and use it. 
                Content = "Loadss a memory!! " + x[1] + x[1000]; 
            }
        }

        const string msg = " ... nulled the HeavyObject ...";

        public MainWindow()
        {
            InitializeComponent();
            window.Content = msg;
        }

        private void window_MouseDown(object sender, MouseEventArgs e)
        {
            if (window.Content.Equals(msg))
            {
                window.Content = new HeavyObject();
            }
            else
            {
                window.Content = msg;
            }
        }
    }
}

现在运行它并点击窗口。我将代码修改为不使用 GC.Collect() 并在按下鼠标时设置内存。我在 Release模式 下编译并在没有调试器 的情况下运行。

在窗口上慢慢点击。

第一次单击时，您会看到内存使用量增加了 750MBytes。随后的点击会在 .. Nulled the heavy object.. 之间切换消息和 Loads a memory! 只要你慢慢点击。分配和释放内存时会有轻微的滞后。内存使用量不应超过 750MBytes，但当重对象为空时它也不会减少。这是设计使然 GC Large Object Heap is lazy and collects large object memory when new large object memory is needed .来自 MSDN:

If I don't have enough free space to accommodate the large object allocation requests, I will first attempt to acquire more segments from the OS. If that fails, then I will trigger a generation 2 garbage collection in hope of freeing up some space.

在窗口上快速点击

大约 20 次点击。怎么了？在我的 PC 上，内存使用率没有上升，但主窗口现在不再更新消息。它卡住了。我没有遇到内存不足异常，我系统的整体内存使用率保持不变。

在窗口上使用 MouseMove 给系统加压

现在通过更改此 Xaml 将 MouseDown 替换为 MouseMove 事件(根据您的问题代码):

<Window x:Class="WpfApplication1.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525" x:Name="window" MouseMove="window_MouseDown">
</Window>

我可以将鼠标移到它上面一段时间，但最终它会抛出 OutofMemoryException。强制异常的一个好方法是进行多次移动，然后尝试最大化窗口。

理论

好的，这就是我的理论。当您的 UI 线程在消息循环事件 (MouseMove) 中创建和删除内存时，垃圾收集器无法跟上。大型对象堆上的垃圾收集已完成 when memory is needed .这也是一项昂贵的任务，因此应尽可能少地执行。

当在 MouseMove 中执行时，我们注意到快速单击开/关/开/关时的滞后变得更加明显。如果要分配另一个大对象，根据该 MSDN 文章，GC 将尝试收集(如果内存不可用)或开始使用磁盘。

System Is in Low Memory Situation: This happens when I receive the high memory notification from the OS. If I think doing a generation 2 GC will be productive, I will trigger one.

现在这部分很有趣，我猜这里是

Finally, as of right now, the LOH is not compacted as a part of collection, but that is an implementation detail that should not be relied on. So to make sure something is not moved by the GC, always pin it. Now take your newfound LOH knowledge and go take control of the heap.

因此，如果大对象堆未被压缩，并且您在紧密循环中请求多个大对象，是否有可能集合导致碎片化，最终导致 OutOfMemoryException，即使理论上应该有足够的内存？

解决方案

让我们稍微释放 UI 线程，让 GC 空间喘口气。将分配代码包装在异步 Dispatcher 调用中并使用低优先级，例如 SystemIdle。这样，它将仅在 UI 线程空闲时分配内存。

    private void window_MouseDown(object sender, MouseEventArgs e)
    {
        Dispatcher.BeginInvoke((ThreadStart)delegate()
            {
                if (window.Content.Equals(msg))
                {
                    window.Content = new HeavyObject();
                }
                else
                {
                    window.Content = msg;
                }
            }, DispatcherPriority.ApplicationIdle);
    }

使用它我可以在整个表单上移动鼠标指针并且它永远不会抛出 OutOfMemoryException。它是否真的有效或已经“解决”了我不知道的问题，但它值得测试。

总结

• 请注意，此大小的对象将分配到大对象堆上
• 如果没有足够的可用空间，LOH 分配会触发 GC
• LOH 在 GC 循环期间未被压缩，因此可能会出现碎片，导致 OutOfMemoryException，尽管理论上有足够的内存
• 最好重复使用大型对象，不要重新分配。如果那不可能:
  • 在后台线程中分配大型对象以与 UI 线程分离
  • 要让 GC 空间喘口气，使用 Dispatcher 解耦分配，直到应用程序空闲为止