我曾經(jīng)和一個開源工程的作者爭論關(guān)于使用 Vector。一開始以為沒有用 ArrayList 的原因是因為項目在 JDK 1.2 之前啟動的，那時還沒有 java collection。
最后的爭論集中在 Vector 是否是線程安全的？因為框架大量使用 RMI，RMI 是天生非線程安全的，所以作者認(rèn)為采用了 Vector 來聲明成員變量后，類就是 Thread-safe 了。
或許，大家經(jīng)常也碰到類似的問題：Vector 與 ArrayList 的區(qū)別？
好多人一拍腦門就出：Vector 是線程安全的 (在任何情況下都是)。。。
原因可能是因為 Vector 的所有方法加上了 synchronized 關(guān)鍵字，從而保證訪問 vector 的任何方法都必須獲得對象的 intrinsic lock (或叫 monitor lock)，也即，在vector內(nèi)部，其所有方法不會被多線程所訪問。
但是，以下代碼呢：
if (!vector.contains(element))
vector.add(element);
...
}
這是經(jīng)典的 put-if-absent 情況，盡管 contains, add 方法都正確地同步了，但作為 vector 之外的使用環(huán)境，仍然存在 race condition: 因為雖然條件判斷 if (!vector.contains(element))與方法調(diào)用 vector.add(element); 都是原子性的操作 (atomic)，但在 if 條件判斷為真后，那個用來訪問vector.contains 方法的鎖已經(jīng)釋放，在即將的 vector.add 方法調(diào)用 之間有間隙，在多線程環(huán)境中，完全有可能被其他線程獲得 vector的 lock 并改變其狀態(tài), 此時當(dāng)前線程的vector.add(element); 正在等待（只不過我們不知道而已）。只有當(dāng)其他線程釋放了 vector 的 lock 后，vector.add(element); 繼續(xù)，但此時它已經(jīng)基于一個錯誤的假設(shè)了。
單個的方法 synchronized 了并不代表組合（compound）的方法調(diào)用具有原子性，使 compound actions 成為線程安全的可能解決辦法之一還是離不開intrinsic lock (這個鎖應(yīng)該是 vector 的，但由 client 維護)：
// Vector v = ...
public boolean putIfAbsent(E x) {
synchronized(v) {
boolean absent = !contains(x);
if (absent) {
add(x);
}
}
return absent;
}
所以，正確地回答那個“愚蠢”的問題是：
Vector 和 ArrayList 實現(xiàn)了同一接口 List, 但所有的 Vector 的方法都具有 synchronized 關(guān)鍵修飾。但對于復(fù)合操作，Vector 仍然需要進行同步處理。
這樣做的后果，Vector 應(yīng)該盡早地被廢除，因為這樣做本身沒有解決多線程問題，反而，在引入了概念的混亂的同時，導(dǎo)致性能問題，因為 synchronized 的開銷是巨大的：阻止編譯器亂序，hint for 處理器寄存一/二級緩存。。。