核心内容摘要
亚洲“热热色”风情：一场感官的盛宴，一次灵魂的触动
生命周期生命周期分析过几次这里因为讨论这个问题还得再唠叨一下。
所以生命周期就是大家普遍理解的字面意义。
一个变量存在的过程时间段即其从创建到被回收的全过程的时间周期。
生命周期非常重要在C开发中悬垂指针野指针引起崩溃就是生命周期的控制出现了问题。
还有常见的不允许返回局部变量的指针或引用也是基于这个道理。
在C的开发中生命周期的控制有四种类型一种是由系统控制的生命周期即自动存储期一般是栈对象如临时变量另外一种是由开发者自己控制的动态存储期堆对象如普通指针变量还有一种是静态或全局存储期如静态变量最后一种是线程局部存储期如纯种局部变量。
C中的静态变量和全局变量在C开发中静态和全局变量是无法绕开的一个技术点。
一般来说汇总到生命周期上静态变量和全局变量都可以归为静态存储期。
它包括全局变量、普通静态变量、函数内的局部静态变量 和类成员的静态变量。
静态生命周期的变量其生命周期的时间一般与整个程序的生命周期保持一致。
只不过创建的时机根据不同的情况有所不同比如全局变量一般在主函数启动前就已经构建成功在程序退出时被回收退出主函数后而静态变量中的类静态变量在程序启动时创建在程序退出时回收函数内的局部静态变量则在首次调用时被创建也就是前面在单实例中提到的懒汉模式程序退出时回收。
在静态生命周期的变量应用中标准对相关的具体细节的定义和描述并不清晰这就为静态生命周期变量的使用埋下了不少的雷如前面提到的动态库的全局变量依赖问题。
而这种问题往往很难发现和定位这就需要开发者从根本上扫除这种现象的出现来提高代码的健壮性。
问题和分析正如刚刚所说C标准对跨编译单元的静态生命周期的定义并不清晰这就引出了两个重要的问题初始化顺序的问题这个在前面分析过即SIOFconstinit避免SIOF。
在刚刚提到的动态库中的全局变量依赖问题以及不同的编译单元静态变量的互相依赖问题都有可能随机的产生不可预知的问题直到崩溃的发生。
而标准定义的模糊就需要开发者必须清晰的控制静态生命周期的变量的依赖顺序。
保障链接器形成安全稳定的依赖关系。
析构顺序问题析构问题和初始化问题本质是同一类问题。
既然初始化的顺序是无法保证的那么析构的顺序同样也是无法保障的。
这就会产生在相关的静态生命周期变量回收后未回收的静态生命周期变量引用或调用其的情况从而导致类似野指针操作的问题。
还有一个典型的可能崩溃的例子就是显式调用abort()绕过主函数退出则相关静态生命周期的变量无法正常析构。
这就引申出来前面分析过的另外一个问题在全局或静态变量上使用智能指针有可能导致二次释放的崩溃现象。
究其原因都是对顺序的依赖出现了问题。
看一个小例子DemogetDemo(){staticDemo d;returnDemo;}structTest{//省略};staticTest t;//静态变量t和d依赖的顺序不确定可能崩溃再次强调一下C标准中对同一编译单元内的静态生命周期的顺序是可控的即按照定义的顺序先后进行的。
这里分析的问题主要是跨编译单元的说明。
解决方法在明白了上述的问题的根源后就可以有的放矢的解决问题。
在C的编程实践中主要有以下几种将全局部变量统一定义到一个头文件或同个类中集中管理//global.hinta0;intb0;intc0;intdgetValue();intgetValue(){return8;}线程安全推荐使用局部静态变量//下面为一个类静态成员函数Demo*Demo::getInstance(){staticDemo*pInstancenewDemo();returnpInstance;}静态变量只生产不销毁回收//只创建不回收让系统自动销毁staticint*pTestnewint(
;视情况引入智能指针管理静态变量structData{};class SingleIns{public:staticstd::unique_ptrDatagetInst(){staticstd::unique_ptrDatapInsstd::make_uniqueData();returnstd::move(pIns);//此特地使用了unique_ptr可以与shared_ptr对比分析一下}};
五、
总结人们总说“细节决定成败”在这一点上生命周期的应用就可以验证这句话。
悬垂指针的现象估计是多线程开发中每个遇到过的开发者的头大的问题。
这个问题看似只是一个很细小的问题但引发的结果往往让开发者不可捉摸。
这就需要认真的对代码进行分析整理或者使用更好的方法来管理指针来解决这个问题。