程序静态分析（Program Static Analysis）是指在不运行代码的方式下，通过词法分析、语法分析、控制流分析等技术对程序代码进行扫描，验证代码是否满足规范性、安全性、可靠性、可维护性等指标的一种代码分析技术。

分析技术及实践

形式化方法

著名的静态分析工具

使用简介

使用目的

用法(FindBug PMD CheckStyle)

检查表

分析技术及实践

程序静态分析（Program Static Analysis）可以帮助软件开发人员、质量保证人员查找代码中存在的结构性错误、安全漏洞等问题，从而保证软件的整体质量。

本文首先对程序静态分析的特点、常用静态分析技术、静态分析实现方式进行描述，然后通过一个实例讲解了程序静态分析的执行过程。

一、静态分析特点

程序静态分析是与程序动态分析相对应的代码分析技术，它通过对代码的自动扫描发现隐含的程序问题，主要具有以下特点：

（1）不实际执行程序。动态分析是通过在真实或模拟环境中执行程序进行分析的方法，多用于性能测试、功能测试、内存泄漏测试等方面。与之相反，静态分析不运行代码只是通过对代码的静态扫描对程序进行分析。

（2）执行速度快、效率高。目前成熟的代码静态分析工具每秒可扫描上万行代码，相对于动态分析，具有检测速度快、效率高的特点。

（3）误报率较高。代码静态分析是通过对程序扫描找到匹配某种规则模式的代码从而发现代码中存在的问题，例如可以定位strcpy（）这样可能存在漏洞的函数，这样有时会造成将一些正确代码定位为缺陷的问题，因此静态分析有时存在误报率较高的缺陷，可结合动态分析方法进行修正。

二、常用静态分析技术

（1）词法分析：从左至右一个字符一个字符的读入源程序，对构成源程序的字符流进行扫描，通过使用正则表达式匹配方法将源代码转换为等价的符号（Token） 流，生成相关符号列表，Lex为常用分析工具。

（2）语法分析：判断源程序结构上是否正确，通过使用上下文无关语法将相关符号整理为语法树， Yacc为常用工具。

（3）抽象语法树分析：将程序组织成树形结构，树中相关节点代表了程序中的相关代码，目前已有javacc等抽象语法树生成工具。

（4）语义分析：对结构上正确的源程序进行上下文有关性质的审查。

（5）控制流分析：生成有向控制流图，用节点表示基本代码块，节点间的有向边代表控制流路径，反向边表示可能存在的循环；还可生成函数调用关系图，表示函数间的嵌套关系。

（6）数据流分析：对控制流图进行遍历，记录变量的初始化点和引用点，保存相关数据信息。

（7）污点分析：基于数据流图判断源代码中哪些变量可能受到攻击，是验证程序输入、识别代码表达缺陷的关键。

程序静态分析是在不执行程序的情况下对其进行分析的技术，简称为静态分析。而程序动态分析则是另外一种程序分析策略，需要实际执行程序。大多数情况下，静态分析的输入都是源程序代码，只有极少数情况会使用目标代码。静态分析这一术语一般用来形容自动化工具的分析，而人工分析则往往叫做程序理解。

静态分析越来越多地被应用到程序优化、软件错误检测等领域。Coverity Inc.的软件质量检测产品就是利用静态分析技术进行错误检测的成功代表。

形式化方法

程序分析中的形式化方法一般指利用纯粹严格的数学方法对软件、硬件进行分析的理论及技术。这些数学方法包括符号语义、公理语义、操作语义和抽象解释。

1952年提出的Rice定理指出，任何关于程序分析的问题都是不可判定的。因此，不存在任何一种机械化的方法能够证明程序的完全正确性。然而，针对大多数的不可判定问题，仍然可以试图找到它们的一些近似解。

形式化静态分析中用到的实现技术有：

模型检查假设系统是有限状态的、或者可以通过抽象归结为有限状态。

抽象解释将每条语句的影响模型化为一个抽象机器的状态。相比实际系统，抽象机器更简单更容易分析，但其代价是丧失了分析的完备性（并不是原始系统中的每种性质在抽象机器中都是保留的）。抽象解释当且仅当抽象机器中的每一个性质都能与原始系统中的性质正确映射时，才被称作可靠（sound）的。

断言在霍恩逻辑中首次被提出。目前存在一些针对特定程序设计语言的工具，例如ESC/JAVA和ESC/JAVA2中分别使用的SPARK语言和JML语言。

著名的静态分析工具

Meta-Compilation

由Standford大学的Dawson Engler教授等研究开发，该静态分析工具允许用户使用一种称作metal的状态机语言编写自定义的时序规则，从而实现了静态分析工具的可扩展性。MC的实际效果非常优秀，号称在Linux内核中找出来数百个安全漏洞。MC目前已经商业化，属于Coverity Inc.

mygcc 由一个法国人N. Volanschi开发，其思想来源于MC，试图将自定义的错误检测集成到编译时。

使用简介

