這個問題肯定要分為JVM物件回收和Spring物件管理來說的！如果看完還不會，你儘管來抽我。。

一，JVM物件回收:

就是對沒有引用存在的物件進行回收，最原始的做法是加一個物件引用計數器，比如A被B引用了，則A物件的引用計數器為1，只要B沒被回收，A的引用計數大於0，A就不會被回收！

但是這樣做是有隱患的，如果A引用B，B引用A，然後沒有任何其他物件引用A，B的時候，理論上AB都應該被回收了，但是AB引用計數器上面的計數都為1，不能回收，這樣兩個永遠不會使用但也無法回收的物件佔據著記憶體，直到記憶體溢位！

JVM是怎麼解決這一現象的呢？引入一個GCRoots(引用鏈)的東西，把靜態物件引用，常量引用等作為根節點，其餘所有的引用都掛在這棵引用樹上，上面說到的AB，如果從根節點上遍歷的時候沒有找到AB的引用(不可達根節點)，就說明AB已經脫離了引用鏈，就算引用計數器還為1，也將被回收！

二，spring管理物件:

如下圖，就是建立物件的父介面:

先看SimpleJndiBeanFactory類:

在SimpleJndiBeanFactory類中，先new了一個名叫singletonObjects的final修飾的hashmap變數，在容器啟動的時候，透過doGetSingleton方法把jndi反射得到的例項化物件放入此hashMap中，作為new出來的強引用，沒有進行釋放就會一直掛在引用鏈上，不會進行釋放！

再看看ApplicationContext下面的StaticListableBeanFactory類，使用new出來的名為beans的LinkedHashMap進行管理，同時使用addBean方法加入物件到map中，方便及時呼叫！

綜上，spring管理的物件，都透過map等形式載入，掛在了引用鏈上，所以並不會一不使用就被回收了！

順便說下，spring這種"家喻戶曉"的框架，其實底層也就是JAVA基本的資料結構組成的，所以JAVA程式設計師人人都可以編一個spring框架出來！更多的技術分享，敬請關注。。。

一、物件會不會回收跟該物件的生命週期有很大關係:

singletonObjects從屬於ApplicationContext，只要ApplicationContext不被回收，singletonObjects就不會被回收。 而ApplicationContext，就有多種情況了

① 你手動建立，例如在main方法中，那麼生存週期根據你的程式碼而定。

② 整合到Servlet中，那麼應用伺服器持有ApplicationContext引用，伺服器不關閉則引用不失效。

二、JVM虛擬機器的垃圾收集演算法使用根搜尋演算法

這個演算法的基本思路是：對任何“活”的物件，一定能最終追溯到其存活在堆疊或靜態儲存區之中的引用。透過一系列名為根（GC Roots）的引用作為起點，從這些根開始搜尋，經過一系列的路徑，如果可以到達java堆中的物件，那麼這個物件就是“活”的，是不可回收的。可以作為根的物件有：

虛擬機器棧（棧楨中的本地變量表）中的引用的物件。 方法區中的類靜態屬性引用的物件。 方法區中的常量引用的物件。 本地方法棧中JNI的引用的物件。 方法區是jvm的一塊記憶體區域，用來存放類相關的資訊。很明顯，java中單例模式建立的物件被自己類中的靜態屬性所引用，符合第二條，因此，單例物件不會被jvm垃圾收集。

雖然jvm堆中的單例物件不會被垃圾收集，但是單例類本身如果長時間不用會不會被收集呢？因為jvm對方法區也是有垃圾收集機制的。如果單例類被收集，那麼堆中的物件就會失去到根的路徑，必然會被垃圾收集掉。對此，筆者查閱了hotspot虛擬機器對方法區的垃圾收集方法，jvm解除安裝類的判定條件如下：

該類所有的例項都已經被回收，也就是java堆中不存在該類的任何例項。 載入該類的ClassLoader已經被回收。 該類對應的java.lang.Class物件沒有任何地方被引用，無法在任何地方透過反射訪問該類的方法。

只有三個條件都滿足，jvm才會在垃圾收集的時候解除安裝類。顯然，單例的類不滿足條件一，因此單例類也不會被解除安裝。也就是說，只要單例類中的靜態引用指向jvm堆中的單例物件，那麼單例類和單例物件都不會被垃圾收集，依據根搜尋演算法，物件是否會被垃圾收集與未被使用時間長短無關，僅僅在於這個物件是不是“活”的。