基于CREDIS开发的订阅发布消息队列SDK，引发的野指针问题

我们先看看什么是内存泄漏和野指针。
1、内存泄漏
定义：内存泄漏，往往指的是堆内存泄漏；由程序申请的一块内存，且没有任何一个指针指向它。
后果：当程序运行时间越长，占用内存越多，最终用尽全部内存，整个系统崩溃。
2、野指针
定义：未初始化或未清零的指针，指向的内存地址不是程序员想要的。
产生原因：
指针使用前未初始化
指针使用完了没置NULL
函数返回值为指向局部变量
避免的方法：
使用指针前必须初始化指针
指针用完且释放了所指向的内存后，记得置为NULL

错误经历：
关于野指针，之前在开发一个基于CREDIS的订阅发布消息队列SDK的时候深深的踩坑了。
当时的问题：
使用这个SDK的模块，很久不收发消息（超过一个小时），然后发送一条消息。
发现模块居然core掉了。从堆栈看出来，CORE掉的原因，REDIS上下文（订阅发布功能都要通过这个REDIS上下文对象去调函数实现的）堆栈乱七八糟的，内容明显不对，疑似被踩。

分析与解决的过程：
当时的怀疑点：
模块是新开发的，其他代码有问题，把上下文对象踩了。
走读代码：无果
然后加GDB监控，收发命令，再用用模块的其他功能，用以触发其他代码，监控的redis上下文对象内存都好好的。

一个小时后，有趣的来了，REDIS上下文变化了，又查REDIS的代码，发现怀疑点，CREDIS的析构函数被调用了。联系REDIS业务相关的专家一问，REDIS会不会主动释放上下文。答案是会的！！

REDIS检测到一个小时都没有活跃度，把上下文的内存给偷偷释放了。这就能解释了。我们的SDK虽然保存了REDIS上下文指针，但是指针指向的对象已经给偷偷释放了。。
加心跳，问题解决。。。

问题本质：
使用了野指针（即REDIS上下文对象指针，指向的内容实际被释放了）