C++博客-feixuwu-随笔分类-游戏开发

项目开发中的一些思考

feixuwu — Thu, 16 Feb 2012 13:00:00 GMT

2011已经谢幕了，现在都流行总结，要是让我总结2011，可以用2个词来概括，辛苦、刺激。
辛苦是因为2011基本上是加了一年班，从过完年开始，到2012年过年前最后一周，这一年来，是我感觉最辛苦的一年，好在最终
项目算是打了个翻身仗，心里总算有了些慰藉。

2011年游戏经历从技术封测、内测、公测到整改、重新内测公测，一路走来，遇到无数稀奇古怪的Bug，
有时候压力大的时候，晚上都睡不着，脑子里回想着现场的一丝丝蛛丝马迹，希望能找到bug的原因，经历过无数次绝望到重生的喜悦，也有被猜忌不信任的痛苦，活脱脱就是一部部侦探剧情。
没有从事过游戏开发或者游戏没上线的同学很难理解:bug有这么难找吗？的确，如果是简单的空指针宕机，当然是好找的，用我们的话，这类问题是个傻子都能解决(其实不然，很多时候直接原因是空指针，
真正的原因隐藏很深)，但是更多的是隐藏很深的问题，需要反复的分析现场，假设剧情才能得到灵感，然后推演，才可能得到结果，当然，这个和游戏逻辑的复杂度是分不开的。
具体的bug细节不便在此分析，但是大部分的问题，其实都是因为不正常的设计引起的，所以其实我一直在思考，在软件开发领域，其实也存在着"道",说通俗点叫客观规律，不按照道行事，迟早是要受到惩罚的。
但是在游戏后台开发中，很多时候存在不同技术方案的矛盾，难以让人取舍，这些矛盾都是真实在很多项目存在的。

动态内存还是静态内存

很多开发者由于担心内存泄露，在项目中禁止使用动态内存(当然这实际上几乎是做不到的)，使用对象池来避免动态内存，就是预先创建预计最大数量的对象，后续申请和归还的时候，都是操作对象池，
避免动态new和delete。这样的项目还不少，我见过的就好几个。对象池的好处是显而易见的，基本上可以避免内存泄露。但是实际上，这种方式是把双刃剑，个人觉得在游戏项目中，这种方式弊大于利。
主要弊端有下面几点：
1、开发不方便，导致需要添加很多的对象池管理类，即使有模板帮忙，也是非常繁琐的。实际开发中，几乎不可能对这些小对象类都搞一个对象池管理类。

2、由于采用预先生成对象，一般会预估一个对象可能存在的最大数量，然后按照最大数量来创建，浪费内存。
的确，你没有内存泄露，但是你启动的时候就需要好几个G的内存，这个是内存浪费，好在现在server开发基本都是64位，没有地址空间的困扰了，但是，在大部分情况下浪费好几个G的内存，
光想想都有点心疼。

3、引入了新的风险，由于采用对象池，申请新对象的时候，只是简单的pop一个空闲对象就可以了，很容易漏掉对象初始化的工作，在回收对象的时候，大部分开发者也很容易漏掉清理工作，或者初始化和
清理工作过于简单，这样容易导致新对象被历史操作影响。曾经遇到过一个新FB所有传送点都打不开的问题，就是因为历史对象回收时数据没清理导致的。

回头来看对象池的优点，很多开发者坚持是为了解决内存碎片和内存泄露。先说内存碎片，暂且不说内存碎片真的是否有这么严重，退一步，其实内存碎片已经有很多的成熟解决方案了，自己重载smallObject还是
采用标准的tcmalloc解决，都是非常轻松的。至于内存泄露，个人觉得这个问题其实是很好查的，也是c++程序员的基本要求。

分模块针对接口编程还是一锅粥

这个问题单独提出来，几乎所有人都会说，当然是分模块针对接口开发了。和天下所有的事情一样，知易行难。由于游戏逻辑项目影响的地方非常多，比如死亡的时候，既需要判断死亡掉落，又需要处理任务状态，
如果在战场和竞技场中，还要判断基数和得分等等，这就导致很多开发者不假思索的把所有的东西都揉在一起，你中有我，我中有你，我改你的代码你改我的。
一个最简单的例子，我在项目中开发掉落功能，当把物品添加到玩家背包后，发现客户端没有更新背包，一查，居然还需要掉落的开发者自己构造数据包同步客户端，其实作为其他模块，根本不关心背包数据同步的细节。
这个其实在现实生活中很常见，我委托背包模块添加一个物品，具体的细节是被由被委托人来负责的。将过多的细节交给其他模块处理，会导致复杂度增加，容易出现问题，对其他人来说，也是一个精力浪费，如果是一个复杂
模块，你会发现需要了解太多的细节，修改太多自己不熟悉的代码，进而导致风险。还有一种观点，认为一锅粥的开发方式有助于了解游戏的各个业务模块，对这种观点，我是不以为然的，每天陷入到繁琐的细节，真的对熟悉业务有好处吗？或许闲下来玩玩游戏更有帮助，而且，这么乱的代码，看起来也是非常累的。分模块开发，具体的办法，游戏编程精粹5上有篇文章写得很好，这里不扩展了。

真的需要禁用STL吗

不止一次在和其他项目交流的资料里看到对方很威严的宣称在项目里禁止使用STL。说实话，我还真没觉得STL有什么不好。见过太多这类项目自己重复实现一个个蹩脚的排序算法、容器等等。
大部分人一般都会根据经验选择使用自己熟悉的技术，这个无可厚非，但是像这样明着禁止使用STL，真不知道如何能理直气壮。其实大部分不用STL的理由，基本上都是不熟悉，完全没有足够的理由禁止使用。

游戏开发无技术含量？

曾经多次听到行业内的兄弟有此感慨，确实，游戏逻辑复杂度非常高，架构上大部分都是类似的。但是这并不说明游戏后台开发复杂度不高，如何将游戏开发逻辑复杂剥离开来，做到稳定高效开发，其实还是有很多
东西可以探讨的，看看那些项目，大部分都是一锅粥，需要什么功能就蛮干，加上去，这样确实毫无技术含量，都是蛮干。所以，一件事情是否有技术含量，不光是看事情本身，还要看怎么干，蛮干和苦干，那是最没有技术
含量的方式了，程序员还是要有强烈的“偷懒”意识。

feixuwu 2012-02-16 21:00 发表评论

linux下PageHeap

feixuwu — Sat, 14 May 2011 13:16:00 GMT

问题

