Java 理论与实践: 消除 bug

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

Brian Goetz (brian@quiotix.com), 首席顾问, Quiotix Corp

2004 年 7 月 01 日

很多有关编程风格的建议都是为了创建高质量、可维护的代码，这很合理，因为最容易修复 bug 的时间就是在产生 bug 之前（少量的预防措施……）。遗憾的是，只预防往往是不够的，虽然有一些精巧的工具可以帮助您创建好的代码，但是很少有工具可以帮助您分析、维护或提高现有代码的质量。本月，专栏作家 Brian Goetz 以 Chris Grandstaff 在前面发表的 FindBugs，第 1 部分: 提高代码质量为基础，向您展示了这个静态分析工具如何帮助分析代码，以使其符合本栏目前面的文章中讨论过的设计原理，请在相应的讨论论坛中与作者及其他读者分享您有关本文的心得体会。（您也可以单击文章顶部或底部的 讨论来访问该论坛。）

编写线程安全的类很难，而分析现有类的线程安全性更难，增强类使其仍然保持线程安全也很难。以隐含假定、不变式以及预期用例（虽然在开发人员的头脑中很清晰，但是没有以设计笔记、注释或者文档的方式记录下来）的方式编写完类之后，人们很快就不再了解类的工作方式（或者应该如何工作），现有代码总是比新代码难以使用。

需求：更好的代码审核工具

当然，确保高质量代码的最佳时机就是在编写代码时，因为在这个时期您最了解它的组织方式。关于如何编写高质量代码可以找到很多建议（阅读本栏目即可！），但是未必能从头编写所有代码或花很多时间来编写它。那么在这种情况下该怎么办？开发人员通常喜欢重新编写代码（毕竟，与修复他人的代码或修复自己编写但 bug 很多的代码相比，编写新代码有趣得多），但是这也是一种奢侈，并且通常只是用今天已知的错误与明天未知的错误交换。您需要的是下面这种工具：分析和审核现有的代码库以帮助开发人员进行代码审核并找出 bug。

我很高兴地说，随着 FindBugs 的引入，在自动代码检测和审核工具方面已经取得重大进步。到目前为止，大多数检测工具要么极力试图证明程序是正确的，要么注重一些表面问题，如代码的格式编排和命名规则，最多还关注一些简单的 bug 模式，如自赋值、未使用的域或潜在的错误（如未使用的方法参数，或可以声明为私有或保护的方法被声明为公共的）。但是 FindBugs 不同，它利用字节码分析和很多内置的 bug 模式检测器来查找代码中的常见 bug。它可以帮助您找出代码的哪些位置有意或者无意地偏离了良好的设计原理。（有关 FindBugs 的介绍，请参阅 Chris Grindstaff 的文章，“ FindBugs，第 1 部分: 提高代码质量”和“ FindBugs，第 2 部分: 编写自定义检测器”。）

回页首

设计建议和 bug 模式

对于每种 bug 模式，设计建议中都存在相应的预防要素，用于告诫我们避免这种 bug 模式。因此如果 FindBugs 是 bug 模式检测器，那么它理所当然可以用作审核工具，衡量代码与一组设计原理的符合程度。 Java 理论与实践的很多期文章都专门讲述设计建议的具体要素（或相应的 bug 模式）。在这一期，我将解释 FindBugs 如何确保现有代码库遵循设计建议。让我们以新方式重复前面的一些建议，并了解在没有遵守这些建议时，FindBugs 如何帮助检测。

关于异常的争论

在“ Java 理论与实践: 关于异常的争论”中，反对检查型异常的一个论据是：“摸索”（也就是捕获）这种异常太容易了，并且它既不采取修正行为，也不抛出其他异常，如清单 1 所示。在原型设计中，有时仅仅为了使程序编译，编写空的 catch 块，目的是以后返回并填充某种错误处理策略，这时经常出现这种“摸索”。虽然一些人提供发生这种情景的频率，是为了作为例子说明 Java 语言设计采用的异常处理方法的不易操作性，但是我认为这仅仅是错误地使用了正确的工具。FindBugs 可以方便地检测和标记这些空的 catch 块。如果想要忽略这种异常，可以方便地给该异常添加描述性注释，这样读者就知道您是有意的忽略它，而不是仅仅忘了处理。

try {
  mumbleFoo();
}
catch (MumbleFooException e) { 
}

哈希

