调用TerminateThread时线程实际终止的时间

定义"实际终止"。文档中说，该线程不能再执行任何用户模式的代码，所以很有效：是的，它被终止了，该线程将不再执行任何代码。

如果您在终止后立即对其进行"WaitForSingleObject"，我想由于Windows正在进行清理，可能还会有一些轻微的延迟。

顺便说一句：TerminateThread是结束线程最糟糕的方式。尝试使用其他同步方式，例如告诉线程停止的全局变量，或者事件。

终止线程类似于杀死进程，只是在每个线程级别上。事实上，它可以通过在目标线程中引发（不可捕获的）信号来实现。

结果基本上是一样的：您的程序没有处于任何特定的、可预测的状态。你对死线无能为力。程序的控制流通常变得不确定，因此在线程终止的情况下，很难对程序的行为进行推理。

基本上，除非你的线程正在做一些非常狭窄、特定和受限的事情（例如，每秒增加一次原子计数器），否则没有一个好的模型来描述终止线程的需要，以及线程终止后程序的状态。

不要这样做。设计你的线程，这样你就可以与它们通信，让它们的入口函数可以返回。设计你的程序，这样你就可以最终加入所有线程，并对所有事情负责。

这是一个同步调用。这并不意味着它一定会很快返回——如果操作系统不得不使用其内核间驱动程序来停止线程，可能会出现一些阻塞（即，它实际上运行在与请求终止的线程不同的内核上）。

在应用程序运行期间从用户代码调用TerminateThread存在问题（与在应用程序/进程终止期间使用它的内核不同），正如其他人明确指出的那样。

我非常努力地在应用程序运行期间，使用TerminateThread或任何其他方式，从不终止线程。应用程序生存期线程和线程池通常不需要任何显式终止，操作系统会在应用程序关闭时销毁它们。