最近游戏开始技术封测了，不过刚刚上线3个小时，Server就挂了，挂在框架代码里，一个不可能挂的地方。
从CallStack看，是在获取数据时发送请求包的时候挂的，由于框架部分是其他部门的同事开发的，所以查问题的时候就拉上他们了，
大家折腾了2天，没有实质性的进展，服务器还是基本上每3个小时宕机一次。由于上层逻辑大部分都在我那，所以压力比较大，宕机的直接原因是hashtable的一个桶的指针异常，
这个hashtable是框架代码的一个内部成员，按道理我们是无从破坏的，只有可能是多线程环境下迭代器损坏导致的。
但是框架代码在这个地方确实无懈可击，所以真正的原因应该还是上层代码破坏了堆内存，很可能是一个memcpy越界导致的。这毕竟是个猜想，如何找到证据呢，这是个问题。
把所有代码里的memcpy浏览了一遍，没有发现明显问题。

猜测

一般游戏中比较容易出现但是不好查的问题很多时候都是脚本（lua）导致的，我们的脚本部分是一个同事几年前写的，在几个产品中都使用过，按道理没这么脆弱，不过老大还是和最初开发这个模块的部门沟通了下，
还真发现问题了，赶紧拿了新的版本更新上去。经过一天的观察，服务器没有宕机了，OK，问题碰巧解决了,背了这么久的黑锅，终于放下来了。

PageHeap

   假如没有碰巧解决了这个问题，正常的思路该如何解决这个问题呢，这个时候我怀念windows了，在windows下有PageHeap来解决这类写越界的问题。基本思路就是每次分配内存的时候，都将内存的结尾放在页的边缘，紧接着这块内存分配一块不能写的内存，这样，一旦写越界，就会写异常，导致宕机。linux下没有现成的工具，但是linux提供了mmap功能，我们可以自己实现这样一个功能，当然，这一切都不用自己动手了，tcmalloc已经包含了
这个功能了，不过在文档里基本没有介绍，我也是在阅读tcmalloc代码时看到的，这个功能默认是关闭的，打开这个开关需要改写代码：

这个代码在debugallocation.cc里：

DEFINE_bool(malloc_page_fence,
            EnvToBool("TCMALLOC_PAGE_FENCE", false),
            "Enables putting of memory allocations at page boundaries "
            "with a guard page following the allocation (to catch buffer "
            "overruns right when they happen).");
把false改成true就可以了。
想要在项目里加入PageHeap功能，只需要链接的时候加上 -ltcmalloc_debug即可。把它加入项目中，试着运行下，直接挂了，
仔细一看，原来是项目中很多成员变量没有初始化导致的，tcmalloc_debug会自动将new 和malloc出来的内存初始化为指定值，这样，一旦变量没有初始化，很容易就暴露了。
修改完这个问题后，编译，再运行，还是挂，这个是mprotect的时候挂的，错误是内存不够，这怎么可能呢，其实是达到了资源限制了。
echo 128000 > /proc/sys/vm/max_map_count
把map数量限制加大,再运行，OK了！

但是游戏Server启动后，发现一个问题，CPU长期处于100%，导致登陆一个玩家都很困难，gdb中断后，info thread，发现大部分的操作都在mmap和mprotect,最开始
怀疑我的linux版本有问题，导致这2个AP慢，写了测试程序试了下，发现其实API不慢，估计是频繁调用导致的。
所以得换种思路优化下才可以，其实大部分情况下，我们free的时候，无需将页面munmap掉，可以先cache进来，下次分配的时候，如果有，直接拿来用就可以了。
最简单的cache算法就是定义一个void* s_pageCache[50000]数组，页面数相同的内存组成一个链表，挂在一个数组项下，这个很像STL的小内存处理，我们可以将mmap出来的内存的
前面几个字节(一个指针大小)用于索引下一个freePage。当然这个过程需要加锁，不能用pthread的锁（因为他们会调用malloc等内存分配函数），必须用spinlock，从linux源码里直接抄一个过来即可。
static void*   s_pagePool[MAX_PAGE_ALLOC]={0};

malloc的时候，先从pagePool里面获取:
// 先从pagePool找
void* pFreePage = NULL;
spin_lock(&s_pageHeapLock);
assert(nPageNum < MAX_PAGE_ALLOC);
if(s_pagePool[nPageNum])
{
   pFreePage = s_pagePool[nPageNum];
   void* pNextFreePage = *((void**)pFreePage);
   s_pagePool[nPageNum] = pNextFreePage;
}
spin_unlock(&s_pageHeapLock);

free内存的时候，直接放到pagePoll里:
spin_lock(&s_pageHeapLock);
assert(nPageNum < MAX_PAGE_ALLOC);
void* pNextFree = s_pagePool[nPageNum];
*(void**)pAddress = pNextFree;
s_pagePool[nPageNum] = pAddress;

spin_unlock(&s_pageHeapLock);

编译、运行,OK了，CPU迅速降下来了，空载的时候不到1%,而且也能达到检测写溢出的问题。

feixuwu 2011-05-14 21:16 发表评论

core和CallStack

feixuwu — Sun, 10 Apr 2011 06:47:00 GMT

最近项目开始集中测试了，服务器程序经常crash，由于服务器一般情况下都是关闭了core的，所以好几次都只能通过杂乱的日志来定位问题。
当然，我们可以通过ulimit来打开core开关，不过这可能带来新的问题：我们的服务器程序每个core文件大概有1G多，测试期间如果频繁crash,没有注意及时清理，一不小心就会把磁盘写满，
而且core文件毕竟是和进程程序相关的，有时候找相应版本也是个麻烦事。

能否在程序crash的时候，将callStack以及参数和局部变量都记录到日志里？
这个技术其实在游戏客户端已经用了很多年了，一般游戏客户端crash后，都会弹出一个是否发送错误的选择框，其实就是发送的CallStack的日志和MiniDUmp文件。
要想记录CallStack就必然涉及到Stack的遍历，linux下的Stack遍历使用很简单，简单的backtrace就可以搞定，man backtrace就有现成的例子，
这比windows下复杂的头疼的StackWalk好用的多。

解决了Stack遍历问题后，还剩下一个问题：如何在程序crash的时候得到通知执行我们自己的dump代码？
在Windwos下有SEH异常来实现这个功能，而linux下可以通过使用信号在进程crash的时候执行自己的处理代码。

好了，开始写个简单代码测试下:
首先设置几个主要crash信号的处理函数
signal(SIGSEGV, &DumpHelper::OnCrash);
signal(SIGABRT, &DumpHelper::OnCrash);
signal(SIGFPE, &DumpHelper::OnCrash);

