你担心大家会滥用的全局变量，大家(包括你自己)一定会滥用-阿里云开发者社区

前言

不要使用全局变量的道理大家都懂，基本上在大家学习编程过程中很早就会被教育到，但是有时候我们也会禁不住诱惑用到一些似非实是的全局变量，只不过这些全局变量会穿上马甲，让你不会一下看穿它的巨大危害，滥用全局变量会引申带来其它更为严重的结构性系统问题。

你担心大家会滥用的代码，大家(包括你自己)一定会滥用。
                                              -- 鲁迅。

滥用全局变量的危害

1. 滥用全局变量会造成不必要的常量频繁使用，特别当这个常量没有用宏定义“正名”时，代码阅读起来将万分吃力。

2. 会导致软件分层的不合理，全局变量相当于一条快捷通道，这在软件系统的构建初期的确效率很高，功能调试进度一日千里，但到了后期往往bug一堆，处处“补丁”，雷区遍布。

编辑

3. 由于软件的分层不合理，到了后期维护，哪怕仅是增加修改删除小功能，往往要从上到下掘地三尺地修改，涉及大多数模块，而原有的代码注释却忘了更新修改，这个时候，交给后来维护者的系统会越来越像一个“泥潭”，注释的唯一作用只是使泥潭上方再加一些迷烟瘴气。

4. 全局变量大量使用，少不了有些变量流连忘返于中断与主回圈程序之间。这个时候如果处理不当，系统的bug就是随机出现的，无规律的，这时候初步显示出病入膏肓的特征来了，没有大牛来力挽狂澜，注定慢性死亡。

无需多言，您已经成功得到一个畸形的系统，它处于一个神秘的稳定状态！

本篇文章我不再赘述全局变量，局部变量等基础知识，感兴趣的可以查看历史文章。

滥用全局变量示例

读到这里，对于新手们来说可能还没有意识到全局变量的危险性，这里我先拿出来一段不太复杂的一段代码：

#include <iostream>
#include <string>
#include <map>
using namespace std;
class Monster
{
private:
    int npc_id;
public:
        Monster(int npc_id):npc_id(npc_id){
            cout << "call Monster::Init" << npc_id <<endl;
        }
        int NpcID(){
            return npc_id;
        }
            virtual void Stand(){
            cout << "call Monster::Stand" <<endl;    
        }
        virtual void Walk(){
            cout << "call Monster::Walk" <<endl;
        }
        virtual int Stop(){
            cout << "call Monster::Stop" <<endl;
        }
        ~Monster(){
            cout << "call ~Monster" <<endl;
        }
};
class NPCFactory
{
public:
        static NPCFactory& Instance(){
            cout << "call static NPCFactory" <<endl;
            static NPCFactory instance;
            return instance;
        }
        ~NPCFactory(){
            cout << "call ~NPCFactory" <<endl;
        }
        Monster* Create(int npc_id){
            map<int,Monster*>::iterator itr = monsters_.find(npc_id);
            if (itr != monsters_.end()) {
                return itr->second;
            }
            Monster* monster = new Monster(npc_id);
            monsters_.insert({ {npc_id, monster} });
            return monster;
        }
        bool Release(Monster* monster){
            if (monster == nullptr){
                return false;
            }
            int npc_id = monster->NpcID();
            map<int,Monster*>::iterator itr = monsters_.find(npc_id);
            if (itr == monsters_.end()) {
                 return false;
            }
            delete monster;
            monsters_.erase(npc_id);
            return true;
        }
private:
        map<int, Monster*> monsters_;
};
#define testobj MonsterMgr::Instance()
class MonsterMgr
{
public:
        virtual ~MonsterMgr(){
            cout << "call ~MonsterMgr" <<endl;
            for (auto d : monsters_){
                 NPCFactory::Instance().Release(d.second);
            }
        }
        Monster* Create(const uint32_t& npc_id)
{
            Monster* monster = NPCFactory::Instance().Create(npc_id);
            monsters_.insert(std::make_pair(npc_id, monster));
            return monster;
        }
        static MonsterMgr& Instance(){
            cout << "call static MonsterMgr" <<endl;
            static MonsterMgr npc_mgr;
            return npc_mgr;
        }
private:
        std::map<uint32_t, Monster*> monsters_;
};
int main(){
    testobj.Create(1000);
    return 0;
}

