minglight

為了不誤導大家,把一些看完Source的進階心得寫在這兒

1. 把Map<Thread,value>放在ThreadLocal的缺點
    在某些情況下Thread不會重複使用. 例如Web環境,Container會產生一個新的Thread來處理Request-Response,因此如果ThreadLocal設計方式是ThreadLocal-簡介,將Map放在ThreadLocal中,你會發現這個Map越來越大,越來越大,要直到你重開Server才會重置 ( 以上純屬個人推論 XD )


2. ThreadLocal實際運作方式
    ThreadLocal並不會自己存放Map,而是把Map放到Thread裡面去!!
    Thread中會有一個ThreadLocalMap<ThreadLocal,Object> ,注意這邊的Key變成了ThreadLocal物件本身, 因此每個ThreadLocalMap都有可能會有以不同的ThreadLocal相對應的值.
    其實這種方式更直覺,每個Thread會有一個空間放一些客製的變數,而且好處是,當Thread掛掉之後,這個Map也會跟著Thread被GC掉.

3. ThreadLocal的API
    protected T initialValue() 
給繼承者使用, 預設回傳null, 當呼叫get()拿到null時會呼叫initialValue()將值擺進去.

    其他直覺的使用如下
     +get() : T 
     +set(T) : void     
     +remove(T) : void 

4. 使用ThreadLocal的時機
    我查了一下網路,有人說當你對一個bean/resource使用synchronized的時候,常常是寫法不易而且效能不彰(因為Thread都在排隊等放飯).因此ThreadLocal可以拿來取代synchronized
    這種說法是部分正確的. 其道理在於如果你今天只有一個飯鍋, 放飯的時間一定會拉很長,如果使用ThreadLocal, 當你需要吃的時候我直接給你一碗飯,這時候就不需要排隊了.
   
    ThreadLocal的觀念就是個人造業個人擔,不管你要對你的飯做什麼都不會影響到別人
    但是synchronized內的邏輯,因為是大家共用一個飯鍋,當輪到你盛飯的時候,如果你在飯鍋裡面加了滷肉,整鍋飯就會變成魯肉飯了.
    因此ThreadLocal可以取代synchronized的時機只有在於沒有人會對飯動手腳的時候才適用.
       
    可以把它當作requestScope的延伸
    這個就不需要太多解釋了,因為跟request在同一個Thread裡面 

如果大家有什麼寫錯的地方也請不吝指教喔~