在“ Java 理论与实践： 哈希”中，我略述了正确地重载 Object.equals() 和 Object.hashCode() 的基本规则，特别是相等对象（根据 equals() ） 的 hashCode() 值必须相等。虽然只要了解了这项规则，遵守起来就相当简单（并且有些 IDE 包含一些向导，用于以一致的风格为您定义这两个方法），但是如果重载了其中一个方法，而忘记重载另一个方法，那么通过检测很难找出 bug，因为错误并非位于存在的代码中，而是位于不存在码中。

FindBugs 有一个检测器用于检测这个问题的很多实例，如重载了 equals() 但没有重载 hashCode() ，或重载了 hashCode() 但没有重载 equals() 。这些检测器是 FindBugs 中最简单的，因为它们只需要检查该类中一组方法签名，并确定是否同时重载了 equals() 和 hashCode() 。还可能错误地使用 Object 之外的参数类型定义 equals() ；虽然这个构造是合法的，但是它的行为和您想像的不同。Covariant Equals 检测器将检测如下有问题的重载：

  
  public void boolean equals(Foo other) { ... }

与这个检测器相关的是 Confusing Method Names 检测器，它是对名称类似 hashcode() 和 tostring() 的方法触发的，对于下面这些类也会触发这个检测器：具有一些只在名称大小写方面存在差异的方法，或者其方法与超类构造函数的名称相同。虽然根据该语言的规范，这些方法名称是合法的，但是它们可能不是您想要的。类似地，如果域 serialVersionUID 不是 final ，不是 long ，也不是 static ，就会触发 Serialization 检测器。

Finalizer 不是朋友

在“ Garbage collection and performance”中，我尽力阻止使用 finalizer。Finalizer 需要牺牲很多性能，并且它们不能（甚至完全不能）保证在预计的时间段运行。仍然有些时候需要使用 finalizer，而这样做的过程中可能产生很多错误。如果必须使用 finalizer，通常应该如清单 2 所示来组织它：

  protected void finalize() { 
    try {
      doStuff();
    }
    finally { 
      super.finalize();
    }
  }

FindBugs 检测很多有问题的 finalizer 构造，如：

• 空的 finalizer（它抵消超类 finalizer 的作用）。
• 不实现任何功能的 finalizer（它只调用 super.finalize() ，但是这对运行时优化可能造成一些损害）。
• 显式的 finalizer 调用（从用户代码中调用 finalize() ）。
• 公共 finalizer（finalizer 应该声明为 protected ）。
• 没有调用 super.finalize() 的 finalizer。

这些 bug 模式的例子如清单 3 所示：

  // negates effect of superclass finalizer
  protected void finalize() { }
  // fails to call superclass finalize method
  protected void finalize() { doSomething(); }
  // useless (or worse) finalizer
  protected void finalize() { super.finalize(); }
  // public finalizer
  public void finalize() { try { doSomething(); } finally { super.finalize() } }

在“ Garbage collection and performance”中，还讲到另一种垃圾收集危险：显式地调用 System.gc() 。这种显式的调用几乎完全是“帮助”或“欺骗”来机收集器的误导尝试，并且它们最终经常损害性能，而不是对其有利。FindBugs 可以检测显式的 System.gc() 调用，并标记它们（在 Sun JVM 上，还可以使用 -XX:+DisableExplicitGC 启动选项，禁用显式的垃圾收集）。

安全构造技术

在“ Java 理论和实践：安全构造技术”中，我展示了允许对象的引用逃避其构造函数如何导致一些严重的问题。从那时起，允许 this 引用逃避构造的风险变得越来越严重。如果允许对象的引用逃避其构造函数，新的 Java Memory Model（如 JSR 133 所指定，并由 JDK 1.5 实现的）抵消了所有初始化安全保证。

对象的引用可以以几种方式逃避它的构造函数，直接和简接都可以。绝对不可以将 this 引用保存在静态变量或数据结构中，但是有更微妙的方式允许引用逃避构造，如公布对非静态内部类的引用，或者从构造函数中启动一个线程（这几乎总是公布对新线程的引用）。FindBugs 有一个检测器，用于寻找从构造函数启动线程的实例，虽然目前它不能检测所有这些危险，但是未来的版本很可能包括用于其他初始化安全模式的检测器。

为内存模型带来好处

