Delphi应用终止时，正在Event上等待的线程会发生什么情况？

Event对象的状态变化 #

当应用进入退出流程时，没有任何系统层面的机制会主动修改Event对象的状态：

• 如果业务代码没有主动对该Event调用SetEvent/ResetEvent，它的内核状态会一直维持阻塞线程休眠时的无信号状态，既不会被系统自动置位，也不会提前失效。
• 只有当进程完全终止、Event内核对象的最后一个关联句柄被释放时，这个Event才会被系统回收销毁，整个过程不会对正在等待它的线程触发任何唤醒通知。

线程的实际运行逻辑 #

线程是否会等到Timeout、返回什么值，完全取决于应用的退出流程设计：

• 若应用退出时没有主动唤醒Event、也没有强制终结线程，只是在主线程等待所有工作线程完全退出后才结束进程：
  线程会保持在Event的阻塞等待状态，直到预先设置的Timeout时间耗尽，这时候WaitFor类方法会正常返回WAIT_TIMEOUT（对应Delphi TEvent的wrTimeout返回值），之后线程才会检查终止标记、退出循环。这种场景下应用的终止速度会被完全延迟一个Timeout的时长。
• 若应用退出时没有做线程等待、直接让主消息循环结束触发进程收尾：
  系统会在顶层窗口全部销毁后直接对进程执行终止操作，不管工作线程当前是在等Event还是在执行其他代码，都会被强制终结——线程根本没有机会等到Timeout时间耗尽，也不会走到Wait方法的返回值判断逻辑，不会出现非Timeout的异常返回值。

常见认知误区 #

很多开发者误以为进程退出会让正在等待Event的线程直接收到无效句柄的错误返回，实际这只有在主动提前关闭Event句柄的极端场景下才会发生：正常流程的进程终止，是直接给所有线程投递终止APC、切断线程执行上下文，不会触发Wait方法的返回逻辑判断。

实际开发中为了避免不必要的退出延迟，正确的收尾逻辑是：通知工作线程终止后，主动调用SetEvent唤醒处于阻塞等待的线程，让线程不需要等满Timeout就能快速响应终止指令。

内容的提问来源于stack exchange，提问作者SteveS