關鍵： 爲何HashMap 一個容器對象仍是處於WeakHashMapjava
1. 以弱鍵 實現的基於哈希表的 Map。在 WeakHashMap 中，當某個鍵再也不正常使用時，將自動移除其條目。更精確地說，對於一個給定的鍵，其映射的存在並不阻止垃圾回收器對該鍵的丟棄，這就使該鍵成爲可終止的，被終止，而後被回收。丟棄某個鍵時，其條目從映射中有效地移除編程
2. WeakHashMap 類的行爲部分取決於垃圾回收器的動做。由於垃圾回收器在任什麼時候候均可能丟棄鍵，WeakHashMap 就像是一個被悄悄移除條目的未知線程。特別地，即便對 WeakHashMap 實例進行同步，而且沒有調用任何賦值方法，在一段時間後 size 方法也可能返回較小的值，對於 isEmpty 方法，返回 false，而後返回true，對於給定的鍵，containsKey 方法返回 true 而後返回 false，對於給定的鍵，get 方法返回一個值，但接着返回 null，對於之前出如今映射中的鍵，put 方法返回 null，而 remove 方法返回 false，對於鍵 set、值 collection 和條目 set 進行的檢查，生成的元素數量愈來愈少。緩存
3. WeakHashMap 中的每一個鍵對象間接地存儲爲一個弱引用的指示對象。所以，無論是在映射內仍是在映射以外，只有在垃圾回收器清除某個鍵的弱引用以後，該鍵纔會自動移除。安全
引用類型的分類：編程語言
1 強引用 - Strong Referenceui
2 弱引用 - Weak Referencespa
3軟引用 - Soft Reference線程
4 幻想引用 - Phantom Referencecode
到目前爲止：你對於WeakHashMap有了一個基本的概念，可是仍是比較模糊，接下來，咱們對於orm
java 引用的內容進行一個詳盡頭解析
1 ：強引用
Stringbuffer sb = new StringBuffer();
Person p = new Person();
Stringbuilder sb = new StrignBuilder();
這句代碼建立了一個StringBuffer對象，在變量buffer中存儲了這個對象的一個強引用。強引用之因此稱之爲「強」（Strong），是由於他們與垃圾回收器（garbage collector）交互的方式。特別是（specifically），若是一個對象經過強引用鏈接（strongly reachable-強引用可到達），那麼它就不在垃圾回收期處理之列。當你正在使用某個對象而不但願垃圾回收期銷燬這個對象時，強引用一般正好能知足你所要的。
2. 當強引用太強的時候
假定你要使用一個final類Widget，可是基於某種緣由，你不能繼承（extend）這個類或者經過其餘方法爲這個類增長一些新的功能。若是你須要跟蹤（track）這個類的不一樣對象的序列號。那麼能夠將這些對象放入HashMap中，得到不一樣的value值，這樣就能夠作到經過不一樣的value值跟蹤這些對象了。代碼：
serialNumberMap.put(widget, widgetSerialNumber);
可是widget的強引用會產生一些問題。在咱們不須要一個Widget的序列號時，咱們須要將這個Widget對應的Entry從HashMap中移除。不然咱們可能面臨內存泄露（memory leak）的問題（若是咱們沒有在應當移除Widgt的時候移除它），或者咱們將莫名其妙的丟失序列號（若是咱們正在使用Widget時卻移除了它）。若是這些問題相似，那麼這些問題是無垃圾回收機制（non-garbage-collected language）的編程語言的開發者所面臨的問題。Java的開發者不須要擔憂這種問題。
W：若是一個對象具備強引用，那就相似於必不可少的生活用品，垃圾回收器毫不會回收它。當內存空 間不足，Java虛擬機寧願拋出OutOfMemoryError錯誤，使程序異常終止，也不會靠隨意回收具備強引用的對象來解決內存不足問題。
強引用的另一個常見問題就是圖片緩存（cache）。普通的強引用將使得Image繼續保存在內存中。在一些狀況下，咱們不須要有些Image繼續留在內存中，咱們須要將這些圖片從內存中移出，這時，咱們將扮演垃圾回收期的角色來決定哪些照片被移除。使這些被移出的圖片被垃圾回收器銷燬。下一次，你被迫再次扮演垃圾回收期的角色，手動決定哪些Image被回收。
Note：我以爲也能夠用對象的hashCode來跟蹤對象。做者在此所舉的例子，只在說明Strong Reference。
3. 弱引用
簡單說，就是弱引用不足以將其鏈接的對象強制保存在內存中。弱引用可以影響（leverage）垃圾回收器的某個對象的可到達級別。代碼：
WeakReference<Widget> weakWidget = new WeakReference<Widget>(widget);
你可使用weakWidget.get()方法老獲取實際的強引用對象。可是在以後，有可能忽然返回null值（若是沒有其餘的強引用在Widget之上），由於這個弱引用被回收。其中包裝的Widget也被回收。
解決Widget序列號的問題，最簡單的方法就是使用WeakHashmap。其key值爲弱引用。若是一個WeakHashmap的key變成垃圾，那麼它對應用的value也自動的被移除。
W：垃圾回收期並不會總在第一次就找到弱引用，而是會找幾回才能找到。
4. 引用隊列（Reference Quene）
一旦弱引用返回null值，那麼其指向的對象（即Widget）就變成了垃圾，這個弱引用對象(即weakWidget)也就沒有用了。這一般意味着要進行必定方式的清理（cleanup）。例如，WeakHashmap將會移除一些死的（dread）的entry，避免持有過多死的弱引用。
ReferenceQuene可以輕易的追蹤這些死掉的弱引用。能夠講ReferenceQuene傳入WeakHashmap的構造方法（constructor）中，這樣，一旦這個弱引用指向的對象成爲垃圾，這個弱引用將加入ReferenceQuene中。
以下圖所示：
5. 軟引用
除了在拋出本身所指向的對象的迫切程度方面不同以外，軟引用和弱引用基本同樣。一個對象爲弱可到達（或者指向這個對象的強引用是一個弱引用對象-即強引用的弱引用封裝），這個對象將在一個垃圾回收循環內被丟棄。可是，弱引用對象會保留一段時間以後纔會被丟棄。
軟引用的執行和弱引用並無任何不一樣。可是，在供應充足（in plentiful supply）的狀況下，軟可到達對象將在內存中保存儘量長的時間。這使得他們在內存中有絕佳的存在基礎（即有儘量長存在的基礎）。由於你讓垃圾回收器去擔憂兩件事情，一件是這個對象的可到達性，一件是垃圾回收期多麼想要這些對象正在消耗的內存。
6. 幻象引用（phantom reference）
幻象引用於弱引用和軟引用均不一樣。它控制其指向的對象很是弱（tenuous），以致於它不能得到這個對象。get()方法一般狀況下返回的是null值。它惟一的做用就是跟蹤列隊在ReferenceQuene中的已經死去的對象。
幻象引用和弱引用的不一樣在於其入隊（enquene）進入ReferenceQuene的方式。當弱引用的對象成爲若可到達時，弱引用即列隊進入ReferenceQuene。這個入隊發生在終結（finialize）和垃圾回收實際發生以前。理論上，經過不正規（unorthodox）的finilize（）方法，成爲垃圾的對象能從新復活（resurrected），可是弱引用仍然是死的。幻象引用只有當對象在物理上從內存中移出時，纔會入隊。這就阻止咱們從新恢復將死的對象。
W：終結(Finalization)指比拉圾回收更通常的概念,能夠回收對象所佔有的任意資源,好比文件描述符和圖形上下文等。
幻象引用由兩個好處：
A:它能肯定某一個對象從內存中移除的時間，這也是惟一的方式。一般狀況下，這不是很是有用。可是早晚（come in handy）會用到手動處理大圖片的狀況：若是你肯定一張圖片須要被垃圾回收，那麼在你嘗試加載下一張照片前，你應該等待這張照片被回收完成。這樣就使得使人恐懼的（dreaded）內存溢出不太可能發生。
B:虛幻引用可以避終結（finilize）的基本問題。finilize（）方法可以經過給一個垃圾對象關聯一個強引用使之復活。問題是覆寫了finilize()方法的對象在成爲垃圾以前，爲了回收，垃圾回收期須要執行兩次單獨的循環。第一輪循環肯定某個對象是垃圾，那麼它就符合終結finilize的條件。在finilize的過程當中，這個對象可能被「復活」。在這個對象被實際移除以前，垃圾回收期不得不從新運行一遍。由於finilization並非實時調用的，因此在終止進行的過程當中，可能發生了gc的屢次循環。在實際清理垃圾對象時，這致使了一些延時滯後。這將致使Heap中有大量的垃圾致使內存溢出。
幻象引用不可能發生以上的狀況，當幻象引用入隊時，它實際上已經被移除了內存。幻象內存沒法「復活」對象。這發現這個對象時虛幻可到達時，在第一輪循環中，它就被回收。
能夠證實，finilize()方法從不在第一種狀況下使用，可是虛幻引用提供了一種更安全和有效的使用和被排除掉的finilize方法的機制，使得垃圾回收更加簡單。可是由於有太多的東西須要實現，我一般不適用finilize。
W:Object類中相關內容以下：
文檔中相關內容以下：