在OnCrash里我们用前面提到的backtrace系列函数，来记录堆栈:
void* szStackFrame[100];
int nFrameCount = backtrace(szStackFrame, 100);
char** strFrameInfo = backtrace_symbols(szStackFrame, nFrameCount);
char szDumpFileName[1024] = {0};
snprintf(szDumpFileName, sizeof(szDumpFileName), "dump_%u.log", (unsigned int)time(NULL) );
FILE* pFile = fopen(szDumpFileName, "wb");
if(!pFile) return;
for(int i = 0; i < nFrameCount; i++)
{
fprintf(pFile, "%s\n", strFrameInfo[i]);
}
fclose(pFile);
free(strFrameInfo);

接着，设置几个嵌套调用的函数：
void fun()
{
//assert(0);
int* p = NULL;
*p =3;
}

void fun1()
{
fun();
}

void fun2()
{
fun1();
}

void fun3()
{
fun2();
}

最后，我们在main函数里执行fun3,注意编译的时候带上-rdynamic 选项。

运行下，果然可以打印基本的堆栈，不过马上，发现了新的问题：这个堆栈信息也太简陋了，只有调用函数的名字，其余的参数、局部变量完全没有，
这个和gdb能看到的callStack差距也太大了。
解决这个问题最简单的办法就是用gdb来打印堆栈,在这里，gdb和其他程序有区别，如果你试图通过 echo "bt"|gdb -p XXX>a.txt来获得堆栈，那将会非常失望，
根本不起作用，google了下，基本没什么解决办法。
不过gdb 可以从文件读入指令，例如 gdb XXXsystem("echo \"bt full|gcore\">testcmd");
  char dbx[160]={0};
    sprintf(dbx, "gdb -p %d ./maingdbdump_%d.log", getpid(), getpid() );
  system(dbx);

测试运行，发现可以打印详细的堆栈，不过，要求机器上有gdb.
上面的命令还dump了一个core文件，不过这个core文件的堆栈信息是错误的，我不知道为什么。。。。

多线程环境下使用上述办法，只能输出一个线程的堆栈，需要先获取线程数目，然后逐个线程打印堆栈。

最后，为了避免影响正常的coredump,要在OnCrash的处理函数里将信号的处理函数设置为默认。
如果我一定要有core呢，setrlimit吧，去掉core限制即可。

feixuwu 2011-04-10 14:47 发表评论

GCC项目编译速度优化

feixuwu — Sat, 19 Mar 2011 08:39:00 GMT

   我们的新项目是在linux平台下运行的，本人是Linux和windows下都开发过，我呆的2个linux后台项目都是所有代码放在一块，编译成一个可
执行文件，基本不考虑编译成动态库，所有代码的头文件依赖也是一团糟，随着项目的增大，编译速度越来越慢，到后来编译一个项目4进程同时编译都需要10来分钟。

其实分析下可以发现，主要的编译速度损耗在头文件上，尤其是模板相关的头文件。VC有一个预编译头文件技术，将常用的公共头文件放在一起，预先编译成pch文件，这样
可以加快编译速度。gcc到底有没有类似技术呢，打开gcc的手册搜索了precompiled，发现还真有相关介绍，使用方法也很简单。

主要是以下步骤：
1、在项目下建立一个 stdafx.h的文件，包含了大部分公共头文件。在每个cpp最开始都#include "stdafx.h"。cpp文件包含了这个预编译头文件后，就可以将原来和
stdafx .h 里头文件重复的内容删除了，尤其是模板相关的头文件，另外，非PCH的头文件里尽量少包含其他头文件。
2、修改makefile文件, 加入OBJ对 gch的依赖,用一个简单的项目做示例，一看就明白

TARGET=TimerTest
PCH=stdafx.h.gch
PCH_H=stdafx.h
OBJ=stdafx.o TimerManager.o TimerTest.o

%.o:%.cpp
    g++ -Wall -c -g $^ -o $@

$(TARGET):$(OBJ)
    g++ -g $^ -o $@

pch.d:stdafx.cpp
    g++ -g -MM stdafx.cpp |sed 's/stdafx.o/stdafx.h.gch/'>$@

-include pch.d

$(OBJ):$(PCH)
$(PCH):
    g++ $(PCH_H)

clean:
    rm -f $(OBJ) $(PCH)

完成以上内容后，make clean,再重新编译，初步估计只需要2分钟！！整整优化了4-5倍。

feixuwu 2011-03-19 16:39 发表评论

定时器的实现

feixuwu — Sun, 13 Mar 2011 14:06:00 GMT

最新换了个项目组，阅读代码后，发现Server端代码居然没有事件和定时器。由于没有事件，所以各个模块代码互相调用的地方特别多，导致代码结构混乱，所有代码都放在一块，乱成一锅粥了。
没有定时器，所有需要定时的任务，都只能添加类似OnUpdate的函数，在主循环的时候执行。定时需求少的时候，看不出明显的问题，但是一旦这种需求多了，尤其是很多内部对象有定时需求的时候，
这个问题就比较明显了，写好了OnUpdate后，还要建立一条从主循环MainLoop到自身OnUpdate的调用链。

事件其实就是一个广播和订阅的关系，Delegate就是实现这样一套机制的利器，目前Delegate的实现主要有2种，一种是CodeProject上的一个FastDelegate实现，另外一个比较典型的实现就是boost的
实现了，无论采取哪种实现方案，实现难度都不算太大。
Server当前框架对定时器无任何支持，只有一个DoMainLoop的函数可以派生来运行自己的定时逻辑。
我原来都是用的ACE封装的组件，用了一段时间也没发现明显问题，不过ACE的定时器不太适合在这个新项目用，主要原因有如下几点：
1、ACE库太大了，不想仅仅为了定时器引入一个这么庞大的库。
2、ACE的定时器需要额外启动一个定时器线程，定时任务是在定时器线程跑的，而我们的项目逻辑其实是在单个线程运行的，如果直接采用ACE定时器，会给逻辑带来额外的复杂度。由于整个逻辑线程的框架是公共模块，手头也没有代码，所以将定时器线程的任务发送到主逻辑线程运行也是不可行的。
3、ACE的定时器有很多种，TIMER_QUEUE、TIMER_WHELL、TIMER_HEAP等，个人感觉这些定时器的插入、取消操作都比较耗时，加以改装放到主线程run的带价将会很大。

