Chris Grindstaff
软件工程师, IBM
2004 年 5 月 25 日

静态分析工具承诺无需开发人员费劲就能找出代码中已有的缺陷。当然，如果有多年的编写经验，就会知道这些承诺并不是一定能兑现。尽管如此，好的静态分析工具仍然是工具箱中的无价之宝。在这个由两部分组成的系列文章的第一部分中，高级软件工程师 Chris Grindstaff 分析了 FindBugs 如何帮助提高代码质量以及排除隐含的缺陷。

代码质量工具的一个问题是它们容易为开发人员提供大量但并非真正问题的问题——即 伪问题（false positives）。出现伪问题时，开发人员要学会忽略工具的输出或者放弃它。FindBugs 的设计者 David Hovemeyer 和 William Pugh 注意到了这个问题，并努力减少他们所报告的伪问题数量。与其他静态分析工具不同，FindBugs 不注重样式或者格式，它试图只寻找真正的缺陷或者潜在的性能问题。

FindBugs是什么？
FindBugs 是一个静态分析工具，它检查类或者 JAR 文件，将字节码与一组缺陷模式进行对比以发现可能的问题。有了静态分析工具，就可以在不实际运行程序的情况对软件进行分析。不是通过分析类文件的形式或结构来确定程序的意图，而是通常使用 Visitor 模式。图 1 显示了分析一个匿名项目的结果（为防止可怕的犯罪，这里不给出它的名字）：

让我们看几个 FindBugs 可以发现的问题。

问题发现的例子
下面的列表没有包括 FindBug 可以找到的 所有问题。相反，我侧重于一些更有意思的问题。

检测器：找出 hash equals 不匹配
这个检测器寻找与 equals() 和 hashCode() 的实现相关的几个问题。这两个方法非常重要，因为几乎所有基于集合的类—— List、Map、Set 等都调用它们。一般来说，这个检测器寻找两种不同类型的问题——当一个类：

• 重写对象的 equals() 方法，但是没有重写它的 hashCode 方法，或者相反的情况时。
  
  
• 定义一个 co-variant 版本的 equals() 或 compareTo() 方法。例如， Bob 类定义其 equals() 方法为布尔 equals(Bob) ，它覆盖了对象中定义的 equals() 方法。因为 Java 代码在编译时解析重载方法的方式，在运行时使用的几乎总是在对象中定义的这个版本的方法，而不是在 Bob 中定义的那一个（除非显式将 equals() 方法的参数强制转换为 Bob 类型）。因此，当这个类的一个实例放入到类集合中的任何一个中时，使用的是 Object.equals() 版本的方法，而不是在 Bob 中定义的版本。在这种情况下， Bob 类应当定义一个接受类型为 Object 的参数的 equals() 方法。

检测器：忽略方法返回值
这个检测器查找代码中忽略了不应该忽略的方法返回值的地方。这种情况的一个常见例子是在调用 String 方法时，如在清单 1 中：

1  String aString = "bob";
2  b.replace('b', 'p');
3  if(b.equals("pop"))

这个错误很常见。在第 2 行，程序员认为他已经用 p 替换了字符串中的所有 b。确实是这样，但是他忘记了字符串是不可变的。所有这类方法都返回一个新字符串，而从来不会改变消息的接收者。

检测器：Null 指针对 null 的解引用（dereference）和冗余比较
这个检测器查找两类问题。它查找代码路径将会或者可能造成 null 指针异常的情况，它还查找对 null 的冗余比较的情况。例如，如果两个比较值都为 null，那么它们就是冗余的并可能表明代码错误。FindBugs 在可以确定一个值为 null 而另一个值不为 null 时，检测类似的错误，如清单 2 所示：

1  Person person = aMap.get("bob");
2  if (person != null) {
3      person.updateAccessTime();
4  }
5  String name = person.getName();

在这个例子中，如果第 1 行的 Map 不包括一个名为“bob”的人，那么在第 5 行询问 person 的名字时就会出现 null 指针异常。因为 FindBugs 不知道 map 是否包含“bob”，所以它将第 5 行标记为可能 null 指针异常。

检测器：初始化之前读取字段
这个检测器寻找在构造函数中初始化之前被读取的字段。这个错误通常是——尽管不总是如此——由使用字段名而不是构造函数参数引起的，如清单 3 所示：

在构造函数中读取未初始化的字段

1  public class Thing {
2      private List actions;
3      public Thing(String startingActions) {
4          StringTokenizer tokenizer = new StringTokenizer(startingActions);
5          while (tokenizer.hasMoreTokens()) {
6              actions.add(tokenizer.nextToken());
7          }   
8      }
9  }

在这个例子中，第 6 行将产生一个 null 指针异常，因为变量 actions 还没有初始化。

这些例子只是 FindBugs 所发现的问题种类的一小部分。在撰写本文时，FindBugs 提供总共 35 个检测器。

要运行 FindBugs，需要一个版本 1.4 或者更高的 Java Development Kit （JDK），尽管它可以分析由老的 JDK 创建的类文件。要做的第一件事是下载并安装最新发布的 FindBugs——当前是 0.7.1 。幸运的是，下载和安全是相当简单的。在下载了 zip 或者 tar 文件后，将它解压缩到所选的目录中。就是这样了——安装就完成了。

安装完后，对一个示例类运行它。就像一般文章中的情况，我将针对 Windows 用户进行讲解，并假定那些 Unix 信仰者可以熟练地转化这些内容并跟进。打开命令行提示符号并进入 FindBugs 的安装目录。对我来说，这是 C:\apps\FindBugs-0.7.3。

