C++多线程调试和测试的注意事项.pdfVIP

C++多线程调试和测试的注意事项 今天顺便说一下开发C++多线程应用程序时，有关调试和测试的一些注意事项。下面这些注 意事项主要是针对C++，不过有些对于其它的语言也适用。 ★关于设置断点和单步执行 很多同学非常依赖于调试器的断点功能和单步功能。这在单线程情况下倒还好（不过有 些单线程但涉及GUI 的程序，也会有点麻烦）。至于多线程程序的调试，这两种手段简直就 是噩梦的开始。多线程造成的主要问题大都和竞态条件（RaceCondition，详细解释看“这里”） 有关。而设置断点或单步跟踪可能会严重干扰多线程之间的竞争状态。导致你看到的是一个 假象。比如本来有两个线程并发执行，存在某些不和谐的 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 功能本身 有问题，要么是程序的竞态条件非常敏感（连log 的开销都会有影响）。 这时候你能依靠的就只有肉眼和人脑了。先把相关的代码和文档仔细看上几遍（最好再 找其他有经验的人一起Code Review），然后大家一起开动脑筋使劲琢磨。★关于Debug版 本和Release版本 C++程序经常有Debug 版本和Release 版本的区别。有些时候，这也会导致一些多线程 的问题。 由于Debug 版本包含了一些调试信息、启用了某些调试机制（比如assert 宏）。所以就 可能影响到多线程的竞争状态。在倒霉的时候，会碰上Debug 版本工作正常，Release 版本 程序随机崩溃。要避免这种情况，可以考虑下面两个办法： ◇放弃使用Debug 版本 你可以干脆放弃使用Debug版本。在这种情况下，你需要考虑把诸如assert之类调试相 关的宏替换成自己的一套宏，使得在非Debug 版本下也可以生效。 ◇两种版本同步测试 使用此方法，程序员平时自测可以使用Debug 版本，但是测试人员日常测试的必须是 Release 版本。具体的操作步骤可以利用每日构建来辅助进行（每日构建的介绍参见“这里”）。 一定要避免：在平时仅仅搞Debug版本的测试，等到发布前夕再制作Release 版本。这种做 法是非常危险的！ ★关于测试的机器（硬件） 说一个亲身经历、印象深刻的事情。 当年用ACE 开发跨平台程序的时候，公司内的的开发环境和测试环境都是单CPU 的机 器。因为当时多核的机器还没有面世，多CPU 的机器又挺贵，公司没舍得花钱配置。 软件开发完之后，测试人员经过几轮回归测试，也没发现太大问题。但是拿到客户的环 境中运行，却经常会随机性崩溃。因为不能在客户环境中 Debug，自己 的环境又死活没问 题，开发组的几个人只好充分发挥肉眼和人脑的功能（盯着代码和设计文档猛想