其实linux内核就有一个比较高性能的定时器，代码在kernel/Timer.c里， 2.6内核的定时器代码更是简洁。
linux的定时任务都是以jiffie 为单位的，linux将所有定时任务分为5个阶梯，
struct tvec {
   struct list_head vec[TVN_SIZE];
};

struct tvec_root {
   struct list_head vec[TVR_SIZE];
};

struct tvec_base {
   spinlock_t lock;
   struct timer_list *running_timer;
   unsigned long timer_jiffies;
   struct tvec_root tv1;
   struct tvec tv2;
   struct tvec tv3;
   struct tvec tv4;
   struct tvec tv5;
} ____cacheline_aligned;

对一个新的定时任务，处理方法如下:
static void internal_add_timer(struct tvec_base *base, struct timer_list *timer)
{
   unsigned long expires = timer->expires;
   unsigned long idx = expires - base->timer_jiffies;
   struct list_head *vec;

   if (idx < TVR_SIZE) {
       int i = expires & TVR_MASK;
       vec = base->tv1.vec + i;
   } else if (idx < 1 << (TVR_BITS + TVN_BITS)) {
       int i = (expires >> TVR_BITS) & TVN_MASK;
       vec = base->tv2.vec + i;
   } else if (idx < 1 << (TVR_BITS + 2 * TVN_BITS)) {
       int i = (expires >> (TVR_BITS + TVN_BITS)) & TVN_MASK;
       vec = base->tv3.vec + i;
   } else if (idx < 1 << (TVR_BITS + 3 * TVN_BITS)) {
       int i = (expires >> (TVR_BITS + 2 * TVN_BITS)) & TVN_MASK;
       vec = base->tv4.vec + i;
   } else if ((signed long) idx < 0) {
       /*
       * Can happen if you add a timer with expires == jiffies,
       * or you set a timer to go off in the past
       */
       vec = base->tv1.vec + (base->timer_jiffies & TVR_MASK);
   } else {
       int i;
       /* If the timeout is larger than 0xffffffff on 64-bit
       * architectures then we use the maximum timeout:
       */
       if (idx > 0xffffffffUL) {
           idx = 0xffffffffUL;
           expires = idx + base->timer_jiffies;
       }
       i = (expires >> (TVR_BITS + 3 * TVN_BITS)) & TVN_MASK;
       vec = base->tv5.vec + i;
   }
   /*
   * Timers are FIFO:
   */
   list_add_tail(&timer->entry, vec);
}
从上可以看到Linux对定时器的处理：对即将在TVR_SIZE 个jiffies内到达的定时任务，将它挂到第一组tv1 下，具体就是挂到expires & TVR_MASK 对应的列表上去。
同一个jiffies到达的定时器是挂在同一个链表的。
同理，挂到第二个组的是到期时间小于 1 << (TVR_BITS + TVN_BITS) jiffies的。
挂到第三个组的是到期时间小于1 << (TVR_BITS + 2 * TVN_BITS) jiffies的。
挂到第四个组的是到期时间小于 1 << (TVR_BITS + 3 * TVN_BITS) jiffies的。
超过1 << (TVR_BITS + 3 * TVN_BITS) 的挂到第五组。
这样，所有到期的任务都会在第一组。任何时刻都可以直接通过当前jiffies&TVR_SIZE 来找到需要运行的定时器任务列表，定时器的插入效率就是O(1)。

下面是定时器的运行代码：
static int cascade(struct tvec_base *base, struct tvec *tv, int index)
{
   /* cascade all the timers from tv up one level */
   struct timer_list *timer, *tmp;
   struct list_head tv_list;

   list_replace_init(tv->vec + index, &tv_list);

   /*
   * We are removing _all_ timers from the list, so we
   * don't have to detach them individually.
   */
   list_for_each_entry_safe(timer, tmp, &tv_list, entry) {
       BUG_ON(tbase_get_base(timer->base) != base);
       internal_add_timer(base, timer);
   }

   return index;
}

#define INDEX(N) ((base->timer_jiffies >> (TVR_BITS + (N) * TVN_BITS)) & TVN_MASK)

/**
* __run_timers - run all expired timers (if any) on this CPU.
* @base: the timer vector to be processed.
*
* This function cascades all vectors and executes all expired timer
* vectors.
*/
static inline void __run_timers(struct tvec_base *base)
{
   struct timer_list *timer;

   spin_lock_irq(&base->lock);
   while (time_after_eq(jiffies, base->timer_jiffies)) {
       struct list_head work_list;
       struct list_head *head = &work_list;
       int index = base->timer_jiffies & TVR_MASK;

       /*
       * Cascade timers:
       */
       if (!index &&
           (!cascade(base, &base->tv2, INDEX(0))) &&
               (!cascade(base, &base->tv3, INDEX(1))) &&
                   !cascade(base, &base->tv4, INDEX(2)))
           cascade(base, &base->tv5, INDEX(3));
       ++base->timer_jiffies;
       list_replace_init(base->tv1.vec + index, &work_list);
       while (!list_empty(head)) {
           void (*fn)(unsigned long);
           unsigned long data;

           timer = list_first_entry(head, struct timer_list,entry);
           fn = timer->function;
           data = timer->data;

           timer_stats_account_timer(timer);

           set_running_timer(base, timer);
           detach_timer(timer, 1);
           spin_unlock_irq(&base->lock);
           {
               int preempt_count = preempt_count();
               fn(data);
               if (preempt_count != preempt_count()) {
                   printk(KERN_ERR "huh, entered %p "
                           "with preempt_count %08x, exited"
                           " with %08x?\n",
                           fn, preempt_count,
                           preempt_count());
                   BUG();
               }
           }
           spin_lock_irq(&base->lock);
       }
   }
   set_running_timer(base, NULL);
   spin_unlock_irq(&base->lock);
}
当第一组运行完一轮后，需要将tv2的一组新的定时任务加到第一组。这就好比时钟的指针，秒针运行一圈后，分针步进一格，后续的调整都是类似。
cascade 就是负责将下一组的定时任务添加到前面的任务阶梯。只有当第一轮的定时任务全部运行完毕后，才会需要从第二轮调入新的任务，只有第二级别的任务都调入完毕后，才需要从第三轮的定时任务调入新的任务：
if (!index &&
           (!cascade(base, &base->tv2, INDEX(0))) &&
               (!cascade(base, &base->tv3, INDEX(1))) &&
                   !cascade(base, &base->tv4, INDEX(2)))
           cascade(base, &base->tv5, INDEX(3));

