在Android的android.os.Message类的文档中有这么一句话：
10年积累的成都网站建设、成都做网站经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站设计后付款的网站建设流程，更有桃城免费网站建设让你可以放心的选择与我们合作。
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来实现对象池和这种通过链表来实现对象池两种方法，我看不出来各自有何优缺点，这两种方法很相似，实现的功能也相似，唯一的不同在于，前者似乎更容易扩展。也许你自己在其他项目中需要对象池的时候，可以借鉴一下这两种方法。