一些你不知道的事，findbugs的配置和使用

╰+哭是因爲堅強的太久メ 2024-02-19 16:49 45阅读 0赞

作为一个程序员，你不得不知道一些提高代码开发性能和开发效率的工具或者插件的使用，再说现在好多的公司都讲究快速开发，如果周期时间短那么你的程序的bug通过一些工具来搞，岂不是方便很多吗,但是插件毕竟还是有很大的局限性，比如findbugs就只能找出java文件里面的bug,下一篇我们来学习pmd的代码优化。

一、findbugs简介  
FindBugs出到目前的版本，功能已经相当强大，不过也有待完善的地方。从实际使用来看，有一些隐藏的bug并不能靠FindBugs直接发现。那么，可不可以撰写一个新的Detector，来发现这种将一个未初始化的reference传来传去而形成的潜在的bug呢？理论上来讲，应该是可以的。这个Detector目前还未实现。哪位如果有兴趣的话，可以参考FindBugs, Part 2: Writing cust detectors（扩展阅读）这篇文章，帮忙实现这个Detector。实现一个新的Detector，便可以检测出一种新型的bug，这样不知又可以帮开发人员省去多少人工检查的时间，功德无量啊。 FindBugs也不能发现非java的Bug。对于非java撰写的代码，如javascript，SQL等等，要找出其中可能的bug，FindBugs是无能为力的。当然，javascript中的bug似乎还不至于使系统崩溃，而SQL中的bug往往又跟业务逻辑相关，只要测试仔细一些应该是可以发现的。 FindBugs不过是一个工具。作为开发人员，当然首先要在编程的时候努力避免引入bug，而不要依赖于某个工具来为自己把关。不过由于代码的复杂性，一些隐藏的bug确实很难靠咱们的肉眼发现。这时，应用一些好的工具或许就可以帮你发现这样的bug。这便是FingBug存在的价值。

二、findbugs 的安装配置  
直接eclipse里面安装插件（http://findbugs.cs.umd.edu/eclipse更新的site），turn on Eclipse, click on Help -> Software Update -> Find and Install...接着勾选next,acept步奏不再叙述。

当然也可以直接从http://download.csdn.net/detail/hailshao/6593725下载，然后将文件复制到你本地eclipse的plugins目录，然后重启eclipse即可。

最后restart Eclipse，选中项目，右键会出现一个Find Bugs菜单。至此，findbugs插件安装完毕,你可以放心的使用了。。

FindBugs的设置：  
安装好之后，可以通过 Projects > Property > FindBugs标签对其进行设置。设置方法可以根据自己的需要进行调整。  
另外在 问题（Proplems）列表窗口（Windows > 视图 > 问题）的Filter设置里，把FindBugs的有关选项都check上。  
FindBugs地执行：  
选中 所在项目，鼠标右键 > Find Bugs > Find Bugs执行,哈哈，一切搞定了吧，然后就是我们的使用了。

在android studio里面的安装请去：

http://plugins.jetbrains.com/plugin/3847?pr=androidstudio

三、Findbugs是一个静态分析工具  
那么什么是静态分析工具呢？

静态代码分析是指无需运行被测代码，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，找出代码隐藏的错误和缺陷，如参数不匹配，有歧义的嵌套语句，错误的递归，非法计算，可能出现的空指针引用等等。

在软件开发过程中，静态代码分析往往先于动态测试之前进行，同时也可以作为制定动态测试用例的参考。统计证明，在整个软件开发生命周期中，30% 至 70% 的代码逻辑设计和编码缺陷是可以通过静态代码分析来发现和修复的。

但是，由于静态代码分析往往要求大量的时间消耗和相关知识的积累，因此对于软件开发团队来说，使用静态代码分析工具自动化执行代码检查和分析，能够极大地提高软件可靠性并节省软件开发和测试成本。

静态代码分析工具的优势  
1. 帮助程序开发人员自动执行静态代码分析，快速定位代码隐藏错误和缺陷。

2. 帮助代码设计人员更专注于分析和解决代码设计缺陷。

3. 显著减少在代码逐行检查上花费的时间，提高软件可靠性并节省软件开发和测试成本。

