我需要做一个项目，其中应用程序监视传入连接并应用 xml 文档中定义的一些规则。规则要么过滤（阻止或允许）连接，要么重定向特定端口上的流量。为此，我使用了诸如accept 和recv（来自Winsock）之类的函数。所有这些功能都在不同的线程上使用。不过，我想知道，由于进行了所有这些阻塞调用，我应该如何在退出之前清理程序。通常，我要么等到该人通过 X 按钮退出控制台，要么等待用户在主线程中输入某个字符。问题是我不确定如果应用程序退出而仍然有活动线程/如果仍然分配内存/如果套接字正在使用中会发生什么。所有的析构函数都被调用了吗？h 和插座是否正确关闭？还是我需要以某种方式自己做？
谢谢
一般来说，我会说不。不要试图明确地清理诸如套接字、fd、句柄、线程之类的资源，除非你绝对被迫这样做。
确切的行为取决于操作系统以及您终止应用程序的方式。
所有常见的桌面操作系统都会在进程终止时释放操作系统分配给进程的资源。这包括套接字、文件描述符、内存。
在 Windows/Linux 上，如果您从 C/C++ main() 返回而没有任何显式清理，则 crt 代码将调用静态 dtor。非主线程中动态分配对象的 Dtor 不会运行。
用其他语言编写的可执行文件可能表现不同。
如果不是从 main() 返回，而是直接调用 'ProcessExit()' API，则不会调用静态析构函数，因为操作系统没有 dtor 的概念——它不知道或不感兴趣使用什么语言生成可执行文件。
在任何一种情况下，都会调用操作系统来终止您的进程。操作系统通过首先更改所有未运行的进程线程的状态来执行此操作（简单的“傻瓜”版本：），以便它们不再运行。然后停止在其他内核上运行的线程。然后像 fd、套接字这样的 OS 资源被关闭，然后被释放，然后所有进程内存被释放，然后 OS 内核进程/线程对象被释放，然后你的进程不再存在。
如果您在某个线程需要停止应用程序时绝对需要一些或全部 C++/任何 dtors，则必须明确指示其他线程停止，以便可以运行 dtors。我倾向于使用全局可访问的“CloseRequested”布尔值，相关阻塞调用在返回后立即检查。仍然存在说服阻塞调用返回的问题。
一些阻塞调用可以编码为等待多个信号，因此允许调用通过简单的 event/sema/condvar/whatever 信号返回。
一些调用，如 recv()、accept()，可以通过关闭它们正在等待的 fd/socket 来劝说提前返回。
一些调用可以通过“人为”满足他们的等待条件来返回——例如。创建一个临时文件只是为了使文件夹监视器调用返回，以便可以检查“CloseRequested”布尔值。
如果阻塞调用非常顽固以至于无法说服它返回，您可以重新设计您的应用程序，以便在 dtors 中释放的任何关键资源都可以由另一个线程释放 - 也许在另一个线程中创建事物并传递它到阻塞在ctor参数中的线程，类似的东西。
注意：如上所述，线程关闭代码是额外的代码，不会添加到您的应用程序的正常功能中。您应该将显式线程关闭限制为那些拥有绝对必须由显式用户代码释放的资源的线程 - 例如，数据库连接。如果操作系统可以释放资源，则应该允许这样做。操作系统非常擅长在释放它们正在使用的资源之前停止所有进程线程，而用户代码则不然。
在可能的情况下，使用具有超时值的阻塞调用，并让你的线程循环。这为您提供了一个检查关闭条件并优雅退出线程的地方。进程退出时，系统通常会清理句柄。优雅地关闭套接字是有礼貌的，但不是绝对强制的。不这样做的缺点是内核可能需要一段时间来清理专有资源。例如，如果你只是杀死了一个等待 accept() 的线程，然后你的应用程序重新启动，它将无法在同一个端口上成功地 accept()，直到内核清理旧的套接字。