这就是负责调整的代码，相当的简洁。
参照上述代码实现一个定时器后，加入4000个定时任务：
    for(int i = 1; i < 4000; i++)
   {
       g_TimerHandle[i] = g_timerManager.setTimer(&tmpSink1, i, i*10, "ss");
   }
从10毫秒到4000*10毫秒,运行后，测试下性能，
函数名                                    执行次数    最小时间     平均时间       最大时间
TimerManager::runTimer    2170566        10              10               3046
可以看到，除了个别时间是因为线程切换导致数据比较大外,平均每次运行runTimer的时间是10微秒。
这个时间还包括每个定时器的执行消耗，效率还是不错的。

feixuwu 2011-03-13 22:06 发表评论

Ogre初体验

feixuwu — Sat, 25 Sep 2010 13:44:00 GMT

最近游戏又要封测了，工作比较紧张，晚上下班了比较累，回家懒得写代码了，不过顺便倒是继续完成了对新剑侠情缘（和月影传说的资源格式相同）的资源逆向。完成了资源逆向后，突然兴致来了，写了个简单的地图查看器，到目前为止，一切运行正常。后来做了个简单的Demo，实现了基本的寻路和技能动画播放，其实新剑侠情缘原本的技能效果以今天的眼光看起来也还可以，即便如此，我还是集成了hge的粒子系统进去，试了下效果，还是挺奇怪的。
做完了这些之后，本想为我的PSP山寨一个新剑侠情缘。不料后来连续加了好几天班，加了几天班之后，人也懒了，山寨游戏的事情也就无疾而终了。
前面写过几篇逆向工程的文章，前几天翻出来看了下，感觉像是另一个人写的天书，我自己看自己的文章尚且如此，别人就更不用说了，其实对大部分人而言，关心的只是逆向的成果。对新剑侠情缘的资源和相关渲染感兴趣的朋友可以单独Email我。
开始阅读Ogre代码正是在这百无聊赖的状态下开始的，Ogre推出来很多年了，貌似05年就听说朋友说起过这个项目，不过我一向是专注服务端开发，对客户端开发经验不是很多，在3D领域就完全是的新手了，所以一直也没仔细研究。这几天拿起原来下载的一个版本，简单读了下代码。
Ogre的结构还是很清晰的，和手册上说的一样，主要就是那几个对象，Demo大部分也很简单，代码量不多，看起来很振奋人心。
但是对我这样的新手来说，首先想了解的当然是渲染流程。 Ogre的渲染流程确实会让3D新手不适应，它是从RenderTarget开始的，一个RenderTarget可以有几个ViewPort，每个ViewPort都有一个独立的摄像机，这可以实现同屏幕多个渲染。
通过ViewPort对象的update调用
mCamera->_renderScene(this, mShowOverlays);
来执行场景渲染，而场景渲染里，最重要的要算_findVisibleObjects了，
这个函数将可见的物体添加到渲染队列里，这个函数非常的绕，里面还用到了Vistor,精神不好容易被绕晕，好在我挺住了，熬过来了。
熟悉了大致的渲染流程后，我觉得该写点东西来实战了。
3D教程的开始一般会教大家画三角形，所以我也想用Ogre画个三角形玩玩，
一开始，我也想从像那些Demo一样从ExampleApplication继承，不过我发现这样启动太慢了，而且我不需要加载那么多的材质，
所以自己手动Configure了，代码如下:
Ogre::LogManager* pLogManager = new Ogre::LogManager;
   Ogre::Log* pLog = pLogManager->createLog("ogreLearn1.log");
   pLog->setDebugOutputEnabled(true);

   Ogre::Root* pRootObject = new Ogre::Root;
   pRootObject->loadPlugin("RenderSystem_Direct3D9_d.dll");
   pRootObject->loadPlugin("Plugin_OctreeSceneManager_d.dll");

    Ogre::RenderSystem* pRenderSystem = pRootObject->getRenderSystemByName("Direct3D9 Rendering Subsystem");
    pRenderSystem->setConfigOption("Full Screen", "False");
    pRootObject->setRenderSystem(pRenderSystem);
    Ogre::RenderWindow* pRenderWindow = pRootObject->initialise(true);

编译测试了下，可以正常运行，不过发现屏幕是花的，我还没有创建场景呢，继续添加摄像机和ViewPort以及场景
// 创建场景和摄像机以及ViewPort
   Ogre::SceneManager* pSceneManager = pRootObject->createSceneManager(Ogre::ST_GENERIC, "OgreLearn1");
   Ogre::Camera* pCamera = pSceneManager->createCamera("MainCamara");
   pCamera->setPosition(0.0, 0.0, -20.0);
   pCamera->lookAt(0, 0, 0);
   pCamera->setNearClipDistance(2);

   Ogre::Viewport* pViewPort = pRenderWindow->addViewport(pCamera);
   pViewPort->setBackgroundColour(Ogre::ColourValue(0, 0, 0, 1.0f) );
   pCamera->setAspectRatio(pViewPort->getActualWidth()/pViewPort->getActualHeight() );

最后加上pRootObject->startRendering();
编译运行，一切正常，屏幕颜色也变成了想要的黑色，恩，下一步该添加三角形了，我不太喜欢用OgreManualObject，一堆的繁琐操作。这里用自定义的Mesh来绘制3角形。
pSceneManager->setAmbientLight(Ogre::ColourValue(0.2, 0.2, 0.2) );
       Ogre::MeshPtr pMeshData = Ogre::MeshManager::getSingleton().createManual("Learn", Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME);
       Ogre::SubMesh* pSubMesh = pMeshData->createSubMesh();
       pSubMesh->useSharedVertices = false;
       pSubMesh->vertexData = new Ogre::VertexData;
       pSubMesh->vertexData->vertexStart = 0;
       pSubMesh->vertexData->vertexCount = 3;

先设置了环境光(其实没啥用，我后面会禁止)，然后创建了一个自定义的Mesh,
紧接着的是创建一个SubMesh，要知道Ogre中最小的网格就是SubMesh,创建好SubMesh后，要填充网格结构了，
创建了一个VertexData,设置顶点数目为3（也就是一个三角形），下面该定义顶点格式了，
Ogre::VertexDeclaration* pDecle = pSubMesh->vertexData->vertexDeclaration;
       size_t sOffset = 0;
       pDecle->addElement(0, sOffset, Ogre::VET_FLOAT3, Ogre::VES_POSITION);
       sOffset += Ogre::VertexElement::getTypeSize(Ogre::VET_FLOAT3);
       pDecle->addElement(0, sOffset, Ogre::VET_COLOUR, Ogre::VES_DIFFUSE);
       sOffset += Ogre::VertexElement::getTypeSize(Ogre::VET_COLOUR);

