C 线程的使用~（上）

C 11 之前，C 语言没有对并发编程提供语言级别的支持，这使得我们在编写可移植的并发程序时，存在诸多的不便。现在 C 11 中增加了线程以及线程相关的类，很方便地支持了并发编程，使得编写的多线程程序的可移植性得到了很大的提高。

C 11 中提供的线程类叫做 std::thread，基于这个类创建一个新的线程非常的简单，只需要提供线程函数或者函数对象即可，并且可以同时指定线程函数的参数。我们首先来了解一下这个类提供的一些常用 API：

1. 构造函数

// ①
thread() noexcept;
// ②
thread( thread&& other ) noexcept;
// ③
template< class function, class... args >
explicit thread( Function&& f, Args&&... args );
// ④
thread( const thread& ) = delete;

构造函数①：默认构造函，构造一个线程对象，在这个线程中不执行任何处理动作

构造函数②：移动构造函数，将 other 的线程所有权转移给新的 thread 对象。之后 other 不再表示执行线程。

构造函数③：创建线程对象，并在该线程中执行函数 f 中的业务逻辑，args 是要传递给函数 f 的参数

任务函数 f 的可选类型有很多，具体如下：

普通函数，类成员函数，匿名函数，仿函数（这些都是可调用对象类型）
可以是可调用对象包装器类型，也可以是使用绑定器绑定之后得到的类型（仿函数）

构造函数④：使用 =delete 显示删除拷贝构造，不允许线程对象之间的拷贝

2. 公共成员函数

2.1 get_id()

应用程序启动之后默认只有一个线程，这个线程一般称之为主线程或父线程，通过线程类创建出的线程一般称之为子线程，每个被创建出的线程实例都对应一个线程 ID，这个 ID 是唯一的，可以通过这个 ID 来区分和识别各个已经存在的线程实例，这个获取线程 ID 的函数叫做 get_id()，函数原型如下：

std::thread::id get_id() const noexcept;

示例程序如下：

#include
#include
#include
using namespace std;void func(int num, string str)
{for (int i = 0; i < 10;   i){cout << "子线程: i = " << i << "num: " << num << ", str: " << str << endl;}
}void func1()
{for (int i = 0; i < 10;   i){cout << "子线程: i = " << i << endl;}
}int main()
{cout << "主线程的线程ID: " << this_thread::get_id() << endl;thread t(func, 520, "i love you");thread t1(func1);cout << "线程t 的线程ID: " << t.get_id() << endl;cout << "线程t1的线程ID: " << t1.get_id() << endl;
}

thread t(func, 520, "i love you");：创建了子线程对象 t，func() 函数会在这个子线程中运行

func() 是一个回调函数，线程启动之后就会执行这个任务函数，程序猿只需要实现即可
func() 的参数是通过 thread 的参数进行传递的，520,i love you 都是调用 func() 需要的实参
线程类的构造函数③ 是一个变参函数，因此无需担心线程任务函数的参数个数问题
任务函数 func() 一般返回值指定为 void，因为子线程在调用这个函数的时候不会处理其返回值

thread t1(func1);：子线程对象 t1 中的任务函数func1()，没有参数，因此在线程构造函数中就无需指定了通过线程对象调用 get_id() 就可以知道这个子线程的线程 ID 了，t.get_id()，t1.get_id()。
基于命名空间 this_thread 得到当前线程的线程 ID

在上面的示例程序中有一个 bug，在主线程中依次创建出两个子线程，打印两个子线程的线程 ID，最后主线程执行完毕就退出了（主线程就是执行 main () 函数的那个线程）。默认情况下，主线程销毁时会将与其关联的两个子线程也一并销毁，但是这时有可能子线程中的任务还没有执行完毕，最后也就得不到我们想要的结果了。

当启动了一个线程（创建了一个 thread 对象）之后，在这个线程结束的时候（std::terminate ()），我们如何去回收线程所使用的资源呢？thread 库给我们两种选择：