在代码构建过程中使用静态分析工具有助于发现代码缺陷，并提高代码的质量。本节关注三个代码静态分析工具的使用：Findbugs、PMD和Checkstyle。这三个工具各有不同的特点，联合使用有助于减少误报错误，提高报告的准确率。

使用目的

这三个工具检查的侧重点各有不同：

本文中三个工具各自的版本分别是：FindBugs 0.85、PMD 2.0和CheckStyle 3.3。这三个工具都可以从sourceforge下载，而且它们都为Eclipse提供了相应的plugin。

用法

关于IDE以及plugin如何使用在此不做介绍，本文主要关注它们如何与ant配合使用，使这些工具成为每次构建过程中的有机组成。

FindBug

FindBugs的运行环境可能是这三个工具之中最苛刻的了。它工作在j2se1.4.0或以后的版本中，需要至少256MB内存。它的安装非常简单，下载之后简单的解压即可。为了与ant配合使用，它提供了对应的ant task。它的使用：

1. findbugs复制到项目的classpath中，并删除将这些文件纳入开发管理中很容易在另一台机器上重建构建环境。不建议向手册中所说的仅仅将findbugs-ant.jar复制到ANT_HOME/lib下。

2. 修改build.xml：

<!-- 定义findbugs所在目录，建议直接将findbugs复制到classpath中 -->

<property name="findbugs.home" value="lib/findbugs" />

<!-- 定义findbugs任务，以及所在的jar文件 -->

<taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask"

classpath="${findbugs.home }/lib/findbugs-ant.jar"/>

<target name="findbugs">

<!-- 使用，所用参数介绍见后 -->

<findbugs home="${findbugs.home}"

output="html"

outputFile="findbugs.html" >

<!-- fog.jar所依赖的classpath引用 -->

<auxClasspath refid="classpath"/>

<!-- fog.jar对应的源文件 -->

<sourcePath path="src" />

<!-- 要分析的bytecode文件 -->

<class location="bin/lib/fog.jar" />

</findbugs>

</target>

3. 运行：ant findbugs。

4. 参数说明：

属性：

- home属性，指出findbugs的安装目录

- quietErrors属性，如果为true，那么严重分析错误和丢失类信息不会出现在输出中。缺省为false。

- reportLevel属性，指明报告输出bug的级别。”low”，所有bug全部输出；”medium”（缺省），输出中级和高级bug；”high”，只输出高级bug。

- output和outputFile属性，指明输出格式和文件名。

- sort属性，如果为true（缺省），输出按类名排序。

- debug属性，是否输出findbugs的调试信息，缺省为false。在自定义bug检测器时使用进行调试。

- visitors属性，用逗号分隔的类名，指明哪些bug检测器可以运行。缺省是所有。

- omitVisitors属性，相当于visitors属性取反，指明哪些bug检测器不能运行。

- excludeFilter和includeFilter属性，指明排除和包含的过滤器（即定义它的文件名）。

- projectFile属性，与findbug gui相关，略。

- jvmargs属性，指明需要传递给jvm的参数。

- timeout属性，超时设置，以毫秒为单位。缺省是600000ms，是10分钟。

- failOnError属性，为true时，如果有findbugs运行中出错，中止构建过程。缺省为false。

- workHard属性，用于将低输出的错误率，但是运行也最慢。缺省为false。

内嵌元素：

- class元素，要分析的bytecode。

- auxClasspath元素，class元素依赖的类。

- sourcePath元素，class元素对应的源文件，它用来指出findbugs输出内容所对应的源文件信息。

- systemProperty元素，定义系统属性。

使用过滤器。过滤器用来包含或排除特殊的bug报告。这样做有助于在特定的时间段内，聚焦我们的关注点。过滤器实际是在一个xml文件定义的，它的典型格式：

<FindBugsFilter>

<!-- 所有的bug检测器都与这个类匹配 -->

<Match class="com.foobar.ClassNotToBeAnalyzed" />

<!-- bugcode为DE,UrF,SIC与这个类匹配 -->

<Match class="com.foobar.ClassWithSomeBugsMatched">

<BugCode name="DE,UrF,SIC" />

</Match>

<!-- bugcode为XYZ的匹配所有的类 -->

<Match classregex=".*" >

<BugCode name="XYZ" />

</Match>

<!-- bugcode为DC的匹配这个类的这些方法 -->

<Match class="com.foobar.AnotherClass">

<Or>

<Method name="nonOverloadedMethod" />

<Method name="frob" params="int,java.lang.String" returns="void" />

<Method name="blat" params="" returns="boolean" />

</Or>

<BugCode name="DC" />

</Match>

</FindBugsFilter>

通过task的excludeFilter和includeFilter属性，可以在findbugs的输出报告中包含或排除匹配它们。具体每个bug检测器的bugcode，可以在plugin/coreplugin.jar/messages.xml中找到。其中messages.xml中的bugcode实际是findbugs.xml（也在coreplugin.jar中）每个Detector元素的reports属性的第一个缩写。如：reports属性为VO_VOLATILE_REFERENCE_TO_ARRAY，对应的bugcode=”VO”。

