记录一个关于程序被优化的奇葩Bug

欢迎转载，转载请注明出处！原文地址

Follow me on GitHub ^_^

问题描述

该问题正常情况下不会遇到，因为正常情况下没人会写这样的代码（结果还是有人写了）

两个朋友操作时间时遇到了一个类似的问题：

• 一个是同样的一段简单且需要多次调用通过时间间隔来执行的代码写在函数中再调用和直接写被调用处的执行结果不同（写在函数中的代码相当于没有起作用）

• 另一个是直接将这段的代码写在被调用处偶尔能够正常运行，但写在函数中却无法正常运行；但如果是在vs2013中调试运行是正常运行的，直接打开exe可执行文件程序无法正常运行

在帮他们调这个Bug发现了一些关于程序被优化的问题

问题代码复现

奇怪了！无论我怎么努力，程序永远都是正常运行！！！

我的测试代码很简单，只有一个main()函数和测试代码，而两个朋友的代码总体都比较复杂只是这一块儿简单

所以无法再现这个问题

问题分析

由于朋友的工程比较大、代码比较复杂所以考率到程序被优化的情况，由于他们的判断时间间隔的来操作的内容在程序开始时获取到的时间差是不同的，而且是不断循环来判断，也就是很有可能因为前面很多次调用函数例的时间判断间隔不够，所以都是相同的结果（0），所以后面的结果被默认全置为了0，导致就算时间间隔够了得到的结果也是0。

而通过在程序开始时使用Sleep()函数将程序执行延迟一会儿，使得时间间隔足够的方法程序就运行成功了

所以问题也很明了了，大量重复的调用由于返回的结果完全一样导致被优化成了后面遇到这样的调用直接把前面相同的返回值拿来用了

我的思考

• 首先程序开始时应该干一些初始化或引导、铺垫的工作再开始主体逻辑的执行

• 在通过时间间隔来制造延时的逻辑应该让程序在第一次循环时能够执行相应的操作，然后再更新时间继续循环使用时间间隔来制造延时，而不是一开始就先让时间间隔不够，然后再通过大量不做任何工作的循环后使时间间隔大于限制的时间间隔后来执行相应的操作

所以作为一个程序猿写代码也要符合正常人的思维，该做的铺垫还是要做的（给同类使用的程序可以不用，思维和正常人不同），比如说不给其他人介绍自己就问别人信息是没有人愿意理的。^_^