Java 静态代码分析理论基础和主要技术  
缺陷模式匹配：缺陷模式匹配事先从代码分析经验中收集足够多的共性缺陷模式，将待分析代码与已有的共性缺陷模式进行模式匹配，从而完成软件的安全分析。这种方式的优点是简单方便，但是要求内置足够多缺陷模式，且容易产生误报。  
类型推断：类型推断技术是指通过对代码中运算对象类型进行推理，从而保证代码中每条语句都针对正确的类型执行。这种技术首先将预定义一套类型机制，包括类 型等价、类型包含等推理规则，而后基于这一规则进行推理计算。类型推断可以检查代码中的类型错误，简单，高效，适合代码缺陷的快速检测。  
模型检查：模型检验建立于有限状态自动机的概念基础之上，这一理论将被分析代码抽象为一个自动机系统，并且假设该系统是有限状态的、或者是可以通过抽象归 结为有限状态。模型检验过程中，首先将被分析代码中的每条语句产生的影响抽象为一个有限状态自动机的一个状态，而后通过分析有限状态机从而达到代码分析的 目的。模型检验主要适合检验程序并发等时序特性，但是对于数据值域数据类型等方面作用较弱。  
数据流分析：数据流分析也是一种软件验证技术，这种技术通过收集代码中引用到的变量信息，从而分析变量在程序中的赋值、引用以及传递等情况。对数据流进行 分析可以确定变量的定义以及在代码中被引用的情况，同时还能够检查代码数据流异常，如引用在前赋值在后、只赋值无引用等。数据流分析主要适合检验程序中的 数据域特性。  
四、findbugs 的使用  
我们还是来看下百度百科里面的原理介绍：它检查类或者JAR 文件，将字节码与一组缺陷模式进行对比以发现可能的问题。有了静态分析工具，就可以在不实际运行程序的情况对软件进行分析。不是通过分析类文件的形式或结构来确定程序的意图，而是通常使用 Visitor 模式（请参阅 参考资料）。

Findbugs自带检测器，其中有60余种Bad practice，80余种Correctness，1种 Internationalization，12种Malicious code vulnerability，27种Multithreaded correctness，23种Performance，43种Dodgy。（其实不太了解），然后介绍这些东西的博客也是非常的多，天朝的程序员也是相当的不容易，反正本着会用就好，原理也是百度上看的，不只做伸手党就好。  
然后直接操作了

选择bugExplorer,好像网上的都是有"Show Bug Details",应该是版本不一样的吧，这个是不影响我们去用这工具检测隐藏的bug的。  
然后find bugs可能需要几十秒到一分钟吧，

从图中可以看出我是有99个bug,然后我们切换到bug explorer ，  
然后你会发现这些小爬虫是有不同的颜色，那么你就必须要看这单词的意思咯。  
Bug Explorer 中的灰色图标处为 Bug 类型，每种分类下红色图标表示 bug 较为严重，黄色的图标表示 bug 为警告程度。Propreties 列出了 bug 的描述信息及修改方案。我的工程就可以知道红色警告10个，那么我就有必要一个个的去解决了，不然程序真的有可能出问题。然后点击进代码里，点击那小虫子就会在控制台打印这样一段，  
，  
可以看出这是一个高风险的bug了，然后你可以通过xml去知道bug在哪，并且eclipse会在影响bug的地方显示和虫子颜色相同的段标记。当然我们以上的测试环境是在默认的配置下进行的，你也可以使用 FindBugs 添加自定义代码检查规范 ，如下图：

可以配置的信息包括如上图所示的四个选项的相关设置：

1. Run FindBugs Automatically开关

当此项选中后，FindBugs将会在你修改Java类时自动运行，如你设置了Eclipse自动编译开关后，当你修改完Java文件保存，FindBugs就会运行，并将相应的信息显示出来。

当此项没有选中，你只能每次在需要的时候自己去运行FindBugs来检查你的代码。

2. Minimum priority to report选择项

这个选择项是让你选择哪个级别的信息进行显示，有Low、Medium、High三个选择项可以选择，很类似于Log4J的级别设置啦。 比如：

你选择了High选择项，那么只有是High级别的提示信息才会被显示。

你选择了Medium选择项，那么只有是Medium和High级别的提示信息才会被显示。

你选择了Low选择项，那么所有级别的提示信息都会被显示。

3. Enable bug categories选择项

在这里是一些显示Bug分类的选择：

Correctness关于代码正确性相关方面的

Performance关于代码性能相关方面的

Internationalization关于代码国际化相关方面的

Multithreaded correctness关于代码多线程正确性相关方面的

Style关于代码样式相关方面的

Malicious code vulnerability关于恶意破坏代码相关方面的

比如：如果你把Style的检查框去掉不选择中它，那么与Style分类相关的警告信息就不会显示了。其它的类似。

4. Select bug patterns to check for选择项

在这里你可以选择所要进行检查的相关的Bug Pattern条目