在 FindBugs 主目录中，有几个值得注意的目录。文档在 doc 目录中，但是对我们来说更重要的是，bin 目录包含了运行 FindBugs 的批处理文件，这使我们进入下一部分。

运行 FindBugs
像如今的大多数数工具一样，可以以多种方式运行 FindBugs——从 GUI、从命令行、使用 Ant、作为 Eclipse 插件程序和使用 Maven。我将简要提及从 GUI 运行 FindBugs，但是重点放在用 Ant 和命令行运行它。部分原因是由于 GUI 没有提供命令行的所有选项。例如，当前不能指定要加入的过滤器或者在 UI 中排除特定的类。但是更重要的原因是我认为 FindBugs 最好作为编译的集成部分使用，而 UI 不属于自动编译。

使用 FindBugs UI
使用 FindBugs UI 很直观，但是有几点值得说明。使用 FindBugs UI 的一个好处是对每一个检测到的问题提供了说明。图 1 显示了缺陷 Naked notify in method的说明。对每一种缺陷模式提供了类似的说明，在第一次熟悉这种工具时这是很有用的。窗口下面的 Source code 选项卡也同样有用。如果告诉 FindBugs 在什么地方寻找代码，它就会在转换到相应的选项卡时突出显示有问题的那一行。

值得一提的还有在将 FinBugs 作为 Ant 任务或者在命令行中运行 FindBugs 时，选择 xml 作为 ouput 选项，可以将上一次运行的结果装载到 UI 中。这样做是同时利用基于命令行的工具和 UI 工具的优点的一个很好的方法。

将 FindBugs 作为 Ant 任务运行
让我们看一下如何在 Ant 编译脚本中使用 FindBugs。首先将 FindBugs Ant 任务拷贝到 Ant 的 lib 目录中，这样 Ant 就知道新的任务。将 FIND_BUGS_HOME\lib\FindBugs-ant.jar 拷贝到 ANT_HOME\lib。

现在看看在编译脚本中要加入什么才能使用 FindBugs 任务。因为 FindBugs 是一个自定义任务，将需要使用 taskdef 任务以使 Ant 知道装载哪一个类。通过在编译文件中加入以下一行做到这一点：

在定义了 taskdef 后，可以用它的名字 FindBugs 引用它。下一步要在编译中加入使用新任务的目标，如清单 4 所示：

清单 4. 创建 FindBugs 目录

1  
2      
3          
4          
5          
6      
7  

让我们更详细地分析这段代码中所发生的过程。

第 1 行： 注意 target 取决于编译。一定要记住处理的是类文件而 不 是源文件，这样使 target 对应于编译目标保证了 FindBugs 可在最新的类文件运行。FindBugs 可以灵活地接受多种输入，包括一组类文件、JAR 文件、或者一组目录。

第 2 行：必须指定包含 FindBugs 的目录，我是用 Ant 的一个属性完成的，像这样：

可选属性 output 指定 FindBugs 的结果使用的输出格式。可能的值有 xml 、 text 或者 emacs 。如果没有指定 outputFile ，那么 FindBugs 会使用标准输出。如前所述，XML 格式有可以在 UI 中观看的额外好处。

第 3 行： class 元素用于指定要 FindBugs 分析哪些 JAR、类文件或者目录。分析多个 JAR 或者类文件时，要为每一个文件指定一个单独的 class 元素。除非加入了 projectFile 元素，否则需要 class 元素。更多细节请参阅 FindBugs 手册。

第 4 行： 用嵌套元素 auxClasspath 列出应用程序的依赖性。这些是应用程序需要但是不希望 FindBugs 分析的类。如果没有列出应用程序的依赖关系，那么 FindBugs 仍然会尽可能地分析类，但是在找不到一个缺少的类时，它会抱怨。与 class 元素一样，可以在 FindBugs 元素中指定多个 auxClasspath 元素。 auxClasspath 元素是可选的。

第 5 行： 如果指定了 sourcePath 元素，那么 path 属性应当表明一个包含应用程序源代码的目录。指定目录使 FindBugs 可以在 GUI 中查看 XML 结果时突出显示出错的源代码。这个元素是可选的。

过滤器
您已经将 FindBugs 引入到了团队中，并运行它作为您的每小时/每晚编译过程的一部分。当团队越来越熟悉这个工具时，出于某些原因，您决定所检测到的一些缺陷对于团队来说不重要。也许您不关心一些类是否返回可能被恶意修改的对象——也许，像 JEdit，有一个真正需要的（honest-to-goodness）、合法的理由调用 System.gc() 。

总是可以选择“关闭”特定的检测器。在更细化的水平上，可以在指定的一组类甚至是方法中查找问题时，排除某些检测器。FindBugs 提供了这种细化的控制，可以排除或者包含过滤器。当前只有用命令行或者 Ant 启动的 FindBugs 中支持排除和包含过滤器。正如其名字所表明的，使用排除过滤器来排除对某些缺陷的报告。较为少见但仍然有用的是，包含过滤器只能用于报告指定的缺陷。过滤器是在一个 XML 文件中定义的。可以在命令行中用一个排除或者包含开关、或者在 Ant 编译文件中用 excludeFilter 和 includeFilter 指定它们。在下面的例子中，假定使用排除开关。还要注意在下面的讨论中，我对 “bugcode”、“bug” 和“detector”的使用具有某种程度的互换性。

可以有不同的方式定义过滤器：

• 匹配一个类的过滤器。可以用这些过滤器 忽略在特定类?