Vector 是執行緒安全的？

vector 是否是執行緒安全的？因為框架大量使用 rmi，rmi 是天生非執行緒安全的，所以作者認為採用了 vector 來宣告成員變數後，類就是 thread-safe 了。

或許，大家經常也碰到類似的問題：vector 與 arraylist 的區別？

好多人一拍腦門就出：vector 是執行緒安全的 (在任何情況下都是)。。。

原因可能是因為 vector 的所有方法加上了 synchronized 關鍵字，從而保證訪問 vector 的任何方法都必須獲得物件的intrinsic lock(或叫monitor lock)，也即，在vector內部，其所有方法不會被多執行緒所訪問。

但是，以下**呢：

if (!vector.contains(element))

vector.add(element);

...}

這是經典的put-if-absent情況，儘管 contains, add 方法都正確地同步了，但作為 vector 之外的使用環境，仍然存在race condition: 因為雖然條件判斷

if (!vector.contains(element))與方法呼叫

vector.add(element);

都是原子性的操作 (atomic)，但在 if 條件判斷為真後，那個用來訪問vector.contains 方法的鎖已經釋放，在即將的 vector.add 方法呼叫之間有間隙，在多執行緒環境中，完全有可能被其他執行緒獲得 vector的 lock 並改變其狀態, 此時當前執行緒的

vector.add(element);

正在等待（只不過我們不知道而已）。只有當其他執行緒釋放了 vector 的 lock 後，

vector.add(element);

繼續，但此時它已經基於乙個錯誤的假設了。

單個的方法 synchronized 了並不代表組合（compound）的方法呼叫具有原子性

，使 compound actions 成為執行緒安全的可能解決辦法之一還是離不開

intrinsic lock(這個鎖應該是 vector 的，但由 client 維護)：

// vector v = ...

public boolean putifabsent(e x)

}return absent;

}所以，正確地回答那個「愚蠢」的問題是：

vector 和 arraylist 實現了同一介面 list, 但所有的 vector 的方法都具有 synchronized 關鍵修飾。但對於復合操作，vector 仍然需要進行同步處理。

這樣做的後果，vector 應該盡早地被廢除，因為這樣做本身沒有解決多執行緒問題，反而，在引入了概念的混亂的同時，導致效能問題，因為 synchronized 的開銷是巨大的：阻止編譯器亂序，hint for 處理器寄存一/二級快取。。。