隐藏的数据炸弹可能是导致不正常崩溃的罪魁祸首

核心提示：内容： 百万分之一 破坏者数据错误模式 语法原因 语义原因 治疗和预防措施 结论 参考资料 关于作者 对本文的评价 隐藏的数据炸弹可能是导致不正常崩溃的罪魁祸首Eric E. Allen（eallen@cyc.com）java 开发人员带头人，Cycorp, Inc.程序由于损坏的数据而崩溃时，隐藏的数据炸弹可能是导致

　　内容：
百万分之一
破坏者数据错误模式
语法原因
语义原因
治疗和预防措施
结论
参考资料
关于作者
对本文的评价

隐藏的数据炸弹可能是导致不正常崩溃的罪魁祸首
Eric E. Allen（eallen@cyc.com）
java 开发人员带头人，Cycorp, Inc.

程序由于损坏的数据而崩溃时，破坏者可能难以捉摸。一个程序经常在处理自身内部的数据的过程中就会崩溃，这甚至会发生在程序已经不出错误地运行了很长一段时间以后。本文将讨论一种错误模式（它可能就是引起这种崩溃的罪魁祸首），还有它为什么会存在，以及在它出现之前和之后的几种消除它的方法。
百万分之一
作为一个勤奋的开发人员，您已经为几个需要更好地访问复杂的大量数据存储的客户安装了一个应用程序，它编写良好，而且经过了充分测试。

对每个客户，现场测试阶段都畅通无阻地通过了。您在去银行的路上，心里极少考虑这六个月来的软件审查，这时您的传呼机响了起来。您的一个客户在使用您的软件运行一个报表时，系统崩溃了。

您赶到出事地点，运行了一个随机测试。工作良好。您运行另一个。没出现问题。您又运行了数百个测试。还是没有问题。您又检查了持续六个月运行这个应用程序的其它客户。没有投诉。

您重复运行那个引起问题的报表。崩溃！怎么回事？

快速跟踪代码
清单 1. 样本，外部源文本文件
这种数据由程序读取。可以从文件、键盘、麦克风、网络或者电子手套进行输入。
清单 2. 使用 StreamTokenizer 插入域和区域字符串
这种插入两个 String 的方法是否行得通取决于从文本文件获取 String 的方式。

清单 3. 数据破坏者
这个数据错误的示例可以引起程序崩溃。

破坏者数据错误模式
许多程序需要频繁访问和处理内部储存的数据来执行各种复杂的任务。这种数据可以从内存中的大型结构、数据库或网络上检索得到。

这类程序非常轻易遭受损坏的内部数据引起的崩溃。我称这种错误模式为破坏者数据模式，是因为这种数据可以无限期地存在于系统中（很象冷战中的潜伏间谍一样），不引发任何问题，直到访问一段特定的数据时，损坏的数据才象炸弹一样爆炸。

语法原因
假定我们有一个 JDBC 应用程序，它存储了一个名为 Mapping 的数据库表，该表将 String 的名称映射到一系列元素的集合。（请参阅参考资料，以获取关于 JDBC API 的更多信息。）每个集合中的每个元素都引用另一个表中的一个要害字（该表名为 PRoperties，包含这些元素的不同已知属性）。

这样说吧，Mapping 和 Properties 表最初都是从一个文本文件中读取的，这个文本文件由外部源（外部意为不是内部产生的任意数据源）发展而来，而在外部源中，每行都以一个名称开头，后面跟着对应集合的表达，如下所示：

清单 1. 样本，外部源文本文件

In the Mapping file:

apples {macintosh, gala, golden-delicious}

trees {elm, beech, maple, pine, birch}

rocks {quartz, limestone, marble, diamond}

...

In the Properties file:

macintosh {color: red, taste: sour}

gala {color: red, taste: sweet}

diamond {color: clear, rigidity: hard, value: high}

...

可以对 Mapping 和 Properties 表条目进行语法分析并将其传递到一个方法中，此方法会把这些条目插入到一个数据库中。但这种方法存在潜在的缺陷。例如，假定我们已经编写了一个处理 JDBC 兼容数据库的类。遵照 JDBC API，我们可以定义一个 PreparedStatement 对象并使用它把信息传递到数据库中，如下所示：

清单 2. 使用 StreamTokenizer 插入域和区域字符串

...

PreparedStatement insertionStmt =

con.prepareStatement("INSERT INTO MAPPING VALUES(?,?)");

...

public void insertEntry(String domain, String range)

throws SQLException {

insertionStatement.setString(1, domain);

insertionStatement.setString(2, range);

insertionStatement.executeUpdate();

}

以这种方式插入两个 String 合适与否取决于从文本文件中获取 String 的方式。例如，假定一个简单的正则表达式匹配工具被用来将每一行拆分成两个 String：

一个 String 包含第一个 String 之前的全部字符。
一个 String 包含第一个 String 之后的全部字符。
这种对文本文件进行的基本的语法分析不会捕捉数据的较小损坏。例如，假如其中的一行是如下的形式：

清单 3. 数据破坏者

trees {elm, beech, maple, pine birch}

“pine”和“birch”之间的逗号漏掉了。这样的错误很轻易由生成文件的工具的错误或手工编辑文件而造成。

无论如何，数据都会以损坏的形式进入数据库，静静地等待被访问。假如用于访问数据的方法要求用逗号和空格来分隔条目，在读取这个条目的时候就会导致崩溃。

