C++编程实践——多线程变量共享问题展开分析
一、问题现象描述
在C++编程的技术点中，多线（进）程的编程是一个非常让人上头的内容。这种情况其实还可以拓展到一些抽象的场景，比如信号、消息和异步等情况。它们看上去和多线程关系不大，但其实内部和多线程都有着密不可分的关系（注意，没说联系，因为有些是类似与多线程应用的情况）。
在多线程编程中，有经验的开发者可能遇到过这种情况，当它们通过一个变量来交换某个状态或数据时，往往在开发和测试时都是没有问题的，但在部署到生产上时，一个月内偶尔会有一两次出现异常的问题。甚至在某些特殊情况下，还会出现偶尔崩溃的情况。这种问题，非常难于定位，而且非常不容易解决。
二、原因分析和说明
上面的问题表面看来没有什么复杂的，但其实内部有多种可能。而这些可能往往有的时候都想不到其中涉及到的知识面的宽度。下面对其中主要的进行一下分析说明：
- 多线程竞态
Race condition，这种情况是开发者最容易想到的，也是最容易解决类似的问题的一种相对有效的方法。但这种方式让开发者有很不爽的地方，就是太重。不光影响效率还增加了代码的复杂度。这就需要开发者根据实际情况来斟酌选择。 - 缓存读写
也就是常见的内存可见性的问题，就是在多线程的情况下，由于缓存的存在，导致更新无法被及时的响应，从而导致数据的不可见。另外还有缓存Line的问题，导致缓存被意外更新的情况。 - 指令乱序
这种情况虽然不少见，但比较容易被人理解的是单实例中double check的问题 - 原子破坏性
这种情况比较少见，但同样出现问题不好调试。比较典型的是就是早期某些第三方提供的在32位系统上用多个int来模拟int64甚至更长的长整型数据时，导致的数据异常。
三、定位问题
解决问题的方法是先找到并确定问题，然后再根据实际问题的情况来解决这些问题。对于问题的查找和调试可以采用下面的方法：
- 内存控制
现代计算机中一般是多核系统，为了控制内存读写，可以使用内存屏障，比如使用：
#defineMEMORY_BARRIER()asmvolatile("mfence":::"memory")- 打印日志
在特定的代码中，对于不稳定态的情况下可以增加日志相关的代码。不过，有一点麻烦的是要考虑打印的线程安全性。 - 编译器中处理
有两种情况，一种是启用编译器屏障；另外一种是严格控制编译器的优化。前者可以使用：
// 禁止编译器重排序#defineCOMPILER_BARRIER()asmvolatile("":::"memory")// 在代码中thread_shared_data=new_data;COMPILER_BARRIER();后者则要根据情况来确定与编译器优化的关系的大小，并根据情况来缩小优化的控制。
四、解决办法
只有了解你的敌人，才能更好的打败他。既然明白了问题的来源，那么解决的思路也就有了，主要有：
- 使用锁
正如上面所分析的，除了太重，没有别的坏处。这算是最安全的方法 - 使用原子变量
这其实可以理解成第一种的一种轻量版。没有什么特别说明的 - 使用volatile关键字
这种一般用于简单的场景下的操作，特别是在IO的操作过程中，不过不要迷信它。记住这一点就够了 - 其它
在某些特殊场景如信号、消息等中，可以利用一些特定的方法如信号的屏蔽以及事件处理等来控制。这里就不再展开了。
总之，解决问题的方法有很多，细节就看开发者自己确定问题后能够采取哪种方法来应对了。不必拘泥于教条和书本。
五、总结
正如大家看到一个苹果上有一个小黑点，未必认为会是什么问题，亦或者认为削皮时多削一点就好了。但实际上打开后，内部可能整个苹果都烂得差不多了。本文提到的问题，其实也是这种情况，虽然问题不大，但真要解决进去，会发现可能会涉及到不少的知识面。与诸君共勉！