我得到了一个印象，即至少应该从主线程中有一点可控的线程完全不使用Synchronize()：任何尝试这样做的任何尝试几乎都会在一种情况下导致僵局另一个。
因此，应避免使用同步。
也应避免使用。例如，我有一个线程，可以进行一些艰苦的背景工作。我想观看其状态栏的进度，如果用户按下关闭按钮，可以"优雅地"停止它。
我不能使用 FreeOnTerminate := true，因为当线程启动时，我绝对不能调用其任何方法：任何时候它可能会被销毁，我会被访问违规(或完全损坏某些东西(。
因此，线程破坏是主线程的责任。在某种形式的过程中完成所有"完成"工作是合乎逻辑的，并向其指出了终端事件。但这是僵局：我们无法将线程从doterminate中释放，因为在tthread.free中，有一个waitfor在同步onterminate事件完成之前无法完成。
不仅是Onterminate：如果Worker线程中有任何同步呼叫(例如，它想通知我们，某些工作的工作已经完成等(，那么如果此刻主线程正在进行，则可能会陷入僵局用工人线程进行SMTH：他们互相阻挡！
因此，在我理解的情况下，使用同步的唯一方法是将所有调用委托给工人线程！例如，我们使用FreeOnTerminate := true做到这一点，有时它使用Synchronize((告诉我们它的进度，或者它已经完成并将被销毁。只有在这些过程中，我们才能控制它，但是它使" Will"几乎不可能或过度复杂化。
我是否缺少一些东西(一些内部工作有助于克服这些僵局(？因为我有些惊讶：同步((是Delphi多线程手册中描述的第一个方法之一。真的没用吗？
Synchronize有完全有效的用例僵局情况。这是完全可能的，但需要仔细设计。
通常，当您需要工作线程到等待主线程以便在本身继续之前完成工作时，您通常应仅使用Synchronize。在大多数情况下，这不是必需的，通常应该优先使用TThread.Queue。使用Queue将工作发布到主线程中，但随后立即返回而无需等待主线程处理工作。这避免了使用Synchronize的大部分僵局。
Queue的唯一危险是超载主线程。如果您有比主线程更快地向主线程发布工作的工人，那么您可以最终遇到主线程锁定排队工作的情况。