假如程序只是简单地使用逗号来区分集合中的元素，更加严重的错误都可能发生。系统可能将“pine birch”解释为一个单独的树类型（数据的单个条目），并将这个错误进一步传播到计算中去。

语义原因
我们的示例是一个违反了数据的一个简单的语法特征演示。当然，这不是可能损坏数据的唯一途径。

语义级别上的限定因素也可能被破坏。在我们的示例中，Mapping 表中数据的一种要求是，每个集合中的每个元素都是 Properties 表中的一个域条目。假如这种不变量被破坏，程序就会在试图读取一个在 Properties 表中并不存在的元素时失败，导致异常被抛出。

在本文中，我使用数据库条目作为示例，但是破坏者数据错误会以各种方式出现 ? 与数据输入的方式一样多。当程序读取数据时，不管它是从文件、键盘、麦克风、网络还是电子手套读取，破坏者数据错误都有可能存在。

治疗和预防措施
最好的防御破坏者数据错误的方法是编译器和解释器开发人员普遍采用的那种方法。由于输入到这些程序的数据是如此复杂，开发人员别无它法，只有在第一次读取输入内容的时候就执行尽可能彻底的完整性检查，而不是在以后访问的时候再进行检查。

语法分析作为消除错误的方法
实际上，对输入内容进行语法分析的方法恰好是消除大量这些错误的途径。不幸的是，很多程序员（他们从来不会考虑编写没有语法分析器的编译器）没有能够为较简单的数据编写足够的语法分析方法。较简单的数据的语法分析当然要轻易一点，但是这并不能成为根本不对它进行语法分析的借口。

任何读取数据的程序 ? 不管有多简单 ? 都应该对数据进行语法分析。究竟，这种程序在它的有效输入的集合所定义的“语言”上可以被看作是一个编译器（或者解释器）。

从经历过的人那里吸取一点经验吧。我年轻时比较鲁莽，犯了个错误 ? 处理数据的时候没有作适当的语法分析，然后我就遭受了那样的后果 ? 猖獗的破坏者。我可不推荐这种经验。

类型检查作为消除错误的方法
编译器为许多语言（当然包括 Java 语言）所作的检查的另一种普遍形式是类型检查。类型检查是程序完整性上的语义级别检查的一个示例。

假如类型系统是健壮的（就象 Java 类型系统一样），这种完整性检查确实可以保证很多错误永远不会在运行时产生。象语法分析一样，编译器编写者的这个示例可以应用于其它经常在其输入数据上规定语义级别不变量的程序。这些不变量通常不是明确的，但可以通过进行对应的检查来把它们变成明确的。

反复操作作为消除错误的方法
当然，假如您怀疑这种错误模式的出现与已经读入并存储的数据有关，反复操作数据也是明智的：访问在实际配置的应用程序中可能要操作的每个数据，保证一切都象期望的那样工作。通过这种方法，您也能够修正简单的错误。

关于消除错误方法的一个告诫
我的意思当然不是暗示执行足够的检查来消除程序中的所有破坏者数据总是可行的。假如真是那样，就不会有引起错误模式的潜在问题了。

一个破坏者在开始带来灾难之前为什么会无法觉察是有很多原因的：

执行所有检查必需的数据直到破坏者数据已经存储了以后才可用。
整套的限定元素甚至是无法计算的（就象编译器和解释器的情况一样）。
限定元素可以计算，但是程序无法访问检查它们所需要的资源。
在这些情况下，我们最好是尽量消除可能的破坏者形式。

结论
下面是破坏者数据错误模式的总结：

模式：破坏者数据
症状：一个存储和处理复杂的输入数据的程序在执行任务时意外地崩溃，而这个任务和其它没有产生任何问题的任务很相似。
起因：一些内部数据被损坏，可能是语法上的损坏，也可能是语义上的。
治疗和预防措施：对输入数据尽量多地执行完整性检查，而且要尽量早执行。对于已经损坏的持久数据，研究它并检查其完整性。
消除数据破坏者的黄金法则：任何读取数据的程序都应该对数据进行语法分析。愿您能顺利消除这些错误！

参考资料

参与本文的讨论论坛。
要了解有关 JDBC 的更多信息，请查看关于本主题的 Java 数据库连接教程（developerWorks，2000 年 4 月）。
学习 Java 调试教程（developerWorks，2001 年 2 月）来获得一般调试技巧的帮助。
访问 Enhydra 主页来下载 Instant DB，一个免费的 JDBC 驱动程序。尽管要让它适用于大型数据库还需要一些技巧，但用它处理中等大小的表还是不错的。
尽管遭受非议，正则表达式读取器还是很强大的工具。看看 OroMatcher，一个 Java 语言的正则表达式匹配器，它读取 Perl 类型的正则表达式。
Java 语言有很多类似于 Lex 和 Yacc 的东西（标准语法分析器工具），请看一下 ANTLR 的一个这样的例子。
阅读 Eric 关于错误模式的 完整系列。

关于作者
Eric Allen 在 Cornell 大学获得计算机科学和数学的学士学位。他目前是 Cycorp 公司的 Java 软件开发人员带头人，还是 Rice 大学的编程语言小组的兼职硕士生。他的研究涉及在源程序和字节码层次上的正规语义模型和 Java 语言扩展的开发。目前，他正在为 NextGen 编程语言实现一种从源代码到字节码的编译器，这也是 Java 语言的泛型运行时类型的一种扩展。请通过 eallen@cyc.com 与 Eric 联系。