如果我使用TerminateThread函数在Windows上终止一个线程，那么一旦该函数返回或终止asyronronous，该线程是否实际终止？
答案 0 :(得分：5)
定义“实际终止”。文档说线程不能执行任何更多的用户模式代码，所以有效：是的，它终止了，你的代码将不再由该线程执行。
如果您在终止后立即使用“WaitForSingleObject”，我想由于Windows正在进行清理，可能会有一些轻微的延迟。
顺便说一下：TerminateThread是结束线程最糟糕的方式。尝试使用其他一些同步方法，例如告诉线程停止的全局变量，或者例如事件。
答案 1 :(得分：3)
终止线程类似于杀死进程，仅在每个线程级别上。事实上，它可以通过在目标线程中引发（不可捕获）信号来实现。
结果基本相同：您的程序没有任何特定的，可预测的状态。死线程没有太多可以做的。程序的控制流程通常是不确定的，因此在出现线程终止时很难推断出程序的行为。
基本上，除非你的线程正在做一些非常狭窄，特定和受限制的事情（例如每秒增加一次原子计数器），否则没有好的模型需要终止线程，以及线程之后的程序状态终止。
不要这样做。设计您的线程，以便您可以与它们进行通信，以便它们的入口函数可以返回。设计您的程序，以便您最终可以加入所有线程并解决所有问题。
答案 2 :(得分：0)
这是同步通话。这并不意味着它必然会快速返回 - 如果操作系统必须使用其核心间驱动程序来停止线程，可能会涉及一些阻塞（即，它实际上运行在与请求终止的线程不同的核心上）。
在应用程序运行期间从用户代码调用TerminateThread存在问题（与在应用程序/进程终止期间使用它的内核不同），正如其他人明确发布的那样。
我非常努力在应用程序运行期间，使用TerminateThread或任何其他方式永远不会终止线程。应用程序生命周期线程和线程池通常不需要在操作系统在应用程序关闭时销毁它们之前进行任何显式终止。