看了几遍没看出来哪里有问题？不妨运行看下

编辑

没错，程序崩溃了，提示double free了？为什么？

归根到底还是全局变量使用的泛滥导致的。

首先我们来分析下：

testobj是一个静态全局变量，在调用Create方法里，通过NPCFactory的静态全局变量工厂方法创建了Monster实例，因此在出了main函数之后，先释放了静态全局变量NPCFactory的成员，由于工厂方法没有正常释放monsters_的成员，造成了内存泄露，实际上这个时候的monsters_里的指针已经变成了野指针，紧接着释放静态全局变量testobj，进入析构MonsterMgr，逐个释放Monster指针，注意这里：NPCFactory::Instance().Release(m_monster); 实际上m_monster已经在NPCFactory工厂释放掉了，成为了野指针，所以在调用NPCFactory::Instance().Release(m_monster);的时候就出现了释放野指针崩溃。

这次相信你可能会比较谨慎的使用全局变量了，尤其是穿梭在多个功能里，跟玩“鳞波微步”一样的潇洒，岂不知已经给后面埋下了地雷。

此时的系统因为离不开你了，所有“雷区”只有你了然于心。当出现紧急的bug时，只有你能够搞定。老板不但不能辞退你，还要给你加薪。

但凡招聘来维护这个系统的，除了改出更多的bug外，基本上一个月内就走人，到了外面还宣扬这个公司的软件质量有够差够烂。

随着产品的后续升级，几个月没有接触这个系统的你会发现，很多雷区你本人也忘记了，于是每次的产品升级维护周期越来越长，因为修改一个功能会冒出很多bug，而按下一个bug，会弹出其他更多的bug。在这期间，又会产生更多的全局变量。终于有一天你告诉老板，不行啦不行啦，资源不够了，内存太小了，升级升级，某个库用的有问题，要换掉！！！

那么有什么对策？

1. 能不用全局变量尽量不用，我想除了系统状态和控制参数、通信处理和一些需要效率的模块，其他的基本可以靠合理的软件分层和编程技巧来解决。

2. 如果不可避免需要用到，那能藏多深就藏多深。

1)如果只有某.c文件用，就static到该文件中，顺便把结构体定义也收进来；

2)如果只有一个函数用，那就static到函数里面去；

3)如果非要开放出去让人读取，那就用函数return出去，这样就是只读属性了；

4)如果非要遭人蹂躏赋值，好吧，我开放函数接口让你传参赋值；

5)实在非要extern我，我还可以严格控制包含我.h档的对象，而不是放到公共的includes.h中被人围观，丢人现眼。

继续带着刚才的问题，那么如何解决崩溃问题呢？

两种方式：

1.如果你的代码逻辑本身够复杂，大动干戈，想最小代价来修复问题，你可以在NpcFactory析构之前，主动释放掉NpcMgr里的一堆指针，新增一个NpcMgr的Clear方法，用于在main函数结束之前主动调用来释放资源。

class MonsterMgr
{
public:
        virtual ~MonsterMgr(){
            cout << "call ~MonsterMgr" <<endl;
            Clear();
        }
        virtual void Clear(){
             for (auto d : monsters_){
                 NPCFactory::Instance().Release(d.second);
            }
        }
        Monster* Create(const uint32_t& npc_id)
{
            Monster* monster = NPCFactory::Instance().Create(npc_id);
            monsters_.insert(std::make_pair(npc_id, monster));
            return monster;
        }
        static MonsterMgr& Instance(){
            cout << "call static MonsterMgr" <<endl;
            static MonsterMgr npc_mgr;
            return npc_mgr;
        }
private:
        std::map<uint32_t, Monster*> monsters_;
};
int main(){
    testobj.Create(1000);
    testobj.Clear();
    return 0;
}

