这个问题似乎可能是重复的，但我无法find一个。 如果我错过了以前的问题，道歉。
在Java中，我有大部分经验，如果你的main（）分支了一个线程，并立即返回，那么进程将继续运行，直到进程中的所有（非守护进程）线程都停止。
在C ++中，看起来并不是这样 – 一旦主线程返回进程正在终止，其他线程仍在运行。 对于我目前的应用程序，这是很容易解决与pthread_join()的应用程序，但我想知道是什么原因导致此行为。 这个编译器（gcc）是特定的，pthreads特定的，还是在C ++已经实现的大多数/所有平台上共享的一种行为？ 这种行为是可以在pthreads中configuration的（我已经通过pthread_attr_*()函数的pthread api查看过，没有看到任何相关的东西。
完全独立的问题，但是当你在这里…什么人会使用pthread_detatch()的？
是。 在现代的linux（更重要的是更新版本的GNU libc）中， exit_group是main返回时使用的系统调用，而不是简单的exit 。 描述如下：
这个系统调用相当于exit（2），除了它不仅终止调用线程，还终止调用进程线程组中的所有线程。
值得注意的是，目前的c ++标准没有提到线程，所以这个行为不是c ++特有的，而是特定于你的特定实现。 也就是说，我亲眼见过的每个实现都会在主线程终止时终止所有线程。
编辑：这也是值得注意的乔纳森·莱弗勒的答案指出，POSIX标准确实指定了这种行为，所以对于线程使用pthreads的应用程序当然是正常的。
编辑：回答有关pthread_detach的后续行动。 基本上它被认为是一个资源泄漏，如果你不加入一个不分离的线程。 如果你有一个长期运行的任务，你不需要“等待”，而只是“结束时结束”，那么你应该分离它，当它没有连接终止时不会有资源泄漏。 手册页说：
pthread_detach（）函数将线程标识的线程标记为已分离。 当分离的线程终止时，其资源会自动释放回系统，而不需要另一个线程与终止的线程连接。
所以，一个快速而肮脏的答案是：“当你不在乎什么时候结束，分离它，如果另一个线程在结束，并且必须等待它结束，那就不要。
POSIX标准说：
§3.297过程终止
有两种进程终止：
当用exit（），_exit（）或_Exit（）函数请求时，通过main（）返回正常终止。 或者当进程中的最后一个线程通过从其启动函数返回，通过调用pthread_exit（）函数或通过取消来终止时。
当abort（）函数请求时或接收到一些信号时，发生异常终止。
第一个正常终止条件适用。 （请注意，C ++（1998，2003）标准没有提到线程）。
POSIX标准（再次）说：
pthread_detach（）函数应该向实现指示线程终止时线程线程的存储可以被回收。 如果线程还没有终止，pthread_detach（）不会导致它终止。
理由说：
应该最终为每个创建的线程调用pthread_join（）或pthread_detach（）函数，以便与线程关联的存储可以被回收。
有人建议，“分离”功能是不必要的; detachstate线程创建属性就足够了，因为线程不需要动态分离。 但是，至少需要两种情况：
在pthread_join（）的取消处理程序中，为了分离pthread_join（）等待的线程，几乎必须有一个pthread_detach（）函数。 没有它，有必要让处理程序做另一个pthread_join（）来尝试分离线程，这将延迟无限期的取消处理，并引入一个新的调用pthread_join（），它本身可能需要取消处理程序。 在这种情况下，动态分离几乎是必不可少的。
为了分离“初始线程”（可能需要在建立服务器线程的进程中）。
这不是编译器特有的，是标准的行为; 当main（）退出时应用程序终止，所以如果你想阻止应用程序终止，你需要main（）来阻塞，直到所有的线程都被终止，你通过加入这些线程来完成。 当你调用pthread_create时，它为该线程分配资源。 除非您执行pthread_join（阻塞直到线程终止）或pthread_detach（这会导致线程在该线程退出时自动释放资源），否则资源不会被释放。 当你启动一个后台线程时，你应该使用pthread_detach，当它的任务完成并且你不需要等待的时候，后台线程将会终止。
为了使这个更具体些，假设你有几个线程执行计算，然后以某种方式聚合结果。 这将是一个情况下，你会使用连接，因为你需要线程的结果继续。 现在，考虑一个线程侦听套接字并处理传入请求的情况，直到一个标志指示该线程应该退出。 在这种情况下，您可以使用pthread_detach，因为没有任何事情需要线程终止以便继续，所以与该线程关联的资源应该自动消失。