臭名昭著的 printf 修复

根据我的经验，我在使用 printf（或任何其他 std out 日志记录）进行调试时遇到了一些奇怪的行为。

行为 1 ：

一种常见的情况是在多线程应用程序中使用 printf 以查找发生某些错误的原因，并使用 printf 突然"修复"错误（ofc printfs 在攻击性调用的地方，导致巨大的输出）。

在这种情况下，我认为 printf 增加了一些延迟，因此可能有一些低优先级线程没有 CPU，所以我开始朝这个方向看。

在奇迹 printf 修复之后，我关注的另一个方向是同步，因为我推测对 printf 的调用虽然是多线程的，但由系统在后面同步，因此具有 printf 的不同线程通过等待彼此完成对 I/O 缓冲区的写入来在它们之间同步。

Q1 ： 我关于第一种情况的两个假设是否正确？

Q2 ： 当这种情况发生时，我应该考虑其他方向吗？

行为 2 ：

这种情况很少发生，但是当遇到这种情况时，即使是高级开发人员也会质疑自己，我真的很感激对此的解释。

它是这样的：

• 代码不起作用...（清理、编译、运行）
• 代码仍然不起作用，所以你添加一个printf看看为什么（清理，编译，运行）
• 代码开始正常工作....删除以前添加的 printf（清理、编译、运行）
• 代码现在工作正常!!!!!!!!!（挠头，难以置信地盯着）。

在实践中，我更多地使用这种方法，然后一旦这种方法修复 CPU 可能会比发生一次更多的与 pe 挂钩的错误：Android"cpu 可能被钉住"错误。

它

实际上运行良好，以至于它成为一个已知的"修复"（如果它从第一次尝试开始不起作用，您只需重复该过程直到它消失）。

请注意，代码已正确清理，它从来都不是与较旧的编译对象链接的问题。

最流行的猜测之一是编译的代码是不同的，原因未知（编译器是否根据某个文件的行（包括空格）有一些随机性？

Q3 ： 这种行为的原因可能是什么（我也愿意猜测）？尽管代码相同，编译器可以生成不同的程序集吗？

请注意，我所说的项目非常大，具有多个静态库，因此这些行为无法在小代码片段上复制（尽管我也听说过单文件程序上发生的场景 2）。