Groovy / Java Gotcha 一则

今天帮人捉虫，看到一个很有趣的关于数组切片的陷阱。代码如下：

   1: list = [1,2,3]

   2: subList = list[1..-1]

   3: ...很多很多行代码，但“没有”修改过list

   4:  

   5: subList.add(0,10)

   6: assert subList == list

按那个程序员的想法，subList 的初始值是 [2,3]，往首位塞个 1，不就变成了 [1,3] 吗？应该和 list 相等才对。

可惜，Groovy 不是这样认为的，断言毫不客气的失败了。

原因在于 subList 的类别，查看 subList.class 会发现这是一个 java.util.RandomAccessSubList （是个 private 类）。RandomAccessSubList 包含了三个值域，分别是

• backingList: 包含了原有列表的 reference
• offset: 从第几个偏移量开始切片
• size: 子列表的长度

从这个结构你大概就能猜出问题之所在了，subList 并没有在内存中重新分配一组空间来保存一个真正的子列表，而是采用了类似指针的技术“指出”了子列表所在的位置。其结果是，当调用 add 函数的时候，Groovy 其实是以 add 的第一参数加上 offset 为插入位置并在 list 内插入了元素 1，同时将 subList 的 size 值加 1。所以，最后的 list 为 [1,10,3]，而 subList 为 [10,3]。

这个陷阱的另一个形式是：

3: // ... N 行代码

   4: list.remove(0)

   5: // 又是 N 行代码

   6: println subList

Opps，这一次则是抛出 java.util.ConcurrentModificationException。（原因很简单，不说了）

由于这个陷阱只能在运行时被发现（我猜是不是有些 BUG 查找软件能找到这样的问题），因此，只有严密的单元测试才能发现漏洞。如果在你的单元测试没有能覆盖这里，嘿嘿……那就可能是一年以后在你哪个VIP客户的服务器上爆炸的定时炸弹了。（一般没有单元测试的代码都写的很长很长很长，要定位这样的问题绝对不简单啊）

PS：这也是为什么我很多时候不计代价的使用 clone 来复制对象或是重新逐个元素地生成集合的原因。在 Scala 中，由于 List 是不可变的（Map 与 Set 则具备了可变和不可变的版本），从而也就很好的避免了这样的问题。如果你的 api 库里面有第三方的不可变集合库，好好利用它们。

Technorati Tags: Groovy