c语言中,答案说左边的function会造成内存泄露,右边的function 会造成悬挂指针

c语言中,答案说左边的function会造成内存泄露,右边的function 会造成悬挂指针,第1张

在C语言中,内存,指针是比较重要的两个概念。一般对于内存的 *** 作,我们遵循的原则就是:

成对编程,使用malloc() 和 free()函数要匹配才可以;

free()函数调用之后,赋值NULL给指针变量

这里我分别讲一下左右两个函数的。

左边的代码:

左边代码的问题是在foo()函数中,使用了malloc()函数分配内存,但是在bar()函数中并没有使用free()函数释放掉分配的内存,从而导致内存泄露。内存泄露就是说只要这个程序无线循环的运行,系统的可用内存就会一直变小,直到不能再分配内存程序崩溃为止。这里也很容易理解:因为程序一致在申请内存,而没有释放掉。

因此,左边的代码违背的我所说的规则1

右边的代码:

右边的代码很好的遵循了规则1, 但是遗憾的是,在free(x)之后,使用 return x; 语句返回了x指针。这在c语言中称之为使用了“野指针”。之所以是“野指针”是因为,这个指针指向的内存内存是不确定的,引用这种指针,极有可能会出现无法预知的问题。因此,一般我们会在free(x)之后,做x=NULL;的 *** 作,这样,函数实际上会返回NULL,然后主调函数中先对指针进行判断,就会很好的规避这种问题的发生。

希望上述的解答能够使你明白c中指针的相关知识和内存的 *** 作。

直观地说,就是storecpp的第519行出错了。

但并不一定是说,519行有什么语法错误,也可能根源在此之前。

该警告表明程序在选定点的行为与预期行为不符合。

在程序跟踪调试过程出现此警告,最常见的错误就是引用了不存在的变量或函数,或者变量未经过声明、函数未经定义,又或者把某个局部变量当做全局变量引用。此类错误通常归结为所谓的“野指针”。

另一类可能是编程习惯不严谨,导致的内存泄漏。

查错应首先着手于519行调用了什么,如果是变量或函数,则此变量在之前是否未声明、函数未定义,又或者曾经存在但在519行之前又被删去;如果519行是与创建资源相关,那么资源创建与其特性是否考虑周到。比如,反复创建同一类资源,在前一资源未释放内存条件下又重复创建。如此,可能导致分配的内存很快耗尽,程序崩溃。

一、assertion的作用

assertion用于差错,C++通过assert宏提供断言功能,其功能定义如下:

assert([表达式]);//表达式为假,程序终止在这一行,并报错。

断言是一种判断条件,在程序执行中的特定点条件表达式必须为真。在条件不满足时系统停止程序的执行并报告错误。

C++通过assert宏提供断言功能,要使用assert宏必须包含头文件#include <cassert>

assert要执行一个可以得出true或者false的表达式。通常,关系表达式,逻辑表达式或者返回为bool值的函数都可以用于assert表达式

二、程序在选定点的行为与预期行为不符合,可能的原因包括野指针和内存泄漏

野指针——野指针指向一个已删除的对象或未申请访问受限内存区域的指针。与空指针不同,野指针无法通过简单地判断是否为 NULL避免,而只能通过养成良好的编程习惯来尽力减少。对野指针进行 *** 作很容易造成程序错误。

内存泄漏(Memory Leak)——指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放,造成系统内存的浪费,导致程序运行速度减慢甚至系统崩溃等严重后果。

泄漏原因

在C语言中,从变量存在的时间生命周期角度上,把变量分为静态存储变量和动态存储变量两类。静态存储变量是指在程序运行期间分配了固定存储空间的变量而动态存储变量是指在程序运行期间根据实际需要进行动态地分配存储空间的变量。在内存中供用户使用的内存空间分为三部分:

程序存储区

静态存储区

动态存储区。

程序中所用的数据分别存放在静态存储区和动态存储区中。静态存储区数据在程序的开始就分配好内存区,在整个程序执行过程中它们所占的存储单元是固定的,在程序结束时就释放,因此静态存储区数据一般为全局变量。动态存储区数据则是在程序执行过程中根据需要动态分配和动态释放的存储单元,动态存储区数据有三类函数形参变量、局部变量和函数调用时的现场保护与返回地址。由于动态存储变量可以根据函数调用的需要,动态地分配和释放存储空间,大大提高了内存的使用效率,使得动态存储变量在程序中被广泛使用。

