2.5 lazy initialization
保护共享数据的初始化过程
lazy initialization （延迟初始化）在单线程的代码中是很常见的。譬如一个共享数据的初始化构建可能会消耗较多的资源，那么对它的每次操作都需要先对它进行检查，如果它已经被初始化了，那么就可以直接使用而不是重新再初始化它。
例如，打开一个文件可能需要消耗较多的资源，如果它已经被打开，那么我们就不需要再次 open 了。
上面的例子并不是线程安全的。在并发代码中假设有A和B两个线程，当 A 线程发现文件没有被打开然后打开文件往里写数据时，B 线程此时应该是不能够打开文件的，但在 B 线程看来，文件确实是被打开了的，因此只要 B 线程抢占到锁，那么它就会往文件里写数据。
因此，打开文件的这一步，需要用互斥量保护起来。
从上面的结果我们可以看到，我们所做的修改依然不是线程安全的。因为当线程 A 打开文件后，离开了 mtxFile 的保护域时，线程 B 可能在这个时候拿到了 mtxFile 然后打开文件。为此，我们需要将 is_open 也加入锁的范围内
可以看到，上面的这份代码就是线程安全的。现在我们考虑性能上的问题。我们频繁地创建锁并加锁解锁操作会消耗大量的系统资源，C++标准库为此提供了较好的解决方案。
std::call_once
与 std::call_once 相适配的是 std::once_flag，它会比互斥量消耗的资源更少，特别是当初始化完成以后。
- std::mutex 和 std::once_flag 对象不能拷贝和移动。
于是，方案修改为：
使用 std::call_once 可以确保 lambda 表达式在并发程序中只会被一个线程调用一次，这就是我们所说的 lazy initialization。
通常，我们也会将 std::call_once 和要保护的数据放在一个类中，用来延迟初始化。借用书中的代码：
在本例中，第一次调用 send_data 和 receive_data 时会完成线程的初始化。
std::call_once 的替代方案
在只需要一个全局实例的情况下，多线程可以安全地调用 getInstance 函数，不用担心数据竞争。