今天客户反应之前做的一个项目中,有一个功能时能时不能,于是按照描述,在自己电脑上进行了相应的测试,可是发现问题难以重现。后来按着客户的环境开了个虚拟机(XP SP3)进行配置,问题重现了。
可是在自己电脑上(WIN7 64)却不会出现。难道是系统引发的问题?可是依据项目以前的案例,在XP上运行是OK的。那这是什么原因?思来想去,只得打开代码,挨个查找,最后把可能的地方都一一作了调整,并输出日志,发现问题集中在了一个数据通讯的线程中。
这个线程有开启,但是不进入循环,结果是一进去就退出来了。下面是部分代码
private void start() { Thread communicateThread = GetSingleThread((ParameterizedThreadStart)delegate { communicate(); }); if (!communicateThread.IsAlive) { communicateThread.IsBackground = true; communicateThread.Start(); } runThread_ = true; } private void communicate() { while(runThread_) { // .... } }
private void start() { Thread communicateThread = GetSingleThread((ParameterizedThreadStart)delegate { communicate(); }); if (!communicateThread.IsAlive) { runThread_ = true;//修改部分 communicateThread.IsBackground = true; communicateThread.Start(); } } private void communicate() { while(runThread_) { // .... } }编译运行,程序正常运转了。这是runThread_标志设的位置不合适引发的BUG,是一种编码失误。
问题至此是解决了,可是却引发了新的思考。为什么在我的电脑上没问题,在虚拟机上有问题?于是将runThread_还原到原来有BUG时的位置,在communicate中输出。在两个环境中得到的值完全不同,在我的电脑上是runThread_=true,在虚拟机上是runThread=false.这进一步确定了原来BUG的原因,但这是为什么会这样?
想起一句牛人的经典话语:解决了问题,却不知道问题产生的原因。
最后,自己分析应该是这两个环境中配置的差异,我的电脑配置明显要高于虚拟机的,这样在线程开启时获得的runThread_就产生了差异。我的电脑上获得的是赋值后的,而虚拟机中获得的是最初的false.