在Android的android.os.Message類的文檔中有這麼一句話：
While the constructor of Message is public, the best way to get one of these is to call Message.obtain() or one of the Handler.obtainMessage() methods, which will pull them from a pool of recycled objects.
大意是說，雖然Message類的構造方法是public的，你可以直接通過new來創建一個新的對象，但是最好還是通過Message.obtain()或者Handler.obtainMessage()來創建一個新的Message對象，因爲這兩個方法會重用之前創建的但是已經不再使用了的對象實例。
這句話不禁引起了我的興趣，因爲之前我寫過一篇博客《Pool, SimplePool與SynchronizedPool》，在這篇博客裏面仔細分析了Android是如何實現一個對象池的。裏面提到VelocityTracker就是用SynchronizedPool來實現對象重用的，代碼如下：
VelocityTracker tracker = VelocityTracker.obtain(); tracker.recycle();
Message類看起來也略有相似，不過經過閱讀Message類的源代碼，發現我錯了，Message類使用了另一種巧妙的方法來實現對象重用。
好了，不賣關子了，Message類使用了一個鏈表來實現對象池，而且是一個前端鏈表，即在前端插入和刪除的鏈表，避免了插入和刪除的時候遍歷整個鏈表。是不是有點出人意料？
首先看一下這段代碼，去除了Message中其他的攜帶消息信息的字段。已經很明顯可以看出來是一個鏈表了吧。
public final class Message implements Parcelable {
// 省略其他代碼
Message next; // (1)
private static final Object sPoolSync = new Object(); // (2)
private static Message sPool; // (3)
private static int sPoolSize = 0; // (4)
private static final int MAX_POOL_SIZE = 50;
// 省略其他代碼
}(1) 聲明瞭next指針
(2) 對象鎖，Message對象池是線程安全的，這樣就需要在向對象池申請和歸還對象時使用鎖
(3) 這裏是關鍵，一個靜態的Message對象，這就是這個鏈表的頭指針了，因爲是類變量，因此，整個JVM中只有一個
(4) 當前對象池的大小，後面還限制了這個Message對象池中的對象個數最大爲50
用圖形表示如下：
public static Message obtain() {
synchronized (sPoolSync) { // (1)
if (sPool != null) {
Message m = sPool; // (2)
sPool = m.next; // (3)
m.next = null; // (4)
sPoolSize--; // (5)
return m;
}
}
return new Message();
}這也很容易理解：
(1) 獲取鎖，這裏毫無疑義
(2) 當頭指針指向的對象不爲null時，將這個對象賦值給m
(3) 將頭指針指向m的next指針
(4) 將m的next指向null，到這裏位置，我們從以sPool爲頭指針的鏈表中取出了第一個元素
(5) 將鏈表size減1
看起來沒錯，疑問是，當第一次獲取對象的時候sPool肯定爲null，那麼這個if語句肯定不會執行，會直接執行最後一句return new Message()，直接創建一個對象？這樣不是毫無意義了麼？
看到這裏，似乎感覺發現了一個Android的bug，會有這麼明顯的bug麼？當然不會，靜下心來繼續讀代碼，讀到這裏的時候豁然開朗了：
public void recycle() {
clearForRecycle(); // (1)
synchronized (sPoolSync) {
if (sPoolSize < MAX_POOL_SIZE) { // (2)
next = sPool; // (3)
sPool = this; // (4)
sPoolSize++;
}
}
}(1) 重置Message中攜帶的消息
(2) 檢查當前對象池的大小是不是已經超過了最大值，如果當前隊列已經滿了，就不管這個對象了，讓JVM的GC回收好了，這裏保證了性能的同時兼顧了內存消耗
(3) 將當前對象next指針指向頭指針sPool指向的對象
(4) 將頭指針sPool指向當前對象，然後將對象池大小加1
到這裏就明白了：這篇博客開頭的那句話其實背後還有一些潛臺詞，那就是你必須顯式的調用一下recycle()將當前的Message對象歸還到對象池，這個對象池才能發揮其效果，不調用recycle()方法，對象不會歸還，會被JVM GC回收。
也就是說下面兩句話必須是成對出現的，不用obtain()而調用recycle()會導致不停的創建Message對象直到超過MAX_POOL_SIZE的限制而被對象池扔掉；通過obtain()申請對象而不用recycle()歸還會導致對象池被消耗乾淨而不停申請新對象。
Message msg = Message.obtain(); msg.recycle();
所以文檔再完整還是不如看代碼。
對於通過SynchronizedPool來實現對象池和這種通過鏈表來實現對象池兩種方法，我看不出來各自有何優缺點，這兩種方法很相似，實現的功能也相似，唯一的不同在於，前者似乎更容易擴展。也許你自己在其他項目中需要對象池的時候，可以借鑑一下這兩種方法。