局部数组过大导致编译栈区溢出问题

在开始ACM的道路上,很多时候会碰到很大的数据范围,而且要用到数组来进行存储;可能会碰到以下的问题:

#include <stdio.h>

int main()
{
    int n, a[10000005];   //局部
    while(~scanf("%d", &n)) {
        for(int i=0; i<n; i++) scanf("%d", &a[i]);
        for(int i=0; i<n; i++) printf("%d\n", a[i]);
    }
    return 0;
}

编译运行的时候立马出现错误!!!!

不过当时没有深究,旁边的学长只是把数组提到了main函数的前面,然后告诉我,以后要定义很大的数组的时候记得把它定义成全局变量;

Just like that:

#include <stdio.h>

int a[10000005];   //全局

int main()
{
    int n;
    while(~scanf("%d", &n)) {
        for(int i=0; i<n; i++) scanf("%d", &a[i]);
        for(int i=0; i<n; i++) printf("%d\n", a[i]);
    }
    return 0;
}

然后成功编译和运行了!當時覺得好神奇!!

今天刚黑龙江省广东商会嘉年华回来已经累得不行了,才想到把以前很多知识都整理一下:

要解决这个疑问,首先你要明白全部变量和局部变量在内存中是如何存储的:

1、栈区(stack sagment):由编译器自动分配释放,存放函数的参数的值,局部变量的值等。在Windows下,栈是向低地址扩展的数据结构,是一块连续的内存的区域。这句话的意思是栈顶的地址和栈的最大容量是系统预先规定好的,在WINDOWS下,栈的大小是2M(也有的是1M,总之是一个编译时就确定的常数),如果申请的空间超过栈的剩余空间时,将提示overflow。因此,能从栈获得的空间较小。

2、堆区(heap sagment) : 一般由程序员分配释放,若程序员不释放,程序结束时可能由系统回收 。它与数据结构中的堆是两回事。堆是向高地址扩展的数据结构,是不连续的内存区域。这是由于系统是用链表来存储的空闲内存地址的,自然是不连续的,而链表的遍历方向是由低地址向高地址。堆的大小受限于计算机系统中有效的虚拟内存。由此可见,堆获得的空间比较灵活,也比较大。

3、全局区(静态区)(data sagment):全局变量和静态变量的存储区域是在一起的,程序结束后由系统释放。数据区的大小由系统限定,一般很大。

4、文字常量区:常量字符串就是放在这里的, 程序结束后由系统释放。

5、程序代码区:存放函数体的二进制代码。

根據以上的知識,就可以清楚的知道了由於棧區容量很小以致不能存儲過大的局部變量,必定會棧區溢出,而全局變量存儲區將有足夠大的空間存儲棧區不能存儲的局部數組;

时间: 2024-09-30 16:34:13

局部数组过大导致编译栈区溢出问题的相关文章

图片--Android有效解决加载大图片时内存溢出的问题

Android有效解决加载大图片时内存溢出的问题 博客分类: Android Android游戏虚拟机算法JNI 尽量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource来设置一张大图,因为这些函数在完成decode后,最终都是通过java层的createBitmap来完成的,需要消耗更多内存. 因此,改用先通过BitmapFactory.decodeStream方法,创建出一个bitmap,再将其设为ImageView

有效解决Android加载大图片时内存溢出的问题

首先解析一下基本的知识: 位图模式,bitmap颜色位数是1位 灰度模式,bitmap颜色位数是8位,和256色一样 RGB模式,bitmap颜色位数是24位 在RGB模式下,一个像素对应的是红.绿.蓝三个字节 CMYK模式,bitmap颜色位数是32位  在CMYK模式下,一个像素对应的是青.品.黄.黑四个字节 图像文件的字节数(Byte) = 图像分辨率*颜色深度/8(bit/8) 例如:一幅640*480图像分辨率.RGB色一般为24位真彩色,图像未经压缩的数据容量为:640X480X24

(转)关于android中bitmap过大导致的程序crash问题

第一种方法--及时回收bitmap内存: 一般而言,回收bitmap内存可以用到以下代码 if(bitmap != null && !bitmap.isRecycled()){ bitmap.recycle(); bitmap = null; } System.gc(); bitmap.recycle()方法用于回收该bitmap所占用的内存,接着将bitmap置空,最后,别忘了用System.gc()调用一下系统的垃圾回收器. 在这里要声明一下,bitmap可以有多个(以为着可以有多个i

drools规则引擎因为内存泄露导致的内存溢出

进入这个问题之前,先了解一下drools: 在很多行业应用中比如银行.保险领域,业务规则往往非常复杂,并且规则处于不断更新变化中,而现有很多系统做法基本上都是将业务规则绑定在程序代码中. 主要存在的问题有以下几个方面: 1) 当业务规则变更时,对应的代码也得跟着更改,每次即使是小的变更都需要经历开发.测试验证上线等过程,变更成本比较大. 2) 长时间系统变得越来越难以维护. 3) 开发团队一般是由一个熟悉业务的BA(业务分析人员)和若干个熟悉技术的开发人员组成,开发人员对业务规则的把握能力远不及

ORA-00064 processes设置过大导致数据库打不开

processes设置过大导致数据库打不开 在processes设置过大后,可能导致数据库打不开,开启数据库后会报错: SQL> startup ORA-00064: object is too large to allocate on this O/S (1,7746920) SQL> 解决办法: 首先找到pfile位置,然后从pfile启动数据库; startup pfile=$ORACLE_BASE/admin/SID/pfile/init.ora.49201715235' pfile一

分享工作中遇到的问题积累经验 事务日志太大导致insert不进数据

原文:分享工作中遇到的问题积累经验 事务日志太大导致insert不进数据 分享工作中遇到的问题积累经验 事务日志太大导致insert不进数据 今天开发找我,说数据库insert不进数据,叫我看一下 他发了一个截图给我 然后我登录上服务器,发现了可疑的地方,而且这个数据库之前有一段经历 在月初的时候这个数据库曾经置疑过,启动不起来 Could not redo log record (163041:116859:5), for transaction ID (0:-1175226963), on

Hbase写入量大导致region过大无法split问题

最近在线上往hbase导数据,因为hbase写入能力比较强,没有太在意写的问题.让业务方进行历史数据的导入操作,中间发现一个问题,写入速度太快,并且业务数据集中到其中一个region,这个region无法split掉,处于不可用状态.这里描述一整个过程—— 事情的起因:业务方按照userid和商品id作为rowkey前缀,并没有进行hash散列.我当时咨询过业务方,认为:1.业务方式按照oracle的rowid顺序来进行迁移的,相对来说对应到rowkey里面就不会集中化:2.即使出现部分集中的情

[MSSQL]服务器端压力过大导致SSMS异常

登陆SSMS时: 编辑表时: 查看事件无重大异常,查看内存接近98%,360提示进程97%. 会不会以为服务器压力过大导致的? 待MSSQL空闲期间,重启测试.结果重启之后正常.

自己实现strcat函数的功能。(假如字符数组足够大)

#include <stdio.h>#include <string.h> /*自己实现strcat函数的功能.(假如字符数组足够大)*/ void main(){ char str1[100] = "helloworld"; char str2[100] = "world"; int i = 0; int index = strlen(str1); for(i = 0; i <= strlen(str2); i++) { str1[i