上述代码定义了顶点格式，只有基本的坐标和颜色。
下一步将是申请显存，填充顶点结构。
Ogre::HardwareVertexBufferSharedPtr vBuf = Ogre::HardwareBufferManager::getSingleton().createVertexBuffer(sOffset, 3, Ogre::HardwareBuffer::HBU_STATIC_WRITE_ONLY);
       float* pReal = static_cast(vBuf->lock(Ogre::HardwareBuffer::HBL_DISCARD));
       Ogre::RGBA* pColor = NULL;

       *pReal++ = -2.0f;
       *pReal++ = 0.0f;
       *pReal++ = 0.0f;
       pColor = (Ogre::RGBA*)pReal;
       pRenderSystem->convertColourValue(Ogre::ColourValue(1.0f, 0.0, 0, 0.0f), pColor);
       pReal = (float*)(pColor+1);

        *pReal++ = 0.0f;
        *pReal++ = 2.0f;
        *pReal++ = 0.0f;
        pColor = (Ogre::RGBA*)pReal;
        pRenderSystem->convertColourValue(Ogre::ColourValue(0.0f, 0, 1.0, 1.0f), pColor);
        pReal = (float*)(pColor+1);

        *pReal++ = 2.0f;
        *pReal++ = 0.0f;
        *pReal++ = 0.0f;
        pColor = (Ogre::RGBA*)pReal;
        pRenderSystem->convertColourValue(Ogre::ColourValue(1.0f, 0, 0, 1.0f), pColor);
        pReal = (float*)(pColor+1);
        vBuf->unlock();
        pSubMesh->vertexData->vertexBufferBinding->setBinding(0, vBuf);

        pMeshData->load();
        pMeshData->_setBounds(Ogre::AxisAlignedBox(-2, 0, -1, 2, 2, 1) );
填充顶点后，设置网格包围盒，这样一个自定义的网格就创建好了，接下来要创建一个使用该网格的实体了
    Ogre::Entity* pEntity = pSceneManager->createEntity("TestEntity", "Learn");
       pEntity->setMaterialName("BaseWhiteNoLighting");

       pSceneManager->getRootSceneNode()->createChildSceneNode()->attachObject(pEntity);
       pEntity->getParentNode()->setPosition(3, 0, 0);
       pEntity->getParentNode()->rotate(Ogre::Quaternion(1.0f, 1.0f, 0, 1.0f) );

好了，这样实体也创建好了，接下来执行渲染吧：
pRootObject->startRendering();

遇到的问题

上述代码是运行正常的，但是一开始，我执行的结果是看不到任何东西，跟踪了下，发现实体每次都被摄像机裁剪了，才发觉自定义Mesh要自己设置包围盒子，
设置可包围盒子。
设置了包围盒后，数据已经进入了D3D的渲染管道，但是还是没看到三角形，仔细观察，原来摄像机对着的是三角形的背面。。。
调整摄像机后，终于能看到一个三角形了，不过是白色的。。。
从这个症状看，应该是没有关闭光照导致的，但是我明明主动调用RenderSystem关闭光照了啊，仔细跟踪了下原来是材质在捣乱，
默认的材质是开启了光照的，所以在渲染前的SceneManager::_setPass 的时候，开启了光照。
这好办，主动设置了关闭光照的材质"BaseWhiteNoLighting" 后，终于看到了彩色三角形了。

feixuwu 2010-09-25 21:44 发表评论

select 和 epoll

feixuwu — Sat, 10 Jul 2010 10:40:00 GMT

最近有朋友在面试的时候被问了select 和epoll效率差的原因，和一般人一样，大部分都会回答select是轮询、epoll是触发式的，所以效率高。这个答案听上去很完美，大致也说出了二者的主要区别。
今天闲来无事，翻看了下内核代码，结合内核代码和大家分享下我的观点。

一、连接数

我本人也曾经在项目中用过select和epoll,对于select，感触最深的是linux下select最大数目限制(windows 下似乎没有限制)，每个进程的select最多能处理FD_SETSIZE个FD(文件句柄)，
如果要处理超过1024个句柄，只能采用多进程了。
常见的使用slect的多进程模型是这样的：一个进程专门accept，成功后将fd通过unix socket传递给子进程处理，父进程可以根据子进程负载分派。曾经用过1个父进程+4个子进程承载了超过4000个的负载。
这种模型在我们当时的业务运行的非常好。epoll在连接数方面没有限制，当然可能需要用户调用API重现设置进程的资源限制。

二、IO差别

1、select的实现

