Java的內存模型中Thread會附有自己的堆棧，寄存器，必要時需要和主存即heap之間同步。
可以使用Synchornized關鍵字和Concurrent包中的Lock可以保證線程互斥和可見性。
互斥性體現在類鎖或者對象鎖上，每個對象自身都包含一個監視器，該監視器是一個每次只能被一個線程所獲取進入的臨界區，可以通過wait和notify來退出和準入臨界區。可以看出這是一個生產者-消費者的模型。而Concurrent包中的Lock為了能夠獲得更好的性能和更好的擴展性，以及不依賴于關鍵字的可讀代碼，自己實現了這樣一個生產消費隊列，也就是AbstractQueuedSynchronizer，被稱為AQS的機制。每個Lock都內置了一個AbstractQueuedSynchronizer。需要說明的是AbstractQueuedSynchronizer內部實現采用了CAS機制，通過getState, setState, compareAndSetState訪問控制一個32bit int的形式進行互斥。
那么可見性是如何保證的呢？
對于關鍵字的同步機制，其實可見性就是線程和主存之間的同步時機問題。共有4個時間點需要注意：
1 獲取或釋放類鎖/對象鎖的時候。Thread保證reload/flush全部變更
2 volatile就是flush on write或者reload on read
3 當線程首次訪問共享變量時，可以得到最新的結果。
題外：所以在構造方法中公布this時很危險的。簡單的說，就是構造時不逃脫任何變量，不開啟新的線程，只做封裝。關于安全構造，請參考
http://www.ibm.com/developerworks/cn/java/j-jtp0618/#resources
4 線程結束時，所有變更會寫回主存
關于Concurrent Lock如何實現可見性的問題，Doug Lea大俠，只在他的論文中提到，按照JSR133，Unsafe在getState, setState, compareAndSetState時保證了線程的變量的可見性，不需要額外的volatile支持，至于具體這些native做了哪些magic就不得而知了，總之，最后的contract就是保證lock區間的共享變量可見性。開發團隊被逼急了就這樣回答：
There seems to be a real reluctance to explain the dirty details. I think the question was definitely understood on the concurrent interest thread, and the answer is that synchronized and concurrent locking are intended to be interchangable in terms of memory semantics when implemented correctly. The answer to matfud's question seems to be "trust us.”
不過這個地方的確是開發團隊給我們用戶迷惑的地方，在同樣應用了CAS機制的Atomic類中，都內嵌了volatile變量，但是再lock塊中，他告訴我們可以保證可見性。
感興趣的同學可以下面的兩個thread和Doug Lea的thesis：
http://altair.cs.oswego.edu/pipermail/concurrency-interest/2005-June/001587.html
http://forums.sun.com/thread.jspa?threadID=631014&start=15&tstart=0
http://gee.cs.oswego.edu/dl/papers/aqs.pdf