加入式（join()）
分离式（detach()）

另外，我们必须要在线程对象销毁之前在二者之间作出选择，否则程序运行期间就会有 bug 产生。

2.2 join()

join() 字面意思是连接一个线程，意味着主动地等待线程的终止（线程阻塞）。在某个线程中通过子线程对象调用 join() 函数，调用这个函数的线程被阻塞，但是子线程对象中的任务函数会继续执行，当任务执行完毕之后 join() 会清理当前子线程中的相关资源然后返回，同时，调用该函数的线程解除阻塞继续向下执行。

再次强调，我们一定要搞清楚这个函数阻塞的是哪一个线程，函数在哪个线程中被执行，那么函数就阻塞哪个线程。该函数的函数原型如下：

void join();

有了这样一个线程阻塞函数之后，就可以解决在上面测试程序中的 bug 了，如果要阻塞主线程的执行，只需要在主线程中通过子线程对象调用这个方法即可，当调用这个方法的子线程对象中的任务函数执行完毕之后，主线程的阻塞也就随之解除了。修改之后的示例代码如下：

int main()
{cout << "主线程的线程ID: " << this_thread::get_id() << endl;thread t(func, 520, "i love you");thread t1(func1);cout << "线程t 的线程ID: " << t.get_id() << endl;cout << "线程t1的线程ID: " << t1.get_id() << endl;t.join();t1.join();
}

当主线程运行到第八行 t.join();，根据子线程对象 t 的任务函数 func() 的执行情况，主线程会做如下处理：

如果任务函数 func() 还没执行完毕，主线程阻塞，直到任务执行完毕，主线程解除阻塞，继续向下运行
如果任务函数 func() 已经执行完毕，主线程不会阻塞，继续向下运行

同样，第 9 行的代码亦如此。

为了更好的理解 join() 的使用，再来给大家举一个例子，场景如下：

程序中一共有三个线程，其中两个子线程负责分段下载同一个文件，下载完毕之后，由主线程对这个文件进行下一步处理，那么示例程序就应该这么写：

#include
#include
#include
using namespace std;void download1()
{// 模拟下载, 总共耗时500ms，阻塞线程500msthis_thread::sleep_for(chrono::milliseconds(500));cout << "子线程1: " << this_thread::get_id() << ", 找到历史正文...." << endl;
}void download2()
{// 模拟下载, 总共耗时300ms，阻塞线程300msthis_thread::sleep_for(chrono::milliseconds(300));cout << "子线程2: " << this_thread::get_id() << ", 找到历史正文...." << endl;
}void doSomething()
{cout << "集齐历史正文, 呼叫罗宾...." << endl;cout << "历史正文解析中...." << endl;cout << "起航，前往拉夫德尔...." << endl;cout << "找到OnePiece, 成为海贼王, 哈哈哈!!!" << endl;cout << "若干年后，草帽全员卒...." << endl;cout << "大海贼时代再次被开启...." << endl;
}int main()
{thread t1(download1);thread t2(download2);// 阻塞主线程，等待所有子线程任务执行完毕再继续向下执行t1.join();t2.join();doSomething();
}

示例程序输出的结果：

子线程2: 72540, 找到历史正文....
子线程1: 79776, 找到历史正文....
集齐历史正文, 呼叫罗宾....
历史正文解析中....
起航，前往拉夫德尔....
找到OnePiece, 成为海贼王, 哈哈哈!!!
若干年后，草帽全员卒....
大海贼时代再次被开启....

在上面示例程序中最核心的处理是在主线程调用 doSomething(); 之前在第 35、36行通过子线程对象调用了 join() 方法，这样就能够保证两个子线程的任务都执行完毕了，也就是文件内容已经全部下载完成，主线程再对文件进行后续处理，如果子线程的文件没有下载完毕，主线程就去处理文件，很显然从逻辑上讲是有问题的。

声明：

本文于网络整理，版权归原作者所有，如来源信息有误或侵犯权益，请联系我们删除或授权事宜。