C++ 多线程调试和测试的注意事项
C++ 多线程调试和测试的注意事项
在 上次的帖子 聊了 C++ 多线程的跨平台问题，后来感觉意犹未尽。今天顺便说一下开发C++多线程应用程序时，有关调试和测试的一些注意事项。下面这些注意事项主要是针对C++，不过有些对于其它的语言也适用。
很多同学非常依赖于调试器的断点功能和单步功能。这在单线程情况下倒还好（不过有些单线程但涉及 GUI 的程序，也会有点麻烦）。至于多线程程序的调试，这两种手段简直就是噩梦的开始。
多线程造成的主要问题大都和竞态条件（Race Condition，详细解释看“ 这里 ”）有关。而设置断点或单步跟踪可能会【 严重干扰 】多个线程之间的竞争状态。导致你看到的是一个假象。比如本来有两个线程并发执行，存在某些不和谐的 Bug（由竞态引起）。一旦你在某一个线程设置了断点，该线程在断点处停住了，只剩下另一个线程在跑。这时候，并发的场景已经完全被破坏了，你通过调试器看到的【 有可能 】是一个和谐的场景。
稍微跑一下题。这很类似量子力学的“测不准原理”，观测者的观测行为干扰了被测量的客体，导致观测者看到的是一个干扰后的现象。
既然断点和单步不好用。那咋办捏？一个替代方案是输出 log 日志。它可以有效减轻断点和单步所导致的（针对竞态条件的）副作用。
传统的 log 输出主要是打印到屏幕或者输出到文件。对于 C++ 而言，标准库内置的类和函数（比如“cout、printf、fputs”）可能会有线程安全的问题（和编译器的具体实现有关）。尤其是标准流类库（iostream）的八个全局对象，更是要小心慎用。轻则输出的 log 文本混杂，重则导致程序崩溃。
鉴于上述原因，应该尽量使用第三方线程库内置的 log 机制来搞定 log 输出功能。比如 ACE 内置的 ACE_Log_Msg 等。
很多情况下，我们会包装一个公用的函数来实现 log 输出功能。然后在该函数内部调用线程库的 log 类/函数。为了不影响线程的竞态条件，这个 log 函数要尽可能简单轻便：不要涉及太多杂七杂八的琐事、千万别进行耗时的操作、尽量不操作一些全局的变量。
不过捏，即使 log 函数再短小精悍，也还是有可能影响竞态条件（毕竟 log 也有开销，也要消耗 CPU 时间）。
万一竞态条件受到 log 的影响，那就比较棘手了。俺以前就碰到过这种情况：加了 log，程序没有问题；去掉 log，程序随机崩溃。这种情况一般有两种可能：要么是 log 函数本身就有 bug，要么是程序的竞态条件非常敏感（连 log 的开销都会有影响）。
这时候你能依靠的就只有肉眼和人脑了。先把相关的代码和文档仔细看上几遍（最好再找其他有经验的人一起 Code Review），然后大家一起开动脑筋使劲琢磨。
C++ 程序经常有 Debug 版本和 Release 版本的区别。有些时候，这也会导致一些多线程的问题。
由于 Debug 版本包含了一些调试信息、启用了某些调试机制（比如 assert 宏）。所以就【 可能 】影响到多线程的竞争状态。在倒霉的时候，会碰上 Debug 版本工作正常，Release 版本程序随机崩溃。要避免这种情况，可以考虑下面两个办法：
你可以干脆放弃使用 Debug 版本。在这种情况下，你需要考虑把诸如 assert 之类调试相关的宏替换成自己的一套宏，使得在非 Debug 版本下也可以生效。
使用此方法，程序员平时自测可以使用 Debug 版本，但是测试人员日常测试的必须是 Release 版本。具体的操作步骤可以利用每日构建来辅助进行（每日构建的介绍参见“ 这里 ”）。一定要避免：在平时仅仅搞 Debug 版本的测试，等到发布前夕再制作 Release 版本。这种做法是非常危险滴！
说一个亲身经历、印象深刻的事情。
当年用 ACE 开发跨平台程序的时候，公司内的的开发环境和测试环境都是单 CPU 的机器——在那个年代，多核的机器还没有面世，而多 CPU 的机器又挺贵，公司没舍得花钱配置。
软件开发完之后，测试人员经过几轮回归测试，也没发现太大问题。但是拿到客户的环境中运行，却经常会随机性崩溃。因为无法在客户环境中 Debug，自己的环境又死活没问题，开发组的几个人只好充分发挥肉眼和人脑的功能（盯着代码和设计文档猛想）。经过 N 长时间，差点把脑袋想破，最后才意识到客户的机器是多 CPU 的。然后赶紧从其它部门借了一台多 CPU 机器，装上软件调试，最后查出是一个第三方库有问题。此事过后，俺立即想出各种法子，去申请了几台多 CPU 机器给测试人员用。
由于上述的前车之鉴，俺强烈建议：如果是开发多线程的应用程序，尽量给【每个】编程人员和测试人员都配置“多核”或者“多 CPU”的测试机。毕竟现在多核机器已经很普及了，即使多 CPU 的机器，价格也还凑合。实在没必要为了省那点小钱而引入开发风险（不光会浪费开发/测试人员的时间，还可能增加实施和维护的成本）。
写到这里，可能有同学会问“超线程的机器如何捏？”
关于“ 多 CPU 、 多核 、 超线程 ”这三者之间的差异，有兴趣的同学可以看“ Intel 官网的介绍 ”。俺个人感觉超线程不如多核与多CPU爽。
★关于设置断点和单步执行
很多同学非常依赖于调试器的断点功能和单步功能。这在单线程情况下倒还好（不过有些单线程但涉及 GUI 的程序，也会有点麻烦）。至于多线程程序的调试，这两种手段简直就是噩梦的开始。
多线程造成的主要问题大都和竞态条件（Race Condition，详细解释看“ 这里 ”）有关。而设置断点或单步跟踪可能会【 严重干扰 】多个线程之间的竞争状态。导致你看到的是一个假象。比如本来有两个线程并发执行，存在某些不和谐的 Bug（由竞态引起）。一旦你在某一个线程设置了断点，该线程在断点处停住了，只剩下另一个线程在跑。这时候，并发的场景已经完全被破坏了，你通过调试器看到的【 有可能 】是一个和谐的场景。
稍微跑一下题。这很类似量子力学的“测不准原理”，观测者的观测行为干扰了被测量的客体，导致观测者看到的是一个干扰后的现象。
★关于 Log 输出
既然断点和单步不好用。那咋办捏？一个替代方案是输出 log 日志。它可以有效减轻断点和单步所导致的（针对竞态条件的）副作用。
◇传统 Log 机制的问题
传统的 log 输出主要是打印到屏幕或者输出到文件。对于 C++ 而言，标准库内置的类和函数（比如“cout、printf、fputs”）可能会有线程安全的问题（和编译器的具体实现有关）。尤其是标准流类库（iostream）的八个全局对象，更是要小心慎用。轻则输出的 log 文本混杂，重则导致程序崩溃。
鉴于上述原因，应该尽量使用第三方线程库内置的 log 机制来搞定 log 输出功能。比如 ACE 内置的 ACE_Log_Msg 等。
◇Log 函数要短小精悍
很多情况下，我们会包装一个公用的函数来实现 log 输出功能。然后在该函数内部调用线程库的 log 类/函数。为了不影响线程的竞态条件，这个 log 函数要尽可能简单轻便：不要涉及太多杂七杂八的琐事、千万别进行耗时的操作、尽量不操作一些全局的变量。
◇Log 的副作用
不过捏，即使 log 函数再短小精悍，也还是有可能影响竞态条件（毕竟 log 也有开销，也要消耗 CPU 时间）。
万一竞态条件受到 log 的影响，那就比较棘手了。俺以前就碰到过这种情况：加了 log，程序没有问题；去掉 log，程序随机崩溃。这种情况一般有两种可能：要么是 log 函数本身就有 bug，要么是程序的竞态条件非常敏感（连 log 的开销都会有影响）。
这时候你能依靠的就只有肉眼和人脑了。先把相关的代码和文档仔细看上几遍（最好再找其他有经验的人一起 Code Review），然后大家一起开动脑筋使劲琢磨。
★关于 Debug 版本和 Release 版本
C++ 程序经常有 Debug 版本和 Release 版本的区别。有些时候，这也会导致一些多线程的问题。
由于 Debug 版本包含了一些调试信息、启用了某些调试机制（比如 assert 宏）。所以就【 可能 】影响到多线程的竞争状态。在倒霉的时候，会碰上 Debug 版本工作正常，Release 版本程序随机崩溃。要避免这种情况，可以考虑下面两个办法：
◇放弃使用 Debug 版本
你可以干脆放弃使用 Debug 版本。在这种情况下，你需要考虑把诸如 assert 之类调试相关的宏替换成自己的一套宏，使得在非 Debug 版本下也可以生效。
◇两种版本同步测试
使用此方法，程序员平时自测可以使用 Debug 版本，但是测试人员日常测试的必须是 Release 版本。具体的操作步骤可以利用每日构建来辅助进行（每日构建的介绍参见“ 这里 ”）。一定要避免：在平时仅仅搞 Debug 版本的测试，等到发布前夕再制作 Release 版本。这种做法是非常危险滴！
★关于测试的机器（硬件）
说一个亲身经历、印象深刻的事情。
当年用 ACE 开发跨平台程序的时候，公司内的的开发环境和测试环境都是单 CPU 的机器——在那个年代，多核的机器还没有面世，而多 CPU 的机器又挺贵，公司没舍得花钱配置。
软件开发完之后，测试人员经过几轮回归测试，也没发现太大问题。但是拿到客户的环境中运行，却经常会随机性崩溃。因为无法在客户环境中 Debug，自己的环境又死活没问题，开发组的几个人只好充分发挥肉眼和人脑的功能（盯着代码和设计文档猛想）。经过 N 长时间，差点把脑袋想破，最后才意识到客户的机器是多 CPU 的。然后赶紧从其它部门借了一台多 CPU 机器，装上软件调试，最后查出是一个第三方库有问题。此事过后，俺立即想出各种法子，去申请了几台多 CPU 机器给测试人员用。
由于上述的前车之鉴，俺强烈建议：如果是开发多线程的应用程序，尽量给【每个】编程人员和测试人员都配置“多核”或者“多 CPU”的测试机。毕竟现在多核机器已经很普及了，即使多 CPU 的机器，价格也还凑合。实在没必要为了省那点小钱而引入开发风险（不光会浪费开发/测试人员的时间，还可能增加实施和维护的成本）。
写到这里，可能有同学会问“超线程的机器如何捏？”
关于“ 多 CPU 、 多核 、 超线程 ”这三者之间的差异，有兴趣的同学可以看“ Intel 官网的介绍 ”。俺个人感觉超线程不如多核与多CPU爽。
版权声明
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者 编程随想 和本文原始地址：
https://program-think.blogspot.com/2009/04/debug-test-multithreaded-applications.html
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者 编程随想 和本文原始地址：
https://program-think.blogspot.com/2009/04/debug-test-multithreaded-applications.html
文章版权归原作者所有。
