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
ThreadLocal是一種confinement，confinement和local及immutable都是線程安全的（如果JVM可信的話）。因為對每個線程和value之間存在hash表，而線程數量未知，從表象來看ThreadLocal會存在內存泄露，讀了代碼，發現實際上也可能會內存泄露。
事實上每個Thread實例都具備一個ThreadLocal的map，以ThreadLocal Instance為key，以綁定的Object為Value。而這個map不是普通的map，它是在ThreadLocal中定義的，它和普通map的最大區別就是它的Entry是針對ThreadLocal弱引用的，即當外部ThreadLocal引用為空時，map就可以把ThreadLocal交給GC回收，從而得到一個null的key。
這個threadlocal內部的map在Thread實例內部維護了ThreadLocal Instance和bind value之間的關系，這個map有threshold，當超過threshold時，map會首先檢查內部的ThreadLocal（前文說過，map是弱引用可以釋放）是否為null，如果存在null，那么釋放引用給gc，這樣保留了位置給新的線程。如果不存在slate threadlocal，那么double threshold。除此之外，還有兩個機會釋放掉已經廢棄的threadlocal占用的內存，一是當hash算法得到的table index剛好是一個null key的threadlocal時，直接用新的threadlocal替換掉已經廢棄的。另外每次在map中新建一個entry時（即沒有和用過的或未清理的entry命中時），會調用cleanSomeSlots來遍歷清理空間。此外，當Thread本身銷毀時，這個map也一定被銷毀了（map在Thread之內），這樣內部所有綁定到該線程的ThreadLocal的Object Value因為沒有引用繼續保持，所以被銷毀。
從上可以看出Java已經充分考慮了時間和空間的權衡，但是因為置為null的threadlocal對應的Object Value無法及時回收。map只有到達threshold時或添加entry時才做檢查，不似gc是定時檢查，不過我們可以手工輪詢檢查，顯式調用map的remove方法，及時的清理廢棄的threadlocal內存。需要說明的是，只要不往不用的threadlocal中放入大量數據，問題不大，畢竟還有回收的機制。
綜上，廢棄threadlocal占用的內存會在3中情況下清理：
1 thread結束，那么與之相關的threadlocal value會被清理
2 GC后，thread.threadlocals(map) threshold超過最大值時，會清理
3 GC后，thread.threadlocals(map) 添加新的Entry時，hash算法沒有命中既有Entry時，會清理
那么何時會“內存泄露”?當Thread長時間不結束，存在大量廢棄的ThreadLocal，而又不再添加新的ThreadLocal（或新添加的ThreadLocal恰好和一個廢棄ThreadLocal在map中命中）時。