11

Java的命运

作者:chenqiuge 分类:CTO视点, 架构实践 13 Comments »

文 / Peter Seibel  译 / 郝培强

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

最糟糕的Bug

Seibel:我们聊聊调试吧。你遇到的最糟糕的Bug是什么?joshua

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

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

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

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

我编写了自己的锁管理器,所以我怀疑是它出了问题。但是锁管理器轻松地通过了测试。最后,我觉得问题不在锁管理器,而是它依赖的互斥体的实现!那时候操作系统还不支持多线程,我们需要写自己的多线程包。原来负责互斥体代码的工程师,不小心把我们的Solaris的线程实现中的lock和try-lock的汇编代码的标签弄混了。所以,每次你以为你在调用lock的时候,其实调用的是try-lock,反之亦然。也就是说当真的有争用发生的时候——在当年其实是很罕见的——第二个线程直接就进入了第一个线程的临界区,因为第一个线程也没有锁住。搞笑的是,这也就是说,整个公司几个星期都在运行没有互斥体的程序,而且谁都不知道。

阅读全文 »

标签:
阅读:24,934 次
preload preload preload
京ICP备06065162