如果你發(fā)現(xiàn)在一個(gè)接口使用有如下定義方法：
 

public String[] getParameters();

那么你應(yīng)該認(rèn)真反思。數(shù)組不僅僅老式，而且我們有合理的理由避免暴露它們。在這篇文章中，我將試圖總結(jié)在Java API中使用數(shù)組的缺陷。首先從最出人意料的一個(gè)例子開(kāi)始。
數(shù)組導(dǎo)致性能不佳

你可能認(rèn)為使用數(shù)組是最快速的，因?yàn)閿?shù)組是大多數(shù)collection實(shí)現(xiàn)的底層數(shù)據(jù)結(jié)構(gòu)。使用一個(gè)純數(shù)組怎么會(huì)比使用一個(gè)包含數(shù)組的對(duì)象性能更低？

讓我們先從這個(gè)看起來(lái)很熟悉的普遍的習(xí)慣用法開(kāi)始:
 

public String[] getNames() {
 return namesList.toArray( new String[ namesList.size() ] );
}

這個(gè)方法從一個(gè)用來(lái)在其內(nèi)部保存數(shù)據(jù)的可變集合處創(chuàng)建了一個(gè)數(shù)據(jù). 它通過(guò)提供一個(gè)確切大小的數(shù)組來(lái)嘗試優(yōu)化數(shù)組的創(chuàng)建. 有趣的是，這一“優(yōu)化”使得其比下面的更簡(jiǎn)單的版本速度還要慢(請(qǐng)看圖表中綠色VS橘色條):
 

public String[] getNames() {
 return namesList.toArray( new String[ 0 ] );
}

不過(guò)，如果方法返回的是一個(gè)List, 創(chuàng)建防御式的副本又更加的快了 (紅條):
 

public List<String> getNames() {
 return new ArrayList( namesList );
}

不同之處在于一個(gè)ArrayList將它的數(shù)據(jù)項(xiàng)放在一個(gè)Object[]數(shù)組中，并且使用的是無(wú)類型的toArray方法，其比有類型的方法要快很多(藍(lán)條). 這是類型安全的，因?yàn)闊o(wú)類型的數(shù)組時(shí)封裝在由編譯器檢查的泛型類型ArrayList<T>中的.

這個(gè)圖標(biāo)展示了一個(gè)在Java 7上n=5的參考標(biāo)準(zhǔn). 不過(guò)，更多的數(shù)據(jù)項(xiàng)或者是另外一個(gè)VM情況系啊，這幅圖片并不會(huì)改變太多. CPU的開(kāi)銷可能并不會(huì)太劇烈，但是會(huì)有增長(zhǎng). 機(jī)會(huì)有一個(gè)數(shù)組的使用者應(yīng)該將其轉(zhuǎn)換到一個(gè)集合中去，以便利用它做任何事情, 然后將結(jié)果轉(zhuǎn)換回一個(gè)數(shù)組，來(lái)送進(jìn)另外一個(gè)接口的方法中，諸如此類做法.

是用一個(gè)簡(jiǎn)單的ArrayList，而不是一個(gè)數(shù)組來(lái)提升性能，無(wú)需再動(dòng)太多的手腳. ArrayList 為封裝的數(shù)組增加了32字節(jié)的恒定開(kāi)銷. 例如，一個(gè)有十個(gè)對(duì)象的數(shù)組需要104字節(jié)，一個(gè)ArrayList 136字節(jié).

使用 集合，你甚至可能決定返回內(nèi)部列表的一個(gè)不可修改的版本:
 

public List<String> getNames() {
 return Collections.unmodifiableList( namesList );
}

此操作會(huì)在固定的市價(jià)運(yùn)行，因此他比任何上述其它的方法都要快很多（黃條）. 其同一個(gè)防御式的拷貝不同。一個(gè)不可修改的集合將會(huì)在你的內(nèi)部數(shù)據(jù)變化時(shí)跟著變化。如果變化發(fā)生了，客戶端會(huì)在迭代數(shù)據(jù)項(xiàng)時(shí)運(yùn)行到一個(gè)ConcurrentModificationException中. 可以認(rèn)為它是一個(gè)糟糕的設(shè)計(jì)，接口提供了一個(gè)在運(yùn)行時(shí)拋出一個(gè)UnsupportedOperationException. 不過(guò)，至少對(duì)于內(nèi)部的使用，這個(gè)方法對(duì)于一個(gè)防御式的拷貝而言，會(huì)是一個(gè)高性能的選擇 - 一些不可能使用數(shù)組實(shí)現(xiàn)的東西.

