表2-2 Og优化级别开启的优化选项

表2-3 O2优化级别在O1优化级别的基础上额外开启的优化选项

表2-4 Os优化级别会开启几乎所有的O2级优化选项，除了以下经常会增加代码大小的选项

       上述优化内容是造成Debug版本和Release版本下代码缺陷表现不同的主要原因，Debug版本下的源代码是没有被优化的，基本上是直接翻译的，而Release版本下的源代码被编译器进行了一系列优化，使最终生成的机器码发生了巨大的变化，因此当代码有缺陷时，两种版本下的运行结果就可能表现出差异。

3.代码缺陷在Debug版本和Release版本下的差异表现

       下面对几种常见的、容易引起Debug版本和Release版本下表现不同的代码缺陷进行分析。

3.1. 变量未初始化

       对于未初始化的变量，Debug版本下会默认对其进行初始化，而Release版本下则不会，所以就有个常见的问题，局部变量未初始化时，Debug版本和Release版本表现有所不同，本文给的代码示例如下所示。

1 bool func() {
2     bool found;
3     for (int i = 0; i < vec.size(); ++i) {
4         if (vec[i] == 3) {
5             found = true;
6         }
7     }
8     return found; 
9 }

       Debug版本下该代码可能会运行正常，因为对于某些开发环境或编译器，其设置可能会为了调试而“填充”未初始化的局部变量，以便在调试时更容易发现未初始化变量的问题，如VS开发环境在Debug版本下，会将栈初始化为0xCC(0xCC为单步调试指令的机器码)，但是这种“填充”的值并不是C/C++标准规定的。而Release版本下该代码就可能会返回错误的结果，因为found局部变量在Release版本下没有初始化。

       类似的，如果未被初始化的变量用作控制变量将导致流程导向不一致，用作数组下标将会使程序崩溃，更加可能是造成其他变量的不准确而引起其他的错误。

3.2.未知因素修改变量

       优化程序为了使程序性能提高，常把一些变量放在寄存器中(类似于register关键字的作用)，其它线程只能对该变量所在的内存进行修改，而寄存器中的值没变，如果你的程序是多线程的，或者你发现某个变量的值与预期的不符，而你确信已正确的设置该值，则很可能是遇到了这样的问题，这种错误有时会表现为程序在最快优化时出错，而最小优化时正常。

       在本文给出的代码示例中，开辟一个子线程用于修改一个全局变量，主线程接到全局变量变化时退出，然而在却发现在Release版本下，主线程的is_ok变量一直不会变。

 1 static bool is_ok = false;
 2 void t1() {
 3     while(1){
 4         if(!is_ok) is_ok = true;
 5     }
 6 }
 7 
 8 int main() {
 9     std::thread th1(t1);
10     for(int i = 0; i < 10; i ++){
11         is_ok = false;
12         while(1){
13             if(is_ok) break;
14         }     
15     } 
16     th1.join();
17 
18     return 0;
19 }

       这里其实就是编译器的优化导致的，is_ok变量被优化掉了。编译器为了提高程序性能，在优化代码时可能会将变量的值存储在寄存器中，而不是每次都从内存中读取，但是，如果这个变量的值可能在程序的其他部分(例如由中断服务程序或并发线程)被改变，那么使用存储在寄存器中的副本就会导致错误。类似的，可能被优化为寄存器变量的包括临时中间变量、循环计数器、函数参数、指针(包括this指针)、引用、公共子表达式等。

       volatile关键字可以告诉编译器不要进行上述优化，volatile是一种类型修饰符，用它声明的类型变量表示可以被某些编译器未知的因素更改，比如：操作系统、硬件或者其它线程等。遇到这个关键字声明的变量，编译器对访问该变量的代码就不再进行优化，从而可以提供对特殊地址的稳定访问。当要求使用volatile声明的变量的值的时候，系统总是重新从它所在的内存读取数据，即使它前面的指令刚刚从该处读取过数据，而且读取的数据立刻被保存，如下图3-1所示。

图3-1 volatile底层原理示意图

       当使用volatile阻止is_ok变量优化时，线程启动之后会从主内存中读取变量的副本存在工作内存中，通过read指令读取、load指令载入工作内存，子线程会对is_ok取反操作，通过use指令读取工作内存的变量，通过assign指令进行计算，把计算的新值赋值给工作内存的变量赋值，若共享变量是volatile声明的，就会把新值立即回写到主内存，通过store指令读取工作内存的变量传入到主内存，然后在主内存中通过write指令给变量赋值。

       所有的读写请求都通过总线，由总线传递给所有的CPU，然后CPU去“嗅探”这些请求，当感知到数据变化时将自己的缓存的数据置为失效，当需要回写或者使用时会重新从内存中读取，即通过所谓的总线嗅探机制和缓存一致性协议来保证数据的一致性。

3.3.数组越界

       若一个函数中，存在某些未被使用的变量，且函数内有数据溢出问题，则Debug版本下可能不会产生问题，因为不会对该变量进行优化，它在栈空间中占有一定字节的空间，但是Release版本下就可能会出问题，因为Release版本下可能会优化掉此变量，栈空间相应变小，数据溢出就会导致栈内存损坏，有可能会产生奇奇怪怪的错误。例如：

1 void func(){
2     char buffer[10];
3     char counter;
4     strcpy(buffer, "abcdefghik");  // 11-byte copy, including "\0"
5 }

       在Debug版本下，最后一个终止的空字符"\0"要越界放入数组外，可能把其放入counter变量的位置，而在Release版本下，可能会把counter变量放在寄存器中，就没有空间让"\0"存放，从而造成崩溃。

       在本文的问题背景中，存放数据的是一个类似二维数组的结构，其中某一维的数组越界时，若处于Debug版本，则越界的数据可能放入了后面其它未被使用维度的数组空间内，而当处于Release版本时，那些未被使用的数组空间就被优化掉了，从而让越界的数据破坏了栈内其它的数据，造成崩溃。

3.4.宏定义变化

       对于C++程序，开发者在Debug版本下会使用assert来及时发现潜在的问题，而在Release版本下会禁用assert，此时程序遇到问题后，可能不会及时暴露，而是继续运行，到后期再产生奇奇怪怪的错误，编译器可以在Release版本下定义NDEBUG宏，预处理器会根据该宏来判断是否开启assert检查，从而可能造成两种编译版本下运行现象的差异。

4.如何“调试”Release版本的程序

       遇到程序在Debug版本下成功，在Release版本下失败，显然是一件很让人沮丧的事，而且往往无从下手。如果根据前面章节的分析，结合缺陷的具体表现，很快找出了原因，固然很好，但如果一时找不出原因，以下给出了一些在这种情况下的策略：
       1、前面已经提过，Debug版本和Release版本在本质上只是优化选项的差别，因此我们可以修改Release版本的优化选项来缩小错误范围，按照前文表2-1至表2-4中的内容，把Release版本的选项逐个添加，判断是何种优化引起的差异，从而有针对性的查找缺陷。

       2、由于开发者通常在Debug状态下开发软件，为避免留最后代码量太多，时间又很紧的情况下出现类似的问题，我们最好在编程过程中就要时常注意测试Release版本。

       3、重视编译器给出的警告信息，通常这些警告就是你程序中隐藏的缺陷，它们可能会在一定条件下才表现出问题，比如强制类型转换导致的数据丢失或精度降低，可能会让程序在数据计算时才出现意外的结果。