当main（）退出时，一个分离的线程会怎样？

假设我先启动一个std::thread，然后启动detach()它，那么即使std::thread那个曾经代表它，但超出范围，线程仍继续执行。

进一步假定该程序不具有用于加入分离线程¹的可靠协议，因此分离线程在main()退出时仍然运行。

我无法在标准（更确切地说，在N3797 C ++ 14草案中）中找到任何内容，该标准描述了应该发生的情况，无论1.10还是30.3都没有相关的措辞。

¹另一个可能等效的问题是：“是否可以再次连接一个分离的线程”，因为无论您想加入哪种协议，都必须在线程仍在运行时完成信令部分，并且OS调度程序可能决定在执行信令后立即使线程休眠一个小时，而接收端无法可靠地检测到线程实际上已完成。

如果main()用分离的线程运行时耗尽是未定义的行为，则除非主线程永不退出^2，否则对的任何使用std::thread::detach()都是未定义的行为。

因此，main()用分离的线程运行时用尽必须具有定义的效果。问题是：在哪里定义了这些效果（在C ++标准中，不是POSIX，不是OS docs，...）。

²分离的线程无法连接（在的意义上std::thread::join()）。您可以等待来自分离线程的结果（例如，通过来自的Future std::packaged_task或通过计数信号量或标志和条件变量），但这不能保证线程已完成执行。事实上，除非你把信令部分进入线程的第一个自动对象的析构函数，也将在一般情况下，是代码（析构函数），其运行后的信号代码。如果操作系统安排主线程使用结果并在分离的线程完成运行所述析构函数之前退出，那么将定义发生什么？

原始问题“ main()退出时分离线程会发生什么”的答案是：

它继续运行（因为标准没有说它已停止），并且定义良好，只要它既不接触其他线程的（automatic | thread_local）变量也不接触静态对象。

似乎允许将线程管理器作为静态对象使用（[basic.start.term] / 4中的注释也要多说了，多亏了@dyp的指针）。

当静态对象的销毁完成时会出现问题，因为执行会进入一种机制，在这种机制中，只有信号处理程序中允许的代码才能执行（[basic.start.term] / 1，第一句）。在C ++标准库中，这只是<atomic>库（[support.runtime] / 9，第二句）。特别是，通常情况下，它会排除 condition_variable（它是实现定义的，是否可以保存以用于信号处理程序，因为它不属于<atomic>）。

除非您此时未展开堆栈，否则很难避免如何避免未定义的行为。

第二个问题“可以再次连接分离的线程”的答案是：

是的，与*_at_thread_exit系列函数（notify_all_at_thread_exit()，std::promise::set_value_at_thread_exit()，...）。

正如问题的脚注[2]所指出的那样，用信号发送条件变量或信号量或原子计数器不足以加入一个分离的线程（从确保在接收到该变量之前执行结束的意义上来说）（例如，通过等待线程发送信号），因为通常在notify_all()条件变量的a 之后，尤其是自动对象和线程本地对象的析构函数之后，将执行更多代码。

运行（如线程做的最后一件事的信号后自动和线程本地对象的析构函数已经-发生）是什么_at_thread_exit功能的系列是专为。

因此，为了避免在没有任何超出标准要求的实现保证的情况下发生不确定的行为，您需要（手动）将分离线程与_at_thread_exit执行信号传递的功能结合在一起，或者使分离线程仅执行对于以下情况安全的代码：信号处理器。

分离线程

根据std::thread::detach：

将执行线程与线程对象分开，允许执行独立继续。线程退出后，将释放所有分配的资源。

来自pthread_detach：

pthread_detach（）函数应向实现指示，在该线程终止时可以回收该线程的存储。如果线程尚未终止，则pthread_detach（）不应使其终止。未指定对同一目标线程的多个pthread_detach（）调用的影响。

分离线程主要是为了节省资源，以防应用程序不需要等待线程完成（例如，守护程序，该守护程序必须运行直到进程终止）：

1. 释放应用程序侧句柄：可以使一个std::thread对象超出范围而无需加入，这通常导致std::terminate()对破坏的调用。
2. 为了使操作系统在线程退出后立即自动清理线程专用资源（TCB），因为我们明确指定了我们对以后再加入线程不感兴趣，因此，一个人不能加入已经分离的线程。

杀死线程

进程终止的行为与主线程的行为相同，这至少可以捕获某些信号。其他线程是否可以处理信号并不那么重要，因为一个线程可以在主线程的信号处理程序调用中加入或终止其他线程。（相关问题）

如前所述，任何线程，无论是否分离，都会在大多数OS上死于进程。可以通过发出信号，通过调用exit()或从main函数返回来终止进程本身。但是，C ++ 11无法也不会尝试定义底层OS的确切行为，而Java VM的开发人员肯定可以在某种程度上抽象出这种差异。AFAIK，奇异的过程和线程模型通常在古老的平台（可能不会将C ++ 11移植到该平台）和各种嵌入式系统中找到，它们可能具有特殊和/或有限的语言库实现以及有限的语言支持。

线程支持

如果不支持线程，std::thread::get_id()则应返回一个无效的id（默认构造std::thread::id），因为有一个普通的进程，该进程不需要运行线程对象，并且a的构造函数std::thread应该抛出std::system_error。这就是我如何结合当今的操作系统来理解C ++ 11的方式。如果有一个具有线程支持的OS，但它的进程中没有产生主线程，请告诉我。

控制线程

如果需要控制线程以正确关闭，则可以使用同步原语和/或某种标志来实现。但是，在这种情况下，我倾向于选择在连接后设置关闭标志，因为通过分离线程来增加复杂性没有意义，因为无论如何在同一时间释放资源（std::thread对象的几个字节）与更高的复杂度以及可能更多的同步原语相比应该是可以接受的。

考虑以下代码：

#include <iostream>
#include <string>
#include <thread>
#include <chrono>

void thread_fn() {
  std::this_thread::sleep_for (std::chrono::seconds(1)); 
  std::cout << "Inside thread function\n";   
}

int main()
{
    std::thread t1(thread_fn);
    t1.detach();

    return 0; 
}

在Linux系统上运行它，从不会打印来自thread_fn的消息。操作系统确实会thread_fn()在main()退出后立即清理。更换t1.detach()用t1.join()总是如预期打印消息。

程序退出后线程的命运是不确定的行为。但是现代操作系统将在关闭进程时清理该进程创建的所有线程。

分离an时std::thread，这三个条件将继续成立：

1. *this 不再拥有任何线程
2. joinable() 将永远等于 false
3. get_id() 将等于 std::thread::id()

当主线程（即运行main（）函数的线程）终止时，该过程终止，所有其他线程停止。

参考：https : //stackoverflow.com/a/4667273/2194843

为了允许其他线程继续执行，主线程应通过调用pthread_exit（）而不是exit（3）来终止。在main中使用pthread_exit很好。当使用pthread_exit时，主线程将停止执行，并将保持僵尸（已取消状态）状态，直到所有其他线程退出。如果在主线程中使用pthread_exit，则无法获取其他线程的返回状态，也无法对其他线程进行清理（可以使用pthread_join（3）完成）。另外，最好分离线程（pthread_detach（3）），以便在线程终止时自动释放线程资源。在所有线程退出之前，不会释放共享资源。