findbugs与sonar应用比较

静态代码扫描是一种对代码的健康状况的管理和度量的手段，如果加入CI环境，在每日对trunk代码进行每日build时加入静态扫描，可以精确的控制代码的变更。现在业界常用的工具一般有findbugs和sonar两种，下面将就两种框架的使用情况做比较。

 

findbugs提供了三种使用方式

1.findbugs+jenkins CI集成运行方式 适用情况：测试部门用于每日build，处理完扫描出的bug后，关注新增代码质量情况，并且根据项目情况 添加规则

运行示例:

 

2.findbugs UI运行方式 适用情况：介于第一种和第三种方式之间，优点就是作为UI工具提供了很多界面操作，利用分类，并且可以

标识处理情况，fix，notfix等

运行示例：

3.ide增加findbugs plugin方式 适用情况：适用于研发测试本机扫描代码，非常方便

运行示例:

如图所示是在intellij IDEA安装了findbugs插件

 

sonar：

sonar的安装相对于findbugs复杂点，需要一个单独的mysql数据库源，启动sonar后

运行示例:

 

总结： findbugs是sonar的子集，在sonar平台中可以直接导入findbugs的规则集。sonar比findbugs高了一个层级，多出了sonar不仅关注了常规静态bug，还关注到了如代码质量、包与包，类与类之间的依赖情况、代码耦合情况、类，方法。文件的复杂度、代码中是否包含大量复制粘贴的代码是质量低下的，关注到了项目代码整体的健康情况。不过个人在使用过程中findbugs本身的规则比sonar的官方规则更加实用，high级别的bug都是较为实用的bug，且能覆盖到一些性能方面的问题，sonar的规则，50%bug都是主要级别，其实危害不大。前期轻量级的静态bugs扫描可以选用findbugs，当项目持续稳定后可以选用sonar进行更深层次的代码质量控制

下面将结合实例说明findbugs的作用:

起因是线上的业务报错，日志如下:

 

这个问题是由于SimpleDateFormat的误用引起的。SimpleDateFormat的javadoc中有这么句话： Date formats are not synchronized. It is recommended to create separate format instances for each thread.  If multiple threads access a format concurrently, it must be synchronized externally. 

 

通过findbugs扫描代码，果然有这个提示：

 

Bug: Call to method of static java.text.DateFormat Pattern id: STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE, type: STCAL, category: MT_CORRECTNESS

As the JavaDoc states, DateFormats are inherently unsafe for multithreaded use. The detector has found a call to an instance of DateFormat that has been obtained via a static field. This looks suspicous.

 

导致SimpleDateFormat出现多线程安全问题的原因，是因为：SimpleDateFormat处理复杂，Jdk的实现中使用了成员变量来传递参数，这就造成在多线程的时候会出现错误。

    而Findbugs所说的“Call to static DateFormat”，其实就是一些人：为了渐少new 的次数而把SimpleDateFormat做成成员或者静态成员，上面已经说了，这样做是不安全的。