Item 38：Be aware of varying thread handle destructor behavior
Item37中说明了可结合的std::thread对应于执行的系统线程。未延迟（non-deferred）任务的future（参见Item36）与系统线程有相似的关系。因此，可以将std::thread对象和future对象都视作系统线程的句柄（handles）。
从这个角度来说，有趣的是std::thread和future在析构时有相当不同的行为。在Item37中说明，可结合的std::thread析构会终止你的程序，因为两个其他的替代选择——隐式join或者隐式detach都是更加糟糕的。但是，future的析构表现有时就像执行了隐式join，有时又像是隐式执行了detach，有时又没有执行这两个选择。它永远不会造成程序终止。这个线程句柄多种表现值得研究一下。
我们可以观察到实际上future是通信信道的一端，被调用者通过该信道将结果发送给调用者。（Item39说，与future有关的这种通信信道也可以被用于其他目的。但是对于本条款，我们只考虑它们作为这样一个机制的用法，即被调用者传送结果给调用者。）被调用者（通常是异步执行）将计算结果写入通信信道中（通常通过std::promise对象），调用者使用future读取结果。你可以想象成下面的图示，虚线表示信息的流动方向：
但是被调用者的结果存储在哪里？被调用者会在调用者get相关的future之前执行完成，所以结果不能存储在被调用者的std::promise。这个对象是局部的，当被调用者执行结束后，会被销毁。
结果同样不能存储在调用者的future，因为（当然还有其他原因）std::future可能会被用来创建std::shared_future（这会将被调用者的结果所有权从std::future转移给std::shared_future），而std::shared_future在std::future被销毁之后可能被复制很多次。鉴于不是所有的结果都可以被拷贝（即只可移动类型），并且结果的生命周期至少与最后一个引用它的future一样长，这些潜在的future中哪个才是被调用者用来存储结果的？
因为与被调用者关联的对象和与调用者关联的对象都不适合存储这个结果，所以必须存储在两者之外的位置。此位置称为共享状态（shared state）。共享状态通常是基于堆的对象，但是标准并未指定其类型、接口和实现。标准库的作者可以通过任何他们喜欢的方式来实现共享状态。
我们可以想象调用者，被调用者，共享状态之间关系如下图，虚线还是表示信息流方向：
共享状态的存在非常重要，因为future的析构函数——这个条款的话题——取决于与future关联的共享状态。特别地，
- 引用了共享状态——使用
std::async启动的未延迟任务建立的那个——的最后一个future的析构函数会阻塞住，直到任务完成。本质上，这种future的析构函数对执行异步任务的线程执行了隐式的join。 - 其他所有future的析构函数简单地销毁future对象。对于异步执行的任务，就像对底层的线程执行
detach。对于延迟任务来说如果这是最后一个future，意味着这个延迟任务永远不会执行了。
这些规则听起来好复杂。我们真正要处理的是一个简单的“正常”行为以及一个单独的例外。正常行为是future析构函数销毁future。就是这样。那意味着不join也不detach，也不运行什么，只销毁future的数据成员（当然，还做了另一件事，就是递减了共享状态中的引用计数，这个共享状态是由引用它的future和被调用者的std::promise共同控制的。这个引用计数让库知道共享状态什么时候可以被销毁。对于引用计数的一般信息参见Item19。）
正常行为的例外情况仅在某个future同时满足下列所有情况下才会出现：
- 它关联到由于调用
std::async而创建出的共享状态。 - 任务的启动策略是
std::launch::async（参见Item36），原因是运行时系统选择了该策略，或者在对std::async的调用中指定了该策略。 - 这个future是关联共享状态的最后一个future。对于
std::future，情况总是如此，对于std::shared_future，如果还有其他的std::shared_future，与要被销毁的future引用相同的共享状态，则要被销毁的future遵循正常行为（即简单地销毁它的数据成员）。
只有当上面的三个条件都满足时，future的析构函数才会表现“异常”行为，就是在异步任务执行完之前阻塞住。实际上，这相当于对由于运行std::async创建出任务的线程隐式join。
通常会听到将这种异常的析构函数行为称为“std::async来的futures阻塞了它们的析构函数”。作为近似描述没有问题，但是有时你不只需要一个近似描述。现在你已经知道了其中真相。
你可能想要了解更加深入。比如“为什么由std::async启动的未延迟任务的共享状态，会有这么个特殊规则”，这很合理。据我所知，标准委员会希望避免隐式detach（参见Item37）的有关问题，但是不想采取强制程序终止这种激进的方案（就像对可结合的sth::thread做的那样（译者注：指析构时std::thread若可结合则调用std::terminal终止程序），同样参见Item37），所以妥协使用隐式join。这个决定并非没有争议，并且认真讨论过在C++14中放弃这种行为。最后，决定先不改变，所以C++11和C++14中这里的行为是一致的。
future的API没办法确定是否future引用了一个std::async调用产生的共享状态，因此给定一个任意的future对象，无法判断会不会阻塞析构函数从而等待异步任务的完成。这就产生了有意思的事情：
//这个容器可能在析构函数处阻塞，因为其中至少一个future可能引用由std::async启动的
//未延迟任务创建出来的共享状态
std::vector<std::future<void>> futs; //std::future<void>相关信息见条款39
class Widget { //Widget对象可能在析构函数处阻塞
public:
…
private:
std::shared_future<double> fut;
};当然，如果你有办法知道给定的future不满足上面条件的任意一条（比如由于程序逻辑造成的不满足），你就可以确定析构函数不会执行“异常”行为。比如，只有通过std::async创建的共享状态才有资格执行“异常”行为，但是有其他创建共享状态的方式。一种是使用std::packaged_task，一个std::packaged_task对象通过包覆（wrapping）方式准备一个函数（或者其他可调用对象）来异步执行，然后将其结果放入共享状态中。然后通过std::packaged_task的get_future函数可以获取有关该共享状态的future：
int calcValue(); //要运行的函数
std::packaged_task<int()> //包覆calcValue以异步运行
pt(calcValue);
auto fut = pt.get_future(); //从pt获取future此时，我们知道future没有关联std::async创建的共享状态，所以析构函数肯定正常方式执行。
一旦被创建，std::packaged_task类型的pt就可以在一个线程上执行。（也可以通过调用std::async运行，但是如果你想使用std::async运行任务，没有理由使用std::packaged_task，因为在std::packaged_task安排任务并执行之前，std::async会做std::packaged_task做的所有事。）
std::packaged_task不可拷贝，所以当pt被传递给std::thread构造函数时，必须先转为右值（通过std::move，参见Item23）：
std::thread t(std::move(pt)); //在t上运行pt这个例子是你对于future的析构函数的正常行为有一些了解，但是将这些语句放在一个作用域的语句块里更容易看：
{ //开始代码块
std::packaged_task<int()>
pt(calcValue);
auto fut = pt.get_future();
std::thread t(std::move(pt)); //见下
…
} //结束代码块此处最有趣的代码是在创建std::thread对象t之后，代码块结束前的“…”。使代码有趣的事是，在“…”中t上会发生什么。有三种可能性：
- 对
t什么也不做。这种情况，t会在语句块结束时是可结合的，这会使得程序终止（参见Item37）。 - 对
t调用join。这种情况，不需要fut在它的析构函数处阻塞，因为join被显式调用了。 - 对
t调用detach。这种情况，不需要在fut的析构函数执行detach，因为显式调用了。
换句话说，当你有一个关联了std::packaged_task创建的共享状态的future时，不需要采取特殊的销毁策略，因为通常你会代码中做终止、结合或分离这些决定之一，来操作std::packaged_task的运行所在的那个std::thread。
请记住：
- future的正常析构行为就是销毁future本身的数据成员。
- 引用了共享状态——使用
std::async启动的未延迟任务建立的那个——的最后一个future的析构函数会阻塞住，直到任务完成。