从使用来看，findbug还是相当简单的。但要用好，使用者还需要了解bug patterns的相关知识，如覆盖equals的同时需要覆盖hashcode。而且，findbugs也允许我们自定义bug patterns，使之方便的扩展。关于这部分内容，请参见developerworks上的文章《FindBugs，第 2 部分：编写自定义检测器》。

PMD

PMD的运行环境是j2se1.3或以后版本，安装过程同样也是解压即可。对应ant task的使用：

1. 把lib中所有的jar复制到项目的classpath中。

2. 将pmd-2.0.jar中的rulesets解压到指定目录，这里面定义了分析所需要的规则集合。

3. 修改build.xml文件。在这一版本中，提供了2个ant task。一个是pmd使用规则集合进行分析；另一个是检查代码中Copy & Paste代码。这2个任务对应的ant task使用：

PMD任务：

<target name="pmd">

<!-- 定义任务和任务所属类所在的classpath引用 -->

<taskdef name="pmd" classname="net.sourceforge.pmd.ant.PMDTask"

classpathref="classpath"/>

<!-- 检查使用的规则文件 -->

<pmd rulesetfiles="junit_lib/rulesets/imports.xml">

<!-- 输出格式和文件名 -->

<formatter type="html" toFile="pmd_report.html"/>

<!-- pmd所需要依赖包的classpath引用 -->

<classpath refid="classpath"/>

<!-- 要检查的项目源文件根目录 -->

<fileset dir="src">

<include name="**/*.java"/>

</fileset>

</pmd>

</target>

CPD任务：

<target name="cpd">

<!-- 定义任务和任务所属类所在的classpath -->

<taskdef name="cpd" classname="net.sourceforge.pmd.cpd.CPDTask"

classpathref="classpath"/>

<!-- 指明输出文件和判断属于copy & paste的标准 -->

<cpd minimumTokenCount="100" outputFile="cpd.txtl">

<!-- 要检查的项目源文件根目录 -->

<fileset dir="src">

<include name="**/*.java"/>

</fileset>

</cpd>

</target>

4. 运行ant pmd和ant cpd即可。

5. 参数说明：

- formatter，指明输出格式和文件。

- rulesetfiles，指明分析所需的规则文件，不同文件使用逗号分隔。

- failonerror，pmd执行出错是否中止构建过程。

- failOnRuleViolation，如果与规则冲突，是否中止构建过程。

- classpath，pmd所需的classpath。

- printToConsole，在发现问题时是否打印到ant log或控制台。

- shortFilenames，在输出报告中是否使用短文件名。

- targetjdk13，是否把目标定为jdk13，如不能使用assert。

- failuresPropertyName，在任务结束时，插入违反规则的号码

- encoding，读源文件时所采用的编码，如utf-8。

关于规则集合的说明，以及如何自定义规则请参见pmd的文档，文档中已说得相当清楚。

CheckStyle

使用ant task：

1. 复制checkstyle-all-3.3.jar到项目的classpath中。

2. 修改build.xml文件：

<taskdef resource="checkstyletask.properties"

classpath="${weblib.dir}/checkstyle-all-3.3.jar"/>

<target name="checkstyle" depends="init">

<!-- 指明checkstyle的分析所需的规则文件 -->

<checkstyle config="checkstyle33.xml">

<!-- 要检查的文件 -->

<fileset dir="${src.code}" includes="**/*.java"/>

<!-- 指明输出格式和文件名 -->

<formatter type="xml" toFile="report.xml"/>

</checkstyle>

<!-- 将xml文件转换成html文件 -->

<style in="report.xml" out="report.html" style="checkstyle-frames"/>

</target>

3. 运行ant checkstyle即可。

checkstyle的规则文件，即项目的代码规范，建议不要手工书写。可以使用checkstyle plug in在Eclipse配置后再导出。Checkstyle提供了缺省的xslt，用来进行xml的格式转换。它们都放在contrib目录中。Checkstyle同样也提供了自定义的check，但与PMD相比，书写要复杂。详细情况请参见checkstyle的文档。

检查表

- 为每个工具建立自己的目录和classpath变量。由于这些工具大多都使用了相同的开源软件，很容易会因为使用相同软件包的不同版本而相互干扰。这种问题非常隐蔽，在这种问题上花费时间和精力是非常不值得的。通过建立不同的目录和classpath，然后在对应的ant task中引用各自的classpath，可以有效的避免它。

- 将这些工具纳入项目的配置管理库中。这样可以方便而迅速的在另一台机器上重建构建环境，有效的保证了项目组中统一的构建环境。

- 重视这些输出，但是不要因为输出而困扰。它们仅仅是工具，要学会正确的对待它们。

- 三个工具都提供了自定义规则的接口，相比而言pmd书写最简单，findbugs功能最强。它们涉及AST（抽象语法树）和byte code相关的知识。