对象分配也有乐观和悲观
最近做公司的网游项目，使用JAVA开发，网络通讯这块使用的则是mina框架。说实话，到现在也只是知道怎么用，内部实现还没仔细研究过。跟成熟的框架比起来，感觉自己之前在.NET上写的Socket在结构化程度上稍差了点，作为一名C# er，便有了模仿其API完善.NET类库的想法。这其中涉及很多技术细节，如线程同步、异步通讯、TCP协议解析、对象池使用及管理等。今天要讲的主题便是这个对象池了。
之所以要用到对象池，是因为在一个典型的TCP/IP应用中，在服务器运行期间，会有无数次收到消息，格式化成指定对象（这里暂时叫Packet吧），并且服务器处理后组织特定的Packet返回给客户端。这样如果每次都用new操作来创建Packet对象的话，加上对象的GC处理回收时间，会对性能产生一定影响。如果服务器压力不大的话，确实可以不用对象池，这样可以保持代码的简洁。不过我的看法是，即使暂时你的服务器压力瓶颈不在这，我们也可以先在底层提供这样的功能，作为技术积累，搞程序还是有点适当的前瞻意识比较好。
对象池，最简单的功能当然就是实现对象复用，避免反复创建及销毁对象。查阅了一些文章，个人总结主要的区别集中在管理策略及管理途径上。策略这东西，可以很简单，可以很复杂，因情况而异。比如.NET中的线程池中关于线程的管理策略，可细分为繁忙时的创建策略及空闲时的销毁。我们的目标是实现一个尽量通用的对象池，因此，用到的管理策略应该是尽量的简单。
再说说管理途径，一般有两种方式：
1、通过封装对象并附加一些池管理需要参数，如是否空闲，最后一次使用时间等，可以称之为ObjectWrapper；
2、通过让对象实现特定接口来实现复用，如实现IDisposable接口或自己另外定义接口。
以上两种方法各有利弊，第一种可以额外附加不同种类的参数，达到辅助管理的目的，第二种可能功能稍微单一，但是贵在简洁，这里我选的是后者，并让池化对象实现一个IPoolable接口，同时定义对象池对象接口IObjectPool，代码如下
{
/// <summary>
/// 将对象释放回对象池，务必确保事件等关联资源先清除
/// </summary>
void Free();
/// <summary>
/// 管理自身的对象池的引用
/// </summary>
IObjectPool<IPoolable> Pool { get; set; }
}
public interface IObjectPool<T> where T : IPoolable
{
/// <summary>
/// 获取空闲对象
/// </summary>
T GetFreeObject();
/// <summary>
/// 释放对象回对象池
/// </summary>
void ReleaseObject(T item);
}
Free方法要求池化对象的实现者将自身返回给对象池的空闲列表，这样做的好处在于对象的使用者可以不用关注对象池的细节。
对象的管理这一问题，确实伤了不少脑筋。使用动态管理，我认为太过复杂，如果这么做，至少要做到可销毁对象的定义，怎么样才算可销毁，是对象空闲了还是一定时间没用了，还是当前数量超出了某个值等。上层应用使用不同对象的情况各有差异，如果简单的用一个标准定死，很难通用。
另一种比较常见的方式，我称之为“乐观获取”，这种做法在无可用对象，并且对象总数达到数量上限时，会假定所有对象的使用者会及时的返回对象，此时请求者选择Sleep或者WaitOne等方式等待。我认为这是种雪上加霜的解决办法，当所有可用对象已经被使用，并且达到了数量上限，这时候认为系达到对象使用的卖方市场，即供不应求。即使有限的对象被返回，也不能满足更多的需求，最坏的情况是一些请求者一直等待。
基于此，我选择了“悲观获取”的方式，这种做法在请求对象时，保证返回一个正确对象，虽然这有可能造成系统中对象总数暂时超
出了数量限制，至少可以保证不会因为没可用对象而使上层逻辑受阻。而当系统压力减轻时，可通过控制返回对象的逻辑来销毁多余的对象。
对象池代码如下：
代码
/// 无需等待的对象池
/// </summary>
class UnWaitObjectPool<T> : IObjectPool<T> where T : IPoolable, new()
{
private int _minObjCount;
private int _maxObjCount;
private object _mutex;
private Queue<T> _freeQueue;//空闲队列
private UnWaitObjectPool(int min, int max)
{
if (min > max || min < 0 || max < 0)
{
throw new ArgumentException("illegal args.");
}
this._minObjCount = min;
this._maxObjCount = max;
this._mutex = new object();
this._freeQueue = new Queue<T>();
for (int i = 0; i < min; i++)
{
this._freeQueue.Enqueue(new T());
}
}
/// <summary>
/// 有空闲对象则直接取出，如果没有，直接创建，这里无视数量上限
/// </summary>
/// <returns></returns>
public T GetFreeObject()
{
if (this._freeQueue.Count > 0)
{
lock (this._mutex)
{
if (this._freeQueue.Count > 0)
{
return this._freeQueue.Dequeue();
}
}
}
return new T();
}
/// <summary>
/// 返回对象，每次调用后如果空闲对象超出限制，则销毁
/// </summary>
/// <param name="item"></param>
public void ReleaseObject(T item)
{
lock (this._mutex)
{
this._freeQueue.Enqueue(item);
}
this.TryTrimToMax();
}
private void TryTrimToMax()
{
while (this._freeQueue.Count > this._maxObjCount)
{
this._freeQueue.Dequeue();
}
}
}
是不是简单很多？这里少了不必要的WaitOne等线程同步操作，以及复杂的管理策略。通俗的说，这里也许跟传统概念的对象池不太一样，因为没有严格控制对象的创建，因此算是一种折中的方案，当对象需求紧张时，对象池与普通new方法一起发挥作用，两种机制同时服务于上层应用。而当系统压力一般时，对象池独自承担对象的维护。
这里只给出部分代码，忽略了单例的部分，对象池对象本身是单例的！但是我们的目的是作为简单或者默认的对象池，前文提到的Packet只是一种应用场景，既然设计成泛型，肯定是希望尽量的通用，因此如果有遗漏的地方没想到，欢迎大家批评及拍砖。
参考文章：
Java对象池技术的原理及其实现http://www.cnblogs.com/aurawing/articles/1887029.html
使用.net技术创建一个小型对象池http://www.cnblogs.com/chegan/archive/2004/03/04/2129.html
SocketAsyncEventArgs对象池示例http://msdn.microsoft.com/en-us/library/bb551675.aspx
数组缓存池示例http://msdn.microsoft.com/en-us/library/bb517542.aspx