开发人员进行程序开发的过程使用动态存储变量时,不可避免地面对内存管理的问题。程序中动态分配的存储空间,在程序执行完毕后需要进行释放。没有释放动态分配的存储空间而造成内存泄漏,是使用动态存储变量的主要问题。一般情况下,开发人员使用系统提供的内存管理基本函数,如malloc、recalloc、calloc、free等,完成动态存储变量存储空间的分配和释放。但是,当开发程序中使用动态存储变量较多和频繁使用函数调用时,就会经常发生内存管理错误,例如:

分配一个内存块并使用其中未经初始化的内容;

释放一个内存块,但继续引用其中的内容;

子函数中分配的内存空间在主函数出现异常中断时、或主函数对子函数返回的信息使用结束时,没有对分配的内存进行释放;

程序实现过程中分配的临时内存在程序结束时,没有释放临时内存。内存错误一般是不可再现的,开发人员不易在程序调试和测试阶段发现,即使花费了很多精力和时间,也无法彻底消除。

产生方式的分类

以产生的方式来分类,内存泄漏可以分为四类:

常发性内存泄漏:发生内存泄漏的代码会被多次执行到,每次被执行时都会导致一块内存泄漏。

偶发性内存泄漏:发生内存泄漏的代码只有在某些特定环境或 *** 作过程下才会发生。常发性和偶发性是相对的。对于特定的环境,偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。

一次性内存泄漏:发生内存泄漏的代码只会被执行一次,或者由于算法上的缺陷,导致总会有一块且仅有一块内存发生泄漏。

隐式内存泄漏:程序在运行过程中不停的分配内存,但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏,因为最终程序释放了所有申请的内存。但是对于一个服务器程序,需要运行几天,几周甚至几个月,不及时释放内存也可能导致最终耗尽系统的所有内存。所以,我们称这类内存泄漏为隐式内存泄漏。从用户使用程序的角度来看,内存泄漏本身不会产生什么危害,作为一般的用户,根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积,这会最终耗尽系统所有的内存。从这个角度来说,一次性内存泄漏并没有什么危害,因为它不会堆积,而隐式内存泄漏危害性则非常大,因为较之于常发性和偶发性内存泄漏它更难被检测到。

1、野指针的病例:

在画图的时候经常会定义一些画刷啊,画笔啊之类的指针,一般都是这么干的:CPen myPen=new CPen
然后用完后就会来一句:delete myPen,发现程序居然会报错!把这个delete语句删除就没问题了,这是为什么呢?难道不需要释放吗?
而且观察到用来申请内存的new貌似和平常的不一样,是紫色的,就像宏定义一样,但在new上右键又转不到类似宏的定义上去,这又是为什么呢?

已经把画笔还原成了原来的oldPen,但是在最后delete oldPen就会报错,只能改成上面那句oldPen=NULL;

oldPen 是个"pen"  select 回去后, 表示 还回 , 必须是 存在的!
把它delete 掉了就不存在了!
所以不要管 pOldPen(不要=0,不要delete) , 这是个局部变量 ,出函数就没有了。

2、内存泄漏的病例:

非静态内部类创建静态实例造成的内存泄漏

例如,有时候我们可能会在启动频繁的Activity中,为了避免重复创建相同的数据资源,可能会出现如下写法:

public class MainActivity extends AppCompatActivity {
private static TestResource mResource = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
superonCreate(savedInstanceState);
setContentView(Rlayoutactivity_main);
if(mResource == null){
mResource = new TestResource();
}
//
}
class TestResource {
//
}
}

这样在Activity内部创建了一个非静态内部类的单例,每次启动Activity时都会使用该单例的数据。虽然这样避免了资源的重复创建,但是这种写法却会造成内存泄漏。因为非静态内部类默认会持有外部类的引用,而该非静态内部类又创建了一个静态的实例,该实例的生命周期和应用的一样长,这就导致了该静态实例一直会持有该Activity的引用,从而导致Activity的内存资源不能被正常回收。
解决方法:将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例,如果需要使用Context,就使用Application的Context。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/13411044.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-07-31
下一篇 2023-07-31

发表评论

登录后才能评论

评论列表(0条)

保存