在“ 修复 Java 内存模型，第 1 部分”中，我回顾了同步的基本规则：只要读取可能由其他线程写入的变量，或者写入随后由其他线程读取的变量，就必须进行同步。很容易“忘记”这个规则，特别是在读取时 —— 但是这么做可以造成很多有关程序线程安全的风险。这种 bug 通常是在维护类时引入的：这个类原来是正确同步的，但是维护人员并没有完全理解线程安全需求。

幸运的是，FindBugs 拥有大量的检测器，它们可以帮助识别错误同步的类。 Inconsistent Synchronization 检测器很可能是 FindBugs 所使用的最复杂的检测器；它必须分析整个程序，而不仅仅是单个方法，使用数据流分析来确定什么时候加锁，并使用直观推断来推出一个类想要提供线程安全保证。基本上，对于每个域，它都会查看该域的访问模式，并且如果大多数访问都是同步实现的，那么没有同步的访问将被标记为可能的错误。类似地，如果一个属性的设置函数是同步的，而获取函数不是，那么 Inconsistent Synchronization 检测器将生成一条警告。

除了 inconsistent synchronization 之外，FindBugs 还包含其他很多用于检测常见线程错误的检测器，如在加锁两次的情况下等待监视器（这虽然不一定是 bug，但是可能导致死锁），使用双检测加锁模式，不正确地初始化非易失性的域，对线程调用 run() 而不是启动线程，从构造函数中调用 Thread.start() ，或者没有将 wait() 包装到循环中就调用它。

变化，或不变化

在“ 变还是不变？”（和其他文章中），我赞扬了不可变的优点，不可变对象不能进入不稳定的状态。它们在本质上就是线程安全的（假设它们的不可变性是通过使用 final 关键字保证的），并且您可以随意共享和缓存对不可变对象的引用，而不必复制或者克隆它们。

Java 语言中包括 final 关键字是为了帮助开发人员创建不可变类，并允许编译器和运行时环境以声明的不可变性为基础进行优化。然而，虽然域可以是 final，但是数组元素不可以。通过正确地使用 final 和 private 域，可以使对象成为不可变的，但是如果对象的状态包括数组，那么防止对这些内部数组的引用逃避该类的方法是很重要的。清单 4 展示的类尝试成为不可变的，但是不是，因为在调用 getStates() 之后，调用者可以修改状态数组。（相关的可能 bug 是在可变类可能返回可变数组的引用时，并且在调用者使用这个数组时，它的内容可能已经更改了。）虽然通常将其看作一种“恶意代码”脆弱性（并且很多开发人员并不关心“恶意代码”，因为他们的系统并不加载“不受信任”的类），但是这种习惯仍然可能导致各种与恶意代码无关的问题。返回一个不可修改的 List 或者在返回之前克隆该数组可能更好。FindBugs 可以检测类似 getStates() 中的错误（如清单 4 所示）—— 虽然它不必知道 States 类是假定为不可变的，但是知道这个设置函数返回了可变私有数组的句柄，并且相应地做了标记。

  public class States {
    private final String[] states = { "AL", "AR", "AZ", ... };
    public boolean isState(String stateCandidate) { ... }
    public String[] getStates() { return states; }
  }

回页首

bug 都很重要

FindBugs 确实是一种不寻常的工具，它几乎可以在任何时间找出实际的 bug。您可能认为它搜索的一些变量自赋值之类的 bug 模式，它们太微不足道了，以至于不必麻烦地查找，但是您错了 —— FindBugs 的每个检测器都已经在测试、产品、专业的开发代码中发现了 bug。您的代码中是否潜藏着未知的 bug？下载一个 FindBugs，并尝试对您的代码使用它。结果可能会启发（和干扰）您。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 下载一个 FindBugs工具，并对您的代码尝试该工具。
  
  
• 其他代码检测工具包括 Checkstyle和 TeamStudio。
  
  
• 请访问 Developer Bookstore，获取技术书籍的完整列表，其中包括数百本 与 Java 相关的书籍。
  
  
• 在 developerWorksJava 技术专区 可以找到数百篇有关 Java 编程每个方面的文章。
  

关于作者

		Brian Goetz在过去的 15 年中一直从事专业软件开发工作。他是 Quiotix的首席顾问，该公司是位于加利福尼亚 Los Altos 的软件开发和咨询公司。他在几个 JCP Expert Group 中任职。请在业界流行的出版物上参阅 Brian 发表的和即将发表的文章。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首