數(shù)組定義一個(gè)結(jié)構(gòu)，而不是一個(gè)接口

Java 是一門(mén)面向?qū)ο蟮恼Z(yǔ)言。面向?qū)ο蟮暮诵母拍罹褪翘峁┮恍┓椒▉?lái)訪問(wèn)和操作它們的數(shù)據(jù)，而不是直接對(duì)數(shù)據(jù)域進(jìn)行操作. 這些方法創(chuàng)建一個(gè)接口來(lái)描述你可以在對(duì)象上面做的事情.

由于java已經(jīng)對(duì)性能做了設(shè)計(jì)，原生類型和數(shù)組已經(jīng)被融合進(jìn)了類型系統(tǒng)之中. 對(duì)象可以使用數(shù)組來(lái)在內(nèi)容高效地存儲(chǔ)數(shù)據(jù). 然而，即使通過(guò)數(shù)組來(lái)呈現(xiàn)一個(gè)可變集合的元素，它們也不會(huì)提供任何方法來(lái)訪問(wèn)和操作這些元素. 事實(shí)上，除了直接訪問(wèn)的替換元素之外，在數(shù)組上你沒(méi)有多少其它事情可以做. 數(shù)組甚至連toString 和 equals 都沒(méi)有一個(gè)有意義的實(shí)現(xiàn), 而集合卻有:
 

String[] array = { "foo", "bar" };
List<String> list = Arrays.asList( array );
 
System.out.println( list );
// -> [foo, bar]
System.out.println( array );
// -> [Ljava.lang.String;@6f548414
 
list.equals( Arrays.asList( "foo", "bar" ) )
// -> true
array.equals( new String[] { "foo", "bar" } )
// -> false

不同于數(shù)組，集合的 API 提供了許多有用的方法來(lái)訪問(wèn)元素. 用戶可以檢查包含的元素，提取子列表或者計(jì)算交集. 集合可以向數(shù)據(jù)層添加特定的特性, 諸如線程安全，同時(shí)將實(shí)現(xiàn)原理保持在內(nèi)部可見(jiàn).

通過(guò)使用一個(gè)數(shù)據(jù)，你定義了數(shù)據(jù)被保存在內(nèi)存中的哪個(gè)地方. 通過(guò)使用一個(gè)集合，你定義了用戶可以在數(shù)據(jù)上做的操作.

數(shù)組不是類型安全的

如果你依賴于編譯器檢查的類型安全，小心對(duì)象數(shù)組. 下面的代碼會(huì)在運(yùn)行時(shí)奔潰，但是編譯器找不出問(wèn)題所在:

Number[] numbers = new Integer[10];
numbers[0] = Long.valueOf( 0 ); // throws ArrayStoreException

原因是數(shù)組是“協(xié)變式”的, 比如，如果 T 是S 的一個(gè)子類型, 那么 T[] 就會(huì)是 S[] 的一個(gè)子類型. Joshua Bloch 在其著作 Effective Java 涵蓋了所有的理論, 每一個(gè)Java開(kāi)發(fā)者必讀.

歸因于這個(gè)行為，暴露數(shù)組類型的接口允許返回聲明數(shù)組類型的一個(gè)子類型, 導(dǎo)致了一個(gè)怪異的運(yùn)行時(shí)異常.

Bloch 同時(shí)也解釋說(shuō)，數(shù)組與泛型類型不兼容. 因?yàn)閿?shù)組會(huì)在運(yùn)行時(shí)強(qiáng)制要求有類型信息，而泛型則會(huì)在編譯時(shí)被檢查，泛型類型不能被放到數(shù)組中.

•     一般而言，數(shù)組和泛型不能很好的融合。如果你發(fā)現(xiàn)自己在融合它們而得到了一個(gè)編譯時(shí)錯(cuò)誤或者警告，那你的第一反應(yīng)應(yīng)該是用list去替換數(shù)組.

- Joshua Bloch, Effective Java (第二版), 第29條
總結(jié)

數(shù)組底層的語(yǔ)言構(gòu)造、它們會(huì)被用在實(shí)現(xiàn)中，但是它們不應(yīng)該想其它的類暴露. 在一個(gè)接口方法中使用數(shù)組違背了面向?qū)ο蟮脑瓌t，它會(huì)導(dǎo)致違和的API，并且它也可能給類型安全和性能造成短板.

最新評(píng)論