Bri*_*sen 39 .net memory clr4.0
据我所知,.NET中的单个实例有2 GB的限制.我没有太多关注,因为到目前为止我主要使用32位操作系统.在32但它或多或少是一个人为的限制.但是,我很惊讶地发现这个限制也适用于64位.NET.
由于诸如List<T>使用数组来存储项目之类的集合,这意味着与在64位上运行的相同应用程序相比,在32位上运行的.NET应用程序将能够在列表中保存两倍的引用类型项.这非常令人惊讶.
有谁知道这个限制是否在CLR 4.0中得到解决(目前我手头没有安装4.0).
Ree*_*sey 53
它比那更糟 - 你是处理空间,当你在.NET中工作时,32位远小于理论极限.在32位.NET应用程序中,我的经验是你总是倾向于在大约1.2-1.4gb的内存使用量内开始出现内存错误(有些人说他们可以达到1.6 ......但我从未见过).当然,这在64位系统上不是问题.
话虽这么说,一个2GB的参考类型阵列,即使在64位系统上,也是一个庞大的对象.即使使用8字节引用,您也可以分配268,435,456个对象引用的数组 - 每个引用都可以非常大(最多2GB,如果它们使用嵌套对象则更多).这比大多数应用程序真正需要的内存更多.
CLR团队的一名成员在博客上发表了关于此问题的博客,并提供了一些解决这些限制的方法.在64位系统上,像BigArray <T>这样的东西将是一个可行的解决方案,可以将任意数量的对象分配到一个数组中 - 远远超过2gb的单个对象限制.P/Invoke也允许您分配更大的数组.
编辑:我也应该提到这一点 - 我不相信这种行为在.NET 4中完全没有改变.自.NET开始以来,这种行为一直没有改变.
编辑:.NET 4.5现在可以在x64中通过在app.config中设置gcAllowVeryLargeObjects来显式允许对象大于2gb.
小智 16
.NET Framework 4.5允许在64位平台上创建大于2GB的数组.默认情况下,此功能未启用,必须使用gcAllowVeryLargeObjects元素通过配置文件启用此功能.
http://msdn.microsoft.com/en-us/library/hh285054(v=vs.110).aspx
| 归档时间： |
|
| 查看次数： |
24259 次 |
| 最近记录： |