这段可以结合linux内核代码描述了，我使用的是2.6.28，其他2.6的代码应该差不多吧。
先看看select:
select系统调用的代码在fs/Select.c下，
asmlinkage long sys_select(int n, fd_set __user *inp, fd_set __user *outp,
           fd_set __user *exp, struct timeval __user *tvp)
{
   struct timespec end_time, *to = NULL;
   struct timeval tv;
   int ret;

   if (tvp) {
       if (copy_from_user(&tv, tvp, sizeof(tv)))
           return -EFAULT;

       to = &end_time;
       if (poll_select_set_timeout(to,
               tv.tv_sec + (tv.tv_usec / USEC_PER_SEC),
               (tv.tv_usec % USEC_PER_SEC) * NSEC_PER_USEC))
           return -EINVAL;
   }

   ret = core_sys_select(n, inp, outp, exp, to);
   ret = poll_select_copy_remaining(&end_time, tvp, 1, ret);

   return ret;
}
前面是从用户控件拷贝各个fd_set到内核空间，接下来的具体工作在core_sys_select中，
core_sys_select->do_select,真正的核心内容在do_select里：
int do_select(int n, fd_set_bits *fds, struct timespec *end_time)
{
   ktime_t expire, *to = NULL;
   struct poll_wqueues table;
   poll_table *wait;
   int retval, i, timed_out = 0;
   unsigned long slack = 0;

   rcu_read_lock();
   retval = max_select_fd(n, fds);
   rcu_read_unlock();

   if (retval < 0)
       return retval;
   n = retval;

   poll_initwait(&table);
   wait = &table.pt;
   if (end_time && !end_time->tv_sec && !end_time->tv_nsec) {
       wait = NULL;
       timed_out = 1;
   }

   if (end_time && !timed_out)
       slack = estimate_accuracy(end_time);

   retval = 0;
   for (;;) {
       unsigned long *rinp, *routp, *rexp, *inp, *outp, *exp;

       set_current_state(TASK_INTERRUPTIBLE);

       inp = fds->in; outp = fds->out; exp = fds->ex;
       rinp = fds->res_in; routp = fds->res_out; rexp = fds->res_ex;

       for (i = 0; i < n; ++rinp, ++routp, ++rexp) {
           unsigned long in, out, ex, all_bits, bit = 1, mask, j;
           unsigned long res_in = 0, res_out = 0, res_ex = 0;
           const struct file_operations *f_op = NULL;
           struct file *file = NULL;

           in = *inp++; out = *outp++; ex = *exp++;
           all_bits = in | out | ex;
           if (all_bits == 0) {
               i += __NFDBITS;
               continue;
           }

           for (j = 0; j < __NFDBITS; ++j, ++i, bit <<= 1) {
               int fput_needed;
               if (i >= n)
                   break;
               if (!(bit & all_bits))
                   continue;
               file = fget_light(i, &fput_needed);
               if (file) {
                   f_op = file->f_op;
                   mask = DEFAULT_POLLMASK;
                   if (f_op && f_op->poll)
                       mask = (*f_op->poll)(file, retval ? NULL : wait);
                   fput_light(file, fput_needed);
                   if ((mask & POLLIN_SET) && (in & bit)) {
                       res_in |= bit;
                       retval++;
                   }
                   if ((mask & POLLOUT_SET) && (out & bit)) {
                       res_out |= bit;
                       retval++;
                   }
                   if ((mask & POLLEX_SET) && (ex & bit)) {
                       res_ex |= bit;
                       retval++;
                   }
               }
           }
           if (res_in)
               *rinp = res_in;
           if (res_out)
               *routp = res_out;
           if (res_ex)
               *rexp = res_ex;
           cond_resched();
       }
       wait = NULL;
       if (retval || timed_out || signal_pending(current))
           break;
       if (table.error) {
           retval = table.error;
           break;
       }

       /*
       * If this is the first loop and we have a timeout
       * given, then we convert to ktime_t and set the to
       * pointer to the expiry value.
       */
       if (end_time && !to) {
           expire = timespec_to_ktime(*end_time);
           to = &expire;
       }

       if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS))
           timed_out = 1;
   }
   __set_current_state(TASK_RUNNING);

   poll_freewait(&table);

   return retval;
}
上面的代码很多，其实真正关键的代码是这一句:
mask = (*f_op->poll)(file, retval ? NULL : wait);
这个是调用文件系统的 poll函数，不同的文件系统poll函数自然不同，由于我们这里关注的是tcp连接，而socketfs的注册在 net/Socket.c里。
register_filesystem(&sock_fs_type);
socket文件系统的函数也是在net/Socket.c里：
static const struct file_operations socket_file_ops = {
   .owner =   THIS_MODULE,
   .llseek =   no_llseek,
   .aio_read =   sock_aio_read,
   .aio_write =   sock_aio_write,
   .poll =       sock_poll,
   .unlocked_ioctl = sock_ioctl,
#ifdef CONFIG_COMPAT
   .compat_ioctl = compat_sock_ioctl,
#endif
   .mmap =       sock_mmap,
   .open =       sock_no_open,   /* special open code to disallow open via /proc */
   .release =   sock_close,
   .fasync =   sock_fasync,
   .sendpage =   sock_sendpage,
   .splice_write = generic_splice_sendpage,
   .splice_read =   sock_splice_read,
};
从sock_poll跟随下去，
最后可以到 net/ipv4/tcp.c的
unsigned int tcp_poll(struct file *file, struct socket *sock, poll_table *wait)
这个是最终的查询函数，
也就是说select 的核心功能是调用tcp文件系统的poll函数，不停的查询，如果没有想要的数据，主动执行一次调度（防止一直占用cpu），直到有一个连接有想要的消息为止。
从这里可以看出select的执行方式基本就是不同的调用poll,直到有需要的消息为止，如果select 处理的socket很多，这其实对整个机器的性能也是一个消耗。

2、epoll的实现

epoll的实现代码在 fs/EventPoll.c下，
由于epoll涉及到几个系统调用，这里不逐个分析了，仅仅分析几个关键点，
第一个关键点在
static int ep_insert(struct eventpoll *ep, struct epoll_event *event,
             struct file *tfile, int fd)
这是在我们调用sys_epoll_ctl 添加一个被管理socket的时候调用的函数，关键的几行如下：
epq.epi = epi;
   init_poll_funcptr(&epq.pt, ep_ptable_queue_proc);

   /*
   * Attach the item to the poll hooks and get current event bits.
   * We can safely use the file* here because its usage count has
   * been increased by the caller of this function. Note that after
   * this operation completes, the poll callback can start hitting
   * the new item.
   */
   revents = tfile->f_op->poll(tfile, &epq.pt);
这里也是调用文件系统的poll函数，不过这次初始化了一个结构，这个结构会带有一个poll函数的callback函数：ep_ptable_queue_proc，
在调用poll函数的时候，会执行这个callback，这个callback的功能就是将当前进程添加到 socket的等待进程上。
static void ep_ptable_queue_proc(struct file *file, wait_queue_head_t *whead,
               poll_table *pt)
{
   struct epitem *epi = ep_item_from_epqueue(pt);
   struct eppoll_entry *pwq;

   if (epi->nwait >= 0 && (pwq = kmem_cache_alloc(pwq_cache, GFP_KERNEL))) {
       init_waitqueue_func_entry(&pwq->wait, ep_poll_callback);
       pwq->whead = whead;
       pwq->base = epi;
       add_wait_queue(whead, &pwq->wait);
       list_add_tail(&pwq->llink, &epi->pwqlist);
       epi->nwait++;
   } else {
       /* We have to signal that an error occurred */
       epi->nwait = -1;
   }
}
注意到参数 whead 实际上是 sk->sleep，其实就是将当前进程添加到sk的等待队列里，当该socket收到数据或者其他事件触发时，会调用
sock_def_readable 或者sock_def_write_space 通知函数来唤醒等待进程，这2个函数都是在socket创建的时候填充在sk结构里的。
从前面的分析来看，epoll确实是比select聪明的多、轻松的多，不用再苦哈哈的去轮询了。

feixuwu 2010-07-10 18:40 发表评论

一、使用方法

