什么时候应该使用std :: thread :: detach？
有时我必须使用std::thread来加速我的应用程序。 我也知道join()等待一个线程完成。 这很容易理解，但调用detach()和不调用它有什么区别？
我认为没有detach() ，线程的方法将独立工作使用一个线程。
不分离：
void Someclass::Somefunction() { //... std::thread t([ ] { printf("thread called without detach"); }); //some code here }
呼叫与分离：
void Someclass::Somefunction() { //... std::thread t([ ] { printf("thread called with detach"); }); t.detach(); //some code here }
在std::thread的析构函数中， std::terminate被调用，如果：
- 该线程没有join（与
t.join()） - 并没有分离（用
t.detach()）
因此，在执行stream到达析构函数之前，您应该总是join或detach一个线程。
当程序终止时（即main返回），在后台执行的剩余的分离线程不被等待; 而是它们的执行被挂起，并且它们的线程本地对象被破坏。
至关重要的是，这意味着这些线程的堆栈没有被解开 ，因此一些析构函数没有被执行。 根据这些破坏者应该采取的行动，这可能是一个糟糕的情况，就像程序崩溃或被杀害一样。 希望操作系统能够释放对文件的锁等等，但是你可能会损坏共享内存，半写文件等等。
那么，你应该使用join还是detach ？
- 使用
join - 除非你需要更多的灵活性，并且愿意提供一个同步机制来等待自己的线程完成，在这种情况下你可以使用
detach
如果不等待线程完成join ，则应该调用detach ，但线程将继续运行直到完成，然后终止，而不需要主线程专门等待它。
detach基本上会释放所需的资源才能够实现join 。
分离线程时，意味着在退出main()之前不必join() main() 。
线程库实际上将等待每个这样的线程在主要 ，但你不应该关心它。
当你有一个任务必须在后台完成时， detach()主要是有用的，但是你不关心它的执行。 这通常是一些图书馆的情况。 他们可能会默默地创build一个后台工作者线程，并将其分离，所以你甚至不会注意到它。
