为什么Thread.Join（）在UI线程上调用时不挂起我的应用程序？
在我的理解中（我在线程方面不擅长），Join（）阻塞调用线程，直到调用Join（）的线程返回。
如果这是真的并且从UI线程调用了Join（），则为某些长时间运行的操作创建新线程没有任何意义。 有些问题，那些问为什么Join（）挂起应用程序。 这看起来很自然。
顺便说一下，即使它看起来很自然，我的应用程序也没有相应的行为。 它不会挂起我的应用程序。
没有挂起应用程序的线程的代码： –
string retValue = ""; retValue = LongRunningHeavyFunction(); txtResult.Text = retValue; 带有不挂应用程序的线程的代码： –
string retValue = ""; Thread thread = new Thread( () => { retValue = LongRunningHeavyFunction(); }); thread.Start(); thread.Join(); txtResult.Text = retValue;
上面的代码很好，没有挂起应用程序 函数调用大约需要15-20秒。 为什么应用程序不挂起？
这对我来说不是问题; 实际上这是一个好消息。 但我只是不明白它有什么不同？ 它与我阅读和学习的内容不符。
如果重要的话，我正在使用DotNet Framework 4.0。
由于Main（）入口点上的[STAThread]属性，程序的UI线程创建了一个STA，一个单线程的公寓。 还要查看Thread.SetApartmentState（）。 STA对非线程安全的代码非常友好，通常是您无法看到的代码，因为它是另一个程序的一部分。
就像将数据放在剪贴板上的代码一样，在Drag + Drop操作中提供数据，在显示OpenFiledialog时激活的shell扩展，像WebBrowser这样的控件需要客户端代码才能拥有调度程序以便它可以提升DocumentCompleted事件，侦听通知的Windows挂钩，依赖可访问性api实现UI自动化的代码或屏幕阅读器。 等等。
即使涉及不同进程中的多个线程，也不需要该代码是线程安全的。 一般来说，编写线程安全的代码很困难，因为没有任何好的方法让作者测试它，所以它变得非常困难。 他无法对可能激活其代码的每个可能程序进行测试。 公寓是为解决这个问题而发明的，无需编写线程安全的代码。
STA是您的承诺 。 你发誓，交叉你的心 – 希望死的风格，你的UI线程表现良好，它必须有一个调度程序（也称为泵消息循环），绝不能阻止。 调度程序是以线程安全的方式运行代码所必需的，它是生产者 – 消费者问题的通用解决方案。 而且你必须永远不要阻止，因为这样做很可能会导致其他程序员代码死锁。 您无法调试的死锁类型，因为您没有该代码的源代码。 Winforms，WPF或Modern UI程序的UI线程始终实现此承诺，这是UI线程与您可能使用的任何其他线程不同的基本原因。
足够的介绍，Thread.Join（）调用块，从而违反了STA合同。 这是非常糟糕的，所以CLR设计师做了一些事情 。 正如你所发现的那样，他们通过不阻塞来实现Join（）， 因为它是在STA线程上调用的。
他们通过实现Application.DoEvents（）的风格来实现这一点。 这是避免UI线程无法响应的一种非常臭名昭着的方法。 它可能导致很难诊断重入错误。 它们的版本并不像DoEvents（）那么糟糕，它对于允许调度哪种消息以最小化风险非常有选择性。
这通常没问题，但是从来没有你想要故意测试自己。 重新入侵的错误是非常严重的错误，与线程竞争错误一样糟糕。 因此，您应该永远不要在UI线程上使用Thread.Join（）。 .NET Framework为BackgroundWorker和Task类提供了很好的替代方案，它们在线程完成时为您提供了执行代码的非常好的方法（无论是在 Join（）调用之后）。