java - 静态线程分析: Good idea?

Question

我帮助维护和构建一个相当大的 Swing GUI，其中包含许多复杂的交互。我经常发现自己修复了由于代码中其他地方的某些竞争条件而导致事情进入奇怪状态的错误。

随着代码库变得越来越大，我发现通过文档指定哪些方法具有线程限制变得不太一致:最常见的是必须在 Swing EDT 上运行的方法。同样，了解并提供静态感知(我们的自定义)监听器在 EDT 上按规范通知是有用的。

所以我想到这应该是可以使用注释轻松执行的东西。瞧，至少存在一种静态分析工具，CheckThread ，它使用注释来完成此操作。它似乎允许您将方法声明为仅限于特定线程(最常见的是 EDT)，并且会标记尝试调用该方法的方法，而不会同时声明自己仅限于该线程。

因此，从表面上看，这似乎只是对源代码和构建周期的一种低痛苦、巨大的 yield 。我的问题是:

• 对于使用 CheckThread 或类似库来强制执行线程约束的人来说，是否有任何成功案例？有失败的故事吗？ 为什么会成功/失败？
• 这在理论上好吗？是否存在理论上的缺点？
• 这在实践中好吗？ 值得吗？它带来了什么样的值(value)？
• 如果它在实践中有效，有哪些好的工具可以支持这一点？我刚刚找到了 CheckThread，但我承认我不完全确定我在寻找什么来找到其他可以做的工具同样的事情。

我知道它是否适合我们取决于我们的情况。但是我从来没有听说过有人在实践中使用过这样的东西，老实说，它似乎并没有从一些一般性的浏览中占据多少。所以我想知道为什么。

Answer 1

此答案更侧重于您问题的理论方面。

从根本上说，您是在断言:“此方法仅在某些线程下运行”。这个断言与您可能做出的任何其他断言并没有真正的不同(“该方法只接受小于 17 的整数作为参数 X”)。问题是

• 这些断言从何而来？
• 静态分析器可以检查它们吗？
• 你从哪里得到这样一个静态分析器？

大多数此类断言必须来自软件设计人员，因为他们是唯一知道意图的人。对此的传统术语是“按契约(Contract)设计”，尽管大多数 DBC 方案仅在 当前 程序状态(C 的 assert 宏)并且它们确实应该在程序的过去和 future 状态(“时间断言”)，例如，“这个例程将分配一个存储 block ，最终一些代码将释放它”。可以构建工具来尝试以色调方式确定断言是什么(例如，Engler 的断言归纳工作；其他人已经在该领域做过工作)。这很有用，但误报是一个问题。实际上，要求设计人员编写此类断言的代码似乎并不特别繁重，而且确实是很好的长期文档。您是否使用特定的“契约(Contract)”语言结构或 if 语句(“if Debug && Not(assertion) Then Fail();”)或将它们隐藏在注释中实际上只是为了方便。当语言允许直接编写这样的断言时，这很好。

静态检查此类断言很困难。如果您只坚持当前状态，则静态分析器几乎必须对整个应用程序进行完整的数据流分析，因为满足断言所需的信息可能来自应用程序的另一部分创建的数据。 (在您的情况下，“EDT 内部”信号必须来自分析应用程序的整个调用图，以查看是否有任何调用路径导致来自非 EDT 线程的线程的方法)。如果您使用时间属性，则静态检查几乎还需要某种状态空间验证逻辑；这些目前仍然是相当多的研究工具。即使使用了所有这些机器，静态分析仪在分析中通常也必须“保守”；如果他们不能证明某事是假的，他们几乎不得不假设它是真的，因为停机问题。

你从哪里得到这样的分析仪？鉴于所需的所有机器，它们很难制造，因此您应该期望它们很少见。如果有人 build 了一个，那就太好了。如果不是...作为一般规则，您不希望自己从头开始执行此操作。最好的长期希望是拥有可用于构建此类分析器的通用程序分析机器，以摊销构建所有基础设施的成本。 (我构建了程序分析工具基础；参见我们的 DMS Software Reengineering Toolkit)。

让构建此类静态分析器“更容易”的一种方法是将它们处理的案例限制在较窄的范围内，例如 CheckThread。我希望 CheckThread 能够完全按照它目前所做的那样做，而且它不太可能变得更强大。

“断言”宏和其他此类动态“当前状态”检查之所以流行，是因为它们实际上可以通过简单的运行时测试来实现。这很实用。这里的问题是您可能永远不会执行导致失败条件的路径。因此，对于动态分析，没有检测到故障并不是正确性的真正证据。感觉还是不错的。

底线:静态分析器和动态分析器各有所长。