本文是Common Lisp专家Peter Seibel对Google公司首席Java架构师Joshua Bloch的访谈，谈到他所遇到的最糟糕的Bug以及Java的命运。

　　最糟糕的Bug

　　Seibel：我们聊聊调试吧。你遇到的最糟糕的Bug是什么？

　　Bloch：提起Bug我立马就想到了一个，这个Bug很严重，而且很搞笑。那是90年代初，我在匹兹堡的Transarc公司工作时。我在很紧的工期下提交了一个事务共享内存的实现。我在限期内完成了设计和实现，甚至还在过程中做出了几个可重用的组件。但是这么匆忙地写了很多新代码，我还是挺担心的。

　　为了测试这些代码，我写了一个叫做“乱撞”的很长的程序出来。它运行了大量的事务，每个事务又包含了嵌套的事务，嵌套到可以嵌套的最大深度。每个嵌套事务都可能会加锁，以递增的顺序读取共享数组里面的几个元素，对每个元素都加入点东西，保持数组中所有元素的和为0，还是不变量。这些事务要么提交，要么取消，如90%的提交，10%的取消，其他比例也可以。多个线程同步运行于这些事务之上，长时间地访问数组。因为我测试的是一个共享内存机制，所以我同时运行多个有多个线程的“乱撞”程序，每个有自己的进程。

　　在一般的并发级别下，“乱撞”轻松过关。但是当我真正调高并发级别时，我发现“乱撞”偶尔，仅仅是偶尔，无法通过一致性检查。我不知道这是怎么搞的。这只能是我的错，因为新代码都是我一个人写的。

　　我花了大约一个星期，痛苦地为每个组件写了彻底的单元测试，所有的单元测试都通过了。然后我为每个内部数据结构写了详细的一致性检查，这样我就可以在每次变化后调用这些一致性检查，直到测试失败为止。最后，我终于发现一个底层的一致性检查失败了，这个问题无法重现，但是某种程度上可以帮助我分析问题出在哪里。最后，我得出了确实的结论——我的锁根本不工作。两个事务锁定、读写同一个值的时候，产生了并发的读—修改—写回操作，而后一次写入毁掉了第一次的写入。