很好的问题！
不会，两种形式都将（可以）被垃圾回收，因为垃圾回收器不直接查找其他引用中的引用。它只查找所谓的“根”引用... 这包括堆栈上的引用变量（变量在堆栈上，实际对象当然在堆上），CPU寄存器中的引用变量以及类中的静态字段中的引用变量...
所有其他引用变量只有在它们被引用于上述过程发现的一个“根”引用对象的属性中时才会被访问（和垃圾回收）...(或者在由根对象引用的对象或其他引用中引用的对象中...)
因此，只有当其中一种形式在“根”引用的其他地方被引用时，这两种形式才会免受垃圾回收的影响。
我能想到的唯一一种“证明”它的方法（不使用内存跟踪工具）是在方法内创建几十万个这些表单，并在循环内部，同时查看应用程序的内存占用情况，然后退出该方法，调用GC，再次查看内存占用情况。
正如其他人所说，垃圾回收在循环引用方面没有问题。我想补充一点的是，在.NET中泄漏内存的常见地方是事件处理程序。如果你的一个窗体附加了对另一个“活动”对象的事件处理程序，则会有一个对你的窗体的引用，因此该窗体将无法被GC回收。
垃圾收集通过跟踪应用程序根来工作。应用程序根是包含对托管堆上对象的引用（或null引用）的存储位置。在.NET中，根可能是:
CLR维护活动根列表。垃圾收集器会检查托管堆上的对象，并查看哪些对象仍然可以通过应用程序访问，即可通过应用程序根访问。这样的对象被视为已根据。
现在假设您有一个父窗体，其中包含对子窗体的引用，这些子窗体包含对父窗体的引用。此外，假设应用程序不再包含对父窗体或任何子窗体的引用。那么，对于垃圾收集器而言，这些托管对象不再是根，并将在下次垃圾收集发生时被回收。
interface IEventSource
{
event EventHandler SomethingHappened;
}
class MyClass : IDisposable
{
IEventSource m_EventSource;
public IEventSource EventSource
{
get { return m_EventSource; }
set
{
if( null != m_EventSource )
{
m_EventSource -= HandleSomethingHappened;
}
m_EventSource = value;
if( null != m_EventSource )
{
m_EventSource += HandleSomethingHappened;
}
}
}
public Dispose()
{
EventSource = null;
}
// ...
}