多线程与对象回收

主线程是具有非常复杂逻辑的，在用户量大的时候这个线程既要处理消息，又要执行自身的逻辑循环，瓶颈并不是机器不够快，而是顺序做太多的事，速度再快，执行完也要花费较多时间，而且这个时间和用户量是指数关系的。由于复杂的逻辑，导致对象之间的引用很多，很多功能难以单独放到单独的线程去做，如果做的话会线程间的同步本身就有很大的代价，恐怕会得不偿失。另外，多线程编程带来的还有编程的复杂性，一不小心就会制造出诡异的难以追踪的错误，带来不少麻烦。现在只好尝试把容易分离而且和其他部分联系不紧密的部分放到单独的线程去做，这样并不能缩短执行时间，但可以减少主线程的工作量。
java有gc来做内存回收。我也写了一个线程做类似工作，但不是回收内存，而是负责对象的析够，主线程中的确定不会再有引用的需要删除对象都放到单独的回收线程中执行析够。这个对于对象有特殊的要求，那就是对象的析够函数不会和主线程有关系，只是执行自身的清除，否则又要牵涉和主线程的同步问题了。为了避免麻烦，在主线程中删除该对象和外部的一切关系之后，才把它放心交给回收线程。
两个线程肯定需要使用同一个数据结构来存储需要删除的对象。为了避免回收线程加锁的时间太长，长时间占用这个线程，使用了两个list，在它们之间做切换，回收线程占用list1做回收时，主线程就使用list2来做为存储的列表。回收线程清掉list1上的对象之后再切换到list2上。这样两个线程竞争的部分就只有切换这段代码，而这段代码执行是很快的。避免了只使用一个list,在回收线程便利list1时，主线程就不能写入的情况.
由于原有代码没有考虑多线程，顺序并不关键，但多线程就需要注意顺序问题。另外没有成熟流程的逻辑改起来更是四处下手，到处都有需要改的代码。
以下是伪代码

struct RecycleList
{
RecycleList()
{
 list_del = &list_Fir;
seq = 0;
}
List *list_del;
byte seq;
List list_Fir;
list list_Sec;
Lock lock;

void addEntry(Entry *entry);
void loop();
}

RecycleList::addEntry(Entry *entry)
{
lock.lock();
list_del->push_back(entry);
lock.unlock();
}
RecycleList::loop()
{
List *list_tmp;
lock.lock();
if(seq == 0)
{
list_tmp = list_del;
list_del = &list_Sec;
}
else
{
list_tmp = list_del;
list_del = &list_Fir;
}
lock.unlock();

for(List::iterator iter=list_tmp->begin(); iter !=list_tmp->end(); iter ++ )
{
delete(*iter);
}
list_tmp->clear();
}