但是我不建议这样做，因为你将给其他人带来麻烦，必须要主动显式调用Clear方法，如果某一天，有人改动了一些Clear的逻辑，你可能仍然面临加班排查问题的境地。

2.就是重构设计，尽可能避免全局变量引发的问题。

其实你主要要解决的是如何避免在MonsterMgr释放所有的Monster指针之前已经将NPCFactory提前释放导致monster野指针问题（这里我不讨论NPCFactory工厂类的释放Release存在的问题），因此你可以考虑下让工厂类作为MonsterMgr的类静态成员，通过静态类成员来管理monster，这样，你可以保证在析构MonsterMgr释放所有monster指针之前，工厂类管理的所有monster指针是有效的。

#include <iostream>
#include <string>
#include <map>
using namespace std;
class Monster
{
private:
    int npc_id;
public:
        Monster(int npc_id):npc_id(npc_id){
            cout << "call Monster::Init" << npc_id <<endl;
        }
        int NpcID(){
            return npc_id;
        }
            virtual void Stand(){
            cout << "call Monster::Stand" <<endl;    
        }
        virtual void Walk(){
            cout << "call Monster::Walk" <<endl;
        }
        virtual int Stop(){
            cout << "call Monster::Stop" <<endl;
        }
        ~Monster(){
            cout << "call ~Monster" <<endl;
        }
};
class NPCFactory
{
public:
        static NPCFactory& Instance(){
            cout << "call static NPCFactory" <<endl;
            static NPCFactory instance;
            return instance;
        }
        ~NPCFactory(){
            cout << "call ~NPCFactory" <<endl;
        }
        Monster* Create(int npc_id){
            map<int,Monster*>::iterator itr = monsters_.find(npc_id);
            if (itr != monsters_.end()) {
                return itr->second;
            }
            Monster* monster = new Monster(npc_id);
            monsters_.insert({ {npc_id, monster} });
            return monster;
        }
        bool Release(Monster* monster){
            if (monster == nullptr){
                return false;
            }
            int npc_id = monster->NpcID();
            map<int,Monster*>::iterator itr = monsters_.find(npc_id);
            if (itr == monsters_.end()) {
                 return false;
            }
            delete monster;
            monsters_.erase(npc_id);
            return true;
        }
private:
        map<int, Monster*> monsters_;
};
#define testobj MonsterMgr::Instance()
class MonsterMgr
{
public:
        virtual ~MonsterMgr(){
            cout << "call ~MonsterMgr" <<endl;
            for (auto d : monsters_){
                 npc_factory_.Release(d.second);
            }
        }
        Monster* Create(const uint32_t& npc_id)
{
            Monster* monster = npc_factory_.Create(npc_id);
            monsters_.insert(std::make_pair(npc_id, monster));
            return monster;
        }
        static MonsterMgr& Instance(){
            cout << "call static MonsterMgr" <<endl;
            static MonsterMgr npc_mgr;
            return npc_mgr;
        }
private:
        std::map<uint32_t, Monster*> monsters_;
        static NPCFactory&           npc_factory_;       
};
NPCFactory& MonsterMgr::npc_factory_ = NPCFactory::Instance();
int main(){
    testobj.Create(1000);
    return 0;
}

再考虑个问题，如果后边增加一个需求模块，要求这个模块也可以管理怪物类Monster，暂且叫NPCMgr，功能和原来的MonsterMgr类似，此时你觉得应该如何设计此NPCMgr类，留下来思考时间给大家。大家可以关注我的公众号“游戏开发司机” 来留言回复

编辑

你担心大家会滥用的全局变量，大家(包括你自己)一定会滥用

前言

滥用全局变量的危害

滥用全局变量示例

云原生

热门文章

最新文章

相关电子书