今天部门的一个同事很痛苦的向我求助。问题是关于一个新功能的测试，如果是一般的功能也就罢了，关键是这个功能是基于我曾做过的一个框架的，而这位同事由于是临时被指派的工作，对我的那个东西完全不熟悉。

问题就在这，当时写那个框架的时候目标就是为了部门内部其他项目的高度复用，也就是说其他项目如果有类似需求，使用我们的框架经过一系列配置就可以满足需求，至多需要一个简单的二次开发过程，可能需要提供若干业务相关的接口实现，编译到动态共享库中，把该库的名字和位置写到配置中即可。

这个框架的确消除了很多复杂的且易在各个项目中重复分布的功能，在部门的几个项目中都有使用；而且当初为了使框架更加通用，更加利于二次开发，我们采用了很多外部配置的方式，并且首次在C组采用xml的配置文件，毕竟xml的表达能力要比单纯的key = value型配置文件强大许多，可读性也更好，当初的目标毕竟是理想的。

实际的情况是，这些为了通用型留出的配置接口在实践中用的很少，但是其他第一次接触该框架的维护人员在了解它的时候又恰恰被过多的配置弄得晕头转向，无奈之下就来问我。复杂性由如何开发这些功能，到如何使用理解我的框架了。复杂性转移了。这也让我想起了最近看的关于J2EE中关于EJB的一些言论了。当初Sun在提出J2EE规范的时候更多的是考虑如何屏蔽掉分布式应用的复杂性，让开发人员不用关心分布式技术难点，结果导致最初的EJB只有Remote接口；而在实际应用中大部分Web应用都是部署在Single Machine Sing JVM上的，而Remote接口反倒降低了J2EE服务器的性能，这也许和复杂性关系还不是很大。继续说EJB，到后来开发人员发现要想开发出好的符合J2EE精神的应用，还是要去了解分布式协议的，这就大大提高了EJB的使用门槛，使大部门人望而却步。其实到后来的框架时代我觉得也是一样，框架的出现，一来可以让大家避免使用EJB的痛苦，开发出without EJB的应用，但是同时大家却都忘记了框架本身的复杂性了。试想要开发出好的Web应用，如果不对框架本身有所了解可能吗？特别是框架本身蕴含的各种设计思想，这也充分证明了复杂性的’此起彼伏’的特点。

下面的问题就是：复杂性没有消失，为什么大家还在用呢？目前软件业都在努力作着这些事情，即尽量让开发人员只关心问题域，业务域。无论是EJB还是各种轻量级容器框架的出现都是在努力向着这个方向前进，毕竟你在走向成功的道路上无需再reinvent the wheel了，虽然了解wheel的过程仍然复杂，仍然坎坷，但是照比以前也要好上很多了。

想到哪，说到哪，有些’语无伦次’，不知道大家能不能理解其中的意思。:)

最近自己曾经辛苦耕耘过的两个项目同时上线，相关问题也就逐渐暴露出来。工作这两年多时间以后，使我有这样感觉：’测试永远都是不完备的’，有些问题只能在商用过程中发现，呵呵，明确一点啊我不是搞测试的:)

在解决问题过程中的感悟往往是最深刻的，解决问题的过程往往真的像是警察在侦破案件，往往一点点罪犯留下的蛛丝马迹就会让神探们找到线索，并迅速破案。

最近两天一直在一个bug上煎熬着，终于于昨天发现蛛丝马迹并醒悟过来，很有意思的一个bug，和大家一起来分享一下。

这周三我们组的一个同事在现网商用运行的系统上发现我们的程序出现了一个core，对于unix后台服务程序来说，出core是一件很严重的事情，而这个core也直接导致了进程的死锁，消息的积压。

通过gdb调试core发现，问题出在遍历一棵放在共享内存中的B+树，从B+树中取出的地址是一个无效地址，所以当使用memcpy拷贝这个地址上的数据时core出现了。

说到这不能不提及一些背景资料了，在开发这个项目的时候，我们在实现业务需求的时候发现需要部门B+树操作库提供一个完备的遍历接口，可是却发现已有的B+树接口并不提供遍历功能，这显然是库接口的不完备造成的，大家都知道树的遍历是一个特别常见的功能。我们决定对该库进行扩充，添加一个遍历接口；不过，我们在添加接口的时候发现，库内部提供一个叫get_next_key的内部接口，但是该接口的问题在于它返回的下一个key并不是总存储有效数据的。按我们的正常逻辑，如果我们提供一个get_next_key，如果遍历到最后一个有效节点后再继续遍历，则应该返回NOT_FOUND之类的返回值，而这个库中的get_next_key仍然给你返回一个空闲节点，而这个节点中的数据是随机值。了解到这种情况，考虑到时间原因，我定义了一个xx_get_next_key的外部接口，在这个接口实现中我仍然选择使用get_next_key来辅助工作，并且在xx_get_next_key的接口说明中解释到需要业务层控制调用xx_get_next_key的次数。

比如说如果目前B+树中有100个有效节点，那么我调用100次xx_get_next_key均会返回有效节点，如果再100次后继续调用该接口，返回的可能就是非有效数据了。

这样在业务层，我写下了如下代码：
int get_default_xx_info(…) {
 int total = 0;
 int i     = 0;
 xx_get_bptree_msgc(&total);

 for (i =0 ; i < total; i++) {
  调用xx_get_next_key遍历B+树；
 }
}

就是这样的代码在系统运行很长时间后出问题了，通过gdb跟踪到xx_get_next_key的内部实现中，最开始我怀疑是不是对以前的B+树操作库不熟悉，代码调用的不对，后经确认，xx_get_bptree_msgc的实现代码无误。而咋一眼看上去业务层的逻辑也没有问题亚。在查了一个下午之后，仍然没有结果。第二天继续，结合日志和GDB跟踪输出，发现这样的一个很奇怪的现象，而且在我们的分布式系统的两台机器上现象是一致的。

通过日志看出，在调用get_default_xx_info之前，日志打印出来当前B+树中有12610个有效数据节点；而通过GDB跟踪栈上信息，发现B+树中的有效节点是12609个。也就是说我们通过xx_get_bptree_msgc调用得到total值是12610个，而在多次调用xx_get_next_key的间隙时间里，B+树中的节点被其他进程删除了，前面我们提到过我们的B+树是进程间共享的。这样的话，xx_get_next_key使用的约束条件被破坏了，发生了多一次的调用，问题应该就在这。的确，在xx_get_next_key内部执行时是有写锁保证其他进程不会对B+树进行修改的，但是当xx_get_next_key结束一次执行，释放锁资源后，阻塞在该锁上的其他进程对B+树的操作很有可能就发生了，也就是说我们没有保证整个完整遍历过程的事务性。真相大白了。修改也容易了，但是由于库接口的不完备性，使得修改后的逻辑看起来也很别扭，业务层和底层库有交叉了。