问哪些编程实践会影响窗口句柄的数量？

EN

但是，我找不到任何关于创建窗口句柄的原因的文档。

这可能是因为.net是一个抽象。

在Win32的“真实”世界中，窗口句柄由类型HWND表示，几乎所有东西都可以使用它。每个按钮、菜单等都可以有一个HWND。

实际上，这并不完全正确。您可以创建的每个对象类(在C Windows API中)都有一个句柄。每个类通常只绘制整个控件-但是，某些控件可能绘制更复杂的控件，如额外的按钮。他们可以创建另一个窗口(控件)，也可以直接使用GDI来绘制。

所以，并不是你看到的所有东西都会产生HWND --但大多数事情都会产生。

有趣的是，您可能想知道在C/Win32中创建控件需要使用CreateWindow()。一切都是一扇窗。

现在回到您的.net应用程序。如果您所依赖的控件通过其底层CreateWindow调用创建了大量对象，那么您将发出大量HWND变量，并最终耗尽唯一标识符。

Mark Russinovich介绍了他的pushing the limits of Windows中的实际限制，他故意尝试耗尽他的应用程序的分配。

那么是什么编程实践导致了这种情况呢？创建的窗口对象太多。这可能并不对应于应用程序窗口意义上的实际Windows -相反，它对应于控件的数量。避免这种情况的唯一方法是减少使用，或者如果是第三方导致问题，则根据一次显示内容的实际限制来设计应用程序。

另一种方法是生成您自己的控件，而不是使用子控件来绘制它们。然而，这可能是大量的工作。

简而言之，窗口句柄被赋予每个交互的UI元素。每个真实的窗口，每个文本框，网格单元，按钮，菜单等等。尽管非交互式控件不需要窗口句柄，但如果没有正确编写，它们可能仍然会使用它们。

通常情况下，很难达到窗口句柄限制。如果发生这种情况，并且您的应用程序不是特别的UI密集型，这通常意味着您正在泄漏句柄。如果您使用编写糟糕的可视组件库，而不是在应该发布资源的时候发布资源，就会发生这种情况。窗口句柄是一种非托管资源，必须注意在不再需要时释放它。如果你碰巧使用了一个库，并且观察到句柄泄漏，最好的办法是更换库。它通常比听起来更难，所以作为一个糟糕的变通办法，你可以尝试强制垃圾收集器收集对象，并希望所有非托管资源在终结器/析构函数中被释放。

GC.Collect();

不能保证这会有帮助，因为如果您正在使用的控件编写得很糟糕，即使在它们的终结器中，它们也可能不会释放句柄。同样，这是一种糟糕的做法，但如果您别无选择，则可能会有所帮助。

如果您只使用标准的.NET控件，请确保在使用后对每个窗体执行Close()操作，而不是仅仅将其隐藏。这将处理非对话框窗体及其所有控件，如果它们是标准控件，则不会发生泄漏。对话框窗体需要在代码中处理。有关详细文档，请访问here。