关于Managed Thread Stack 内存占用
2012-07-14 18:36
211 查看
CLR会通过VirtualAlloc预先提交整个栈,提交之后就立即占用物理空间(物理内存或磁盘)。也许你会发现查看内存占用的时候看起来并没有占用那么多内存,那是因为线程栈一般很少用到1M内存的全部,提交内存在未被使用之前并不会真正分配。看看我的内存截图:
提交数内和已用内存并不相等,因为很多提交内存并未真正分配出去。
那是不是就真的不占用内存了?看下面有看了3000个线程,在继续加就OutOfMemory了。
看以看出虽然并没有使用完物理内存,但将物理内存“预订“下了,这块物理内存也无法干其他用了。
看以看到真实分配了1G内存,而工作集只有56M。
在这儿看来分配磁盘虚拟物理内存也是很有必要的,想我这样完全关闭磁盘虚拟地址就很大程度的浪费内存了
。
在做full dump的时候dump文件往往要比实际Working Set 大,有时候出奇的大很多,尤其线程数多的进程,dump完了后内存占用也蹭的涨起来了,我想可能是dump了整个已提交地址空间。
就算64下虚拟地址空间足够用,但物理地址空间是很有限的,还得控制一下提交量啊,别占着茅坑不拉屎,明明有内存还OutOfMemory。。。
提交数内和已用内存并不相等,因为很多提交内存并未真正分配出去。
那是不是就真的不占用内存了?看下面有看了3000个线程,在继续加就OutOfMemory了。
看以看出虽然并没有使用完物理内存,但将物理内存“预订“下了,这块物理内存也无法干其他用了。
看以看到真实分配了1G内存,而工作集只有56M。
在这儿看来分配磁盘虚拟物理内存也是很有必要的,想我这样完全关闭磁盘虚拟地址就很大程度的浪费内存了
。
在做full dump的时候dump文件往往要比实际Working Set 大,有时候出奇的大很多,尤其线程数多的进程,dump完了后内存占用也蹭的涨起来了,我想可能是dump了整个已提交地址空间。
就算64下虚拟地址空间足够用,但物理地址空间是很有限的,还得控制一下提交量啊,别占着茅坑不拉屎,明明有内存还OutOfMemory。。。
相关文章推荐
- 关于一个程序占用的内存区
- 关于关闭TAB,IFRAME占用的内存不能释放问题
- 关于Android应用内存占用查看及优化
- 关于fielddata数据占用内存过大的解决方法
- MYSQL 内存报错 Use 'mysqld --thread_stack=#' to specify a bigger stack.
- 关于64位操作系统,应用程序占用内存飙升的问题解决方法记录
- 关于android系统内存占用超过80%的解决方法!有问题先百度~吼吼
- 关于电脑DLL占用内存 和 空间!
- 关于释放ASPNET进程的内存占用问题.
- 关于Android中图片大小、内存占用与drawable文件夹关系的研究与分析
- 关于内存的分配问题.bss.data .text .rodata HEAP STACK
- 关于MappedByteBuffer占用内存和文件关闭
- 关于Android中图片大小、内存占用与drawable文件夹关系的研究与分析
- 关于动态链接库占用内存的思考
- 关于Android中图片大小、内存占用与drawable文件夹关系的研究与分析
- 关于C语言中一,二级指针函数中的使用和c语言中和函数发生调用时,实参和形参都会占用内存吗?
- 讨论关于Java占用内存的研究
- 关于MSSQL占用过多内存的问题
- 关于Java占用内存的研究
- 关于内存占用和运行性能的关系