打开主页，由于公司网络禁止SVN从外部更新，所以只能下载了打包的源代码。解压后，看到有个doc目录，进去，打开使用文档，发现使用方法极为简单：
To use TCMalloc, just link TCMalloc into your application via the "-ltcmalloc" linker flag.再看算法，也没什么特别的，还是和slab以及SGI STL分配器类似的算法。
unix环境居然只要链接这个tcmalloc库就可以了！，太方便了，不过我手头没有linux环境，文档上也没提到windows环境怎么使用，
打开源代码包，有个vs2003解决方案，打开，随便挑选一个测试项目，查看项目属性，发现仅仅有2点不同：
1、链接器命令行里多了
"..\..\release\libtcmalloc_minimal.lib"，就是链接的时候依赖了这个内存优化库。
2、链接器->输入->强制符号引用多了 __tcmalloc。
这样就可以正确的使用tcmalloc库了，测试了下，测试项目运行OK!

二、如何替换CRT的malloc

从前面的描述可知，项目强制引用了__tcmalloc，搜索了测试代码，没发现用到_tcmalloc相关的函数和变量,这个选项应该是为了防止dll被优化掉(因为代码里没有什么地方用到这个dll的符号)。
初看起来，链接这个库后，不会影响任何现有代码:我们没有引用这个Lib库的头文件，也没有使用过这个dll的导出函数。那么这个dll是怎么优化应用程序性能的呢？
实际调试，果然发现问题了，看看如下代码
    void* pData = malloc(100);
00401085 6A 64            push        64h
00401087 FF 15 A4 20 40 00 call        dword ptr [__imp__malloc (4020A4h)]
跟踪 call malloc这句，step进去，发现是
78134D09 E9 D2 37 ED 97   jmp         `anonymous namespace'::LibcInfoWithPatchFunctions<8>::Perftools_malloc (100084E0h)
果然，从这里开始，就跳转到libtcmalloc提供的Perftools_malloc了。
原来是通过API挂钩来实现无缝替换系统自带的malloc等crt函数的，而且还是通过大家公认的不推荐的改写函数入口指令来实现的，一般只有在游戏外挂和金山词霸之类的软件才会用到这样的挂钩技术，
而且金山词霸经常需要更新补丁解决不同系统兼容问题。

三、性能差别原因

如前面所述，tcmalloc确实用了很hacker的办法来实现无缝的替换系统自带的内存分配函数（本人在使用这类技术通常是用来干坏事的。。。），但是这也不足以解释为什么它的效率比我们自己的好那么多。
回到tcmalloc 的手册，tcmalloc除了使用常规的小内存管理外，对多线程环境做了特殊处理，这和我原来见到的内存分配器大有不同，一般的内存分配器作者都会偷懒，把多线程问题扔给使用者，大多是加
个bool型的模板参数来表示是否是多线程环境，还美其名曰:可定制，末了还得吹嘘下模板的优越性。
tcmalloc是怎么做的呢？答案是每线程一个ThreadCache，大部分操作系统都会支持thread local storage 就是传说中的TLS,这样就可以实现每线程一个分配器了，
这样，不同线程分配都是在各自的threadCache里分配的。我们的项目的分配器由于是多线程环境的，所以不管三七二十一，全都加锁了，性能自然就低了。

仅仅是如此，还是不足以将tcmalloc和ptmalloc2分个高下，后者也是每个线程都有threadCache的。
关于这个问题，doc里有一段说明，原文贴出来：
ptmalloc2 also reduces lock contention by using per-thread arenas but there is a big problem with ptmalloc2's use of per-thread arenas. In ptmalloc2 memory can never move from one arena to another. This can lead to huge amounts of wasted space.
大意是这样的：ptmalloc2 也是通过tls来降低线程锁，但是ptmalloc2各个线程的内存是独立的，也就是说，第一个线程申请的内存，释放的时候还是必须放到第一个线程池中（不可移动），这样可能导致大量内存浪费。

四、代码细节

1、无缝替换malloc等crt和系统分配函数。

前面提到tcmalloc会无缝的替换掉原有dll中的malloc，这就意味着使用tcmalloc的项目必须是 MD（多线程dll）或者MDd（多线程dll调试）。tcmalloc的dll定义了一个
static TCMallocGuard module_enter_exit_hook;
的静态变量，这个变量会在dll加载的时候先于DllMain运行，在这个类的构造函数，会运行PatchWindowsFunctions来挂钩所有dll的 malloc、free、new等分配函数，这样就达到了替换功能，除此之外，
为了保证系统兼容性，挂钩API的时候还实现了智能分析指令，否则写入第一条Jmp指令的时候可能会破环后续指令的完整性。

2、LibcInfoWithPatchFunctions 和ThreadCache。

LibcInfoWithPatchFunctions模板类包含tcmalloc实现的优化后的malloc等一系列函数。LibcInfoWithPatchFunctions的模板参数在我看来没什么用处，tcmalloc默认可以挂钩
最多10个带有malloc导出函数的库(我想肯定是够用了)。ThreadCache在每个线程都会有一个TLS对象：
__thread ThreadCache* ThreadCache::threadlocal_heap_。

3、可能的问题

设想下这样一个情景：假如有一个dll 在tcmalloc之前加载，并且在分配了内存（使用crt提供的malloc），那么在加载tcmalloc后，tcmalloc会替换所有的free函数，然后，在某个时刻，
在前面的那个dll代码中释放该内存，这岂不是很危险。实际测试发现没有任何问题，关键在这里：
span = Static::pageheap()->GetDescriptor(p);
    if (!span) {
      // span can be NULL because the pointer passed in is invalid
      // (not something returned by malloc or friends), or because the
      // pointer was allocated with some other allocator besides
      // tcmalloc. The latter can happen if tcmalloc is linked in via
      // a dynamic library, but is not listed last on the link line.
      // In that case, libraries after it on the link line will
      // allocate with libc malloc, but free with tcmalloc's free.
      (*invalid_free_fn)(ptr); // Decide how to handle the bad free request
      return;
    }
tcmalloc会通过span识别这个内存是否自己分配的，如果不是，tcmalloc会调用该dll原始对应函数(这个很重要)释放。这样就解决了这个棘手的问题。

五、其他

其实tcmalloc使用的每个技术点我从前都用过，但是我从来没想过用API挂钩来实现这样一个有趣的内存优化库（即使想过，也是一闪而过就否定了）。
从tcmalloc得到灵感，结合常用的外挂技术，可以很轻松的开发一个独立工具：这个工具可以挂载到指定进程进行内存优化，在我看来，这可能可以作为一个外挂辅助工具来优化那些
内存优化做的很差导致帧速很低的国产游戏。

feixuwu 2010-07-10 17:32 发表评论