可以从Bug codes、Detector name、Detector description中看到相应的是要检查哪些方面的内容，你可以根据需要选择或去掉相应的 检查条件。

五、详细说明（参考 http://www.cnblogs.com/doit8791/archive/2012/10/22/2734730.html）

Bad practice 坏的实践

一些不好的实践，下面列举几个：

HE： 类定义了equals()，却没有hashCode()；或类定义了equals()，却使用

Object.hashCode()；或类定义了hashCode()，却没有equals()；或类定义了hashCode()，却使用Object.equals()；类继承了equals()，却使用Object.hashCode()。

SQL：Statement 的execute方法调用了非常量的字符串；或Prepared Statement是由一个非常量的字符串产生。

DE： 方法终止或不处理异常，一般情况下，异常应该被处理或报告，或被方法抛出。

Correctness 一般的正确性问题

可能导致错误的代码，下面列举几个：

NP： 空指针被引用；在方法的异常路径里，空指针被引用；方法没有检查参数是否null；null值产生并被引用；null值产生并在方法的异常路径被引用；传给方法一个声明为@NonNull的null参数；方法的返回值声明为@NonNull实际是null。

Nm： 类定义了hashcode()方法，但实际上并未覆盖父类Object的hashCode()；类定义了tostring()方法，但实际上并未覆盖父类Object的toString()；很明显的方法和构造器混淆；方法名容易混淆。

SQL：方法尝试访问一个Prepared Statement的0索引；方法尝试访问一个ResultSet的0索引。

UwF：所有的write都把属性置成null，这样所有的读取都是null，这样这个属性是否有必要存在；或属性从没有被write。

Internationalization 国际化

当对字符串使用upper或lowercase方法，如果是国际的字符串，可能会不恰当的转换。

Malicious code vulnerability 可能受到的恶意攻击

如果代码公开，可能受到恶意攻击的代码，下面列举几个：

FI： 一个类的finalize()应该是protected，而不是public的。

MS：属性是可变的数组；属性是可变的Hashtable；属性应该是package protected的。

Multithreaded correctness 多线程的正确性

多线程编程时，可能导致错误的代码，下面列举几个：

ESync：空的同步块，很难被正确使用。

MWN：错误使用notify()，可能导致IllegalMonitorStateException异常；或错误的

使用wait()。

No： 使用notify()而不是notifyAll()，只是唤醒一个线程而不是所有等待的线程。

SC： 构造器调用了Thread.start()，当该类被继承可能会导致错误。

Performance 性能问题

可能导致性能不佳的代码，下面列举几个：

DM：方法调用了低效的Boolean的构造器，而应该用Boolean.valueOf(…)；用类似

Integer.toString(1) 代替new Integer(1).toString()；方法调用了低效的float的构造器，应该用静态的valueOf方法。

SIC：如果一个内部类想在更广泛的地方被引用，它应该声明为static。

SS： 如果一个实例属性不被读取，考虑声明为static。

UrF：如果一个属性从没有被read，考虑从类中去掉。

UuF：如果一个属性从没有被使用，考虑从类中去掉。

Dodgy 危险的

具有潜在危险的代码，可能运行期产生错误，下面列举几个：

CI： 类声明为final但声明了protected的属性。

DLS：对一个本地变量赋值，但却没有读取该本地变量；本地变量赋值成null，却没有读取该本地变量。

ICAST： 整型数字相乘结果转化为长整型数字，应该将整型先转化为长整型数字再相乘。

INT：没必要的整型数字比较，如X <= Integer.MAX\_VALUE。

NP： 对readline()的直接引用，而没有判断是否null；对方法调用的直接引用，而方法可能返回null。

REC：直接捕获Exception，而实际上可能是RuntimeException。

ST： 从实例方法里直接修改类变量，即static属性。

上面这些的解释还是可以解决很多的问题的，不过其实用默认的就好了，这些东西谁会傻不拉几的去记住啊。  
六 总结  
findBugs：

Bad practice 坏的实践：常见代码错误，用于静态代码检查时进行缺陷模式匹配  
Correctness 可能导致错误的代码，如空指针引用等  
国际化相关问题：如错误的字符串转换  
可能受到的恶意攻击，如访问权限修饰符的定义等  
多线程的正确性：如多线程编程时常见的同步，线程调度问题。  
运行时性能问题：如由变量定义，方法调用导致的代码低效问题。  
\---------------------  
作者：Losileeya  
来源：CSDN  
原文：https://blog.csdn.net/u013278099/article/details/45843285  
版权声明：本文为博主原创文章，转载请附上博文链接！