引用计数gc机制使用不当导致内存泄漏

上一篇文章找同事review了一下，收到的反馈是铺垫太长了，我尽量直入正题，哈哈

最近dbd压测时发现内存泄漏，其实这个问题去年已经暴露了，参见这篇博客【压测周】。当时排查不够仔细，在此检讨下。关于dbd的内存问题，还有这篇博客讨论线程安全，以及这篇博客讨论临时变量的处理。当时还存了一个尾巴，因为用到关联数组进行脏数据管理，这部分数据是怎么释放的一直没搞明白。今天算是搞明白了，这个内存泄漏的bug也源于此。

基于引用计数的gc机制，应该是在引用计数为0的时候释放内存的，lpc也基本没有例外。具体详情可以参看free_svalue的实现，里面基本是引用计数减去1，然后检查是否引用计数为0，若是0就执行相关的Free操作。其中，有一半的篇幅都是讲字符串的释放的，剩下的则是object、buffer、array、mapping、class以及function的释放问题。所以，基本上，lpc不需要像golang一样，停止一切操作做mark and swap的gc操作。也不同于Lua的标记清除，不需要分步执行，只要引用计数为0，立马释放掉。

为什么是基本上呢？因为对于object类型，lpc并没有对其立即释放，而是放到一个链表里面，待主循环里没有函数执行时，再行销毁。这样做，一方面是为了配合复杂的热更新机制，另一方面，则是解决object循环引用的需要。对于对象的销毁，首先调用的是destruct_object, 这个函数最终的作用是为对象打上销毁标志。在这个函数里，针对master object和simul_efun object做了热更新的处理。然后从栈上移除object的所有引用，从object#n列表里移除这个object。最后打上销毁标记，并放入待销毁列表。

下一步，则调用destruct2, 首先将该object的所有变量释放。如果该对象有对自身引用，则因为这一步而引用计数减一，方便接下来释放该对象本身。接着调用free_object, 对象引用次数为0，已打上销毁标记，功成身退，成功析构。

由于在dbd中，没有跑lpc脚本，所有的关联数组（mapping）都是在C层生成和使用的，因此引用计数需要手工维护，这就是万恶之源了。对于脚本层，新建的变量，引用计数都应该为1，退出变量作用域时，则引用计数减一。放入mapping时，引用次数相应加1。而在C层使用mapping时，所有变量的组织都是围绕mapping展开的，变量的生命周期就等同于mapping的生命周期。当序列化数据后，释放数据对应的mapping时，会对其中的所有变量引用计数-1，但依然计数不为0，因此无法释放。

解决的办法也相当简单，变量放入mapping前，先free_svalue，将引用计数变为0，则加入mapping后，引用计数为1，生命周期就同mapping一样了。