vb.net虚拟内存 虚拟内存命令

VB.net2000的自动垃圾回收机制到底管用么???????!!!!

分类: 电脑/网络 程序设计 其他编程语言

创新互联专业为企业提供邳州网站建设、邳州做网站、邳州网站设计、邳州网站制作等企业网站建设、网页设计与制作、邳州企业网站模板建站服务，十年邳州做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

问题描述:

别跟我说VB2000自动释放内存,曾经深信这句话的我,如今已是伤痕累累,好几个大项目都差点毁在vb的内存问题上,C#我倒不知道..VB的回收内存速度太慢了,这只是保守的说,其实本人认为它根本不会回收内存.就算全部用上gc.collet也回收不了,而且越用越慢

在使用我的项目的时候,随着窗口的开开关关\控件的调用,内存一直飙,从14MB左右一路疯狂飙高,40分钟系统就崩溃了...上了补丁的XP可以不死机,但就定着不动了..如果虚拟内存文件大,可以维持到撑满,但录一条记录平均要等一个小时!!!!!!!,后来我学乖了开始nothing全局变量(工作量惊人...),结果内存开始有下走的现象(原来是一路向上..只占不放)但内存还是呈曲线上飙,40分钟到200多MB,于是我开始释放局部变量,在每个方法中都要释放!!!!!!!!!!!!!!!!!!!!!,而且还要区分哪些是引用!痛苦啊!!!

...结果三个月之后,满面憔悴的我终于发现内存接近正常了,虽然还不是释放的很干净,但能保证在一段时间内不会崩溃了..至少客户做的时候没再提过意见...我并没有优化什么代码,只是痛苦的释放了一些全局和局部变量,结果内存就不消耗的那么厉害了,你说奇怪不奇怪..但内存始终不是释放的那么干净,我算过了一分钟内曲线飙高2MB左右,有时更多照这样一来,真是早死不如晚死,想想将来还不如用java重新做呢...各位可怜可怜我吧,有什么好主意整理vb2000的内存的好东东,就告诉我吧!!!!!!!!!!我真的受不了了!!!!!有没有什么方法可以重新分配内存呢,就算会造成页中断我也在所不惜!!!!

另外Me.Refresh()是什么意义,能释放内存么?

解析:

很简单，你没有正确理解VB的内存自动回收机制，仔细看一下MSDN，好好研究一下相关的内容。其实JAVA的内存自动回收机制与VB是类似的，如果你用VB.NET做不好，换用JAVA照样做不好。

其实，你已经发现了为什么内存不能回收，只是你没意识到罢了。

为什么要用全局变量呢？给你举个极端的例子吧：建立一个全局的Hashtable，然后将程序中创建的每一个对象实例加入到这个hashtable中，那么你将看到内存一直猛增，直到崩溃。

正确的作法是：

1、尽量不用、少用全局变量和静态变量

2、如果没有必要，就不要把对象实例加到全局或静态的Hashtable、ArrayList之类的 *** 中去，除非你是想自己建立一个对象缓冲池

3、如果你自己要建立对象缓冲池，就一定要注意对象的清理，尽早将不用的对象从池中删除

4、找本好一点的数据结构，仔细学学其中关于自动内存回收的那几种机制，以后在程序中不要违反它们的要求前提条件。

VB.NET窗体内容很多,会不会导致窗体最小化后在还原时很卡？

不会卡的，体一显示已经加载到内存了，所以最小化还原是一定不会卡的

不过窗体内容太多会导致以后修改时查找不方便

建议把不同项目分别写在模块中

vb.net操作数据库的效率问题

select * from XXX 如果数据量少还可以，如果数据量一大，需要从适配器在读取到Dataset中，这个是相当耗时的。

其实，有一些程序可以采用 分段读取，多次读取。

像这样的写法，更新一条数据，就需要在重新读取所有的数据。。耗费太大资源和贷款。。

客户端也会导致很慢甚至读取数据假死。。

-----------------------------

最好的方式不管你用DataRead还是什么，这些都根本解决不了这些问题。

你需要做的就是 如何高效读取/处理数据。

BS 结构，可以采用异步加载数据和处理数据

CS结构 异步加载和分段读取数据。而不是一下子就把所有数据加载处理。这样的话，CPU和内存占用率就会抬高。。。。

---------------------------------

之前公司采用的方式就是这样的，DataSet和Fill

后来发现不好，于是就采用异步，服务器压力减少，客户端满意度提高。。

如何在.net应用中发现和避免内存和资源泄露

尽管很多人相信在.net应用中谈及内存及资源泄露是件很轻松的事情。但GC(垃圾回收器)并不是魔法师，并不能把你完全从小心翼翼处理内存与资源损耗中解放出来。

本文中我将解释缘何内存泄露依然存在以及如何避免其出现。别担心，本文不涉及GC内部工作机制及其它.net的资源及内存管理等高级特性中。

理解泄露本身及如何避免其出现很重要，尤其因为它无法轻松地自动检测到。单元测试在此方面无能为力。一旦产品中你的程序崩溃了，你需要马上找出解决方案。所以在一切都还不是太晚前，花些时间来学习一下本文吧。

Table of Content

· 介绍

· 泄露？资源？指什么？

· 如何检测泄露并找到泄露的资源

· 常见内存泄露原因

· 常见内存泄露原因演示

· 如何避免泄露

· 相关工具

· 结论

· 资源

介绍

近期，我参与了一个大的.net项目(暂叫它项目X吧)，我在项目中负责追踪内存与资源泄露。大部分时间我都花在与GUI关联的泄露上，更准确地说是一个基于Composite UI Application Block (CAB).的windows窗体应用。接下来我要说的直接应用到winform上的内容，多数见解同样可以适用到其它.net应用中(像WPF,Silverlight,ASP.NET,Windows service,console application 等等)。

我不是个处理泄露方面的专家，所以我不得不深入钻研了一下应用程序，做一些清理工作。本文的目标是与你们分享在我解决问题过程中的所得所悟。希望能够帮助那些需要检测与解决内存、资源泄露问题的朋友。下面的概述部分首先会介绍什么是泄露，之后会看看如何检测到泄露和被泄露资源，以及如何解决与避免类似泄露，最后我会列出一个对此过程有帮助的工具列表及相关资源。

泄露？资源？指什么？

内存泄露

在进一步深入前，让我们先来定义下我所谓的“内存泄露”。简单引用在Wikipedia上找到的定义吧。该定义与我打算通过本文所帮助解决的问题完美的一致：

在计算机科学领域中，内存泄露是指一种特定的内存损耗，该损耗是由一个计算机程序未成功释放不需要的内存引起的。通常是程序中的BUG阻碍了不需要内存的释放。

仍然来自Wikipedia:”以下语言提供了自动的内存管理，但并不能避免内存泄露。像 Java,C#,VB.NET或是LISP等。”

GC只回收那些不再使用的内存。而使用中的内存无法释放。在.net中，只要有一个引用指向的对象均不会被GC所释放。

句柄与资源

内存可不是唯一被视为资源的。当你的.net应用程序在Windows上运行时，消耗着一个完整的系统资源集。微软定义了系统三类对象：用户(user)，图形设备接口(GUI),以及系统内核(kernel)。我不会在此给出完整的分类对象列表，只是指出一些重要的：

· 系统通过使用用户对象(User objects) 来支持windows管理。相关对象包括：提速缓冲表(Accelerator tables),Carets(补字号？),指针(Cursors),钩子(Hooks),图标(Icons),菜单(Menus)和窗体(Windows)。

· GDI对象 支持图形绘制：位图(bitmaps),笔刷(Brushes),设备上下文(DC),字体(Fonts),内存设置上下文(Memory DCs),元文件(Metafiles),画笔(Pens),区域(Regions)等。

· 内核对象 支持内存管理，进程执行和进程间通讯(IPC)：文件，进程，线程，信号(Semaphores),定时器(Timer)，访问记号(Access tokens),套接字(Sockets)等。

所有系统对象的详细情况都可以在MSDN中找到。

系统对象之外，你还会碰到句柄(handles).据MSDN的陈述，应用程序不能直接访问对象数据或是对象所代表的系统资源。取而代之，应用程序一定都会获得一个对象句柄(Handle)，可以使用它检查或是修改系统资源。在.net中无论如何，多数情况下系统资源的使用都是透明的，因为系统对象与句柄都由.net类直接或间接代表了。

非托管资源

像系统对象(System objects)这样的资源自身都不是个问题，但本文仍涵盖了它们，因为像Windows这样的操作系统对可同时打开的 套接字、文件等的数量都有限制。所以关注应用程序所使用系统对象的数量非常重要。

在特定时间段内一个进程所能使用的User与GDI对象数目也是有配额的。缺省值是10000个GDI对象和10000个User对象。如果想知道本机的相关设置值，可以使用如下的注册表键：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows: GDIProcessHandleQuota 和 USERProcessHandleQuota.

猜到了什么？确实没有这么简单，还有一些你会很快达到的其它限制。比如参照：我的一篇有关桌面堆的博客 所述。

假设这些值是可以自定义的，你也许认为一个解决方案就是打破默认值的限制—调高这些配额。但我认为这可不是个好主意，有如下原因：

1． 配额存在的原因：系统中不是只有你独自一个应用程序，所有运行在计算机中的其它进程与你的应用应该分享系统资源。

2. 如果你修改配额，使它不同于其它系统了。你不得不确认所有你的应用程序需要运行的机器都完成了这样的修改，而且这样的修改从系统管理员的角度来说是否会有问题也需要确认。

3. 大部分都采用了默认配额值。如果你发现配置值对你应用程序来说不够，那你可能确实有些清理工作要做了。

如何检测泄露及找到泄露的资源

泄露带来的实际问题在MSDN上的一篇文章中有着很好的描述：

哪怕在小的泄露只要它反复出现也会拖垮系统。

这与水的泄露异曲同工。一滴水的落下不是什么大问题。但是一滴一滴如此反复的泄露也会变为一个大问题。

像我稍后解释的，一个无意义的对象可以在内存中维持一整图的重量级对象。

仍然是同一篇文章，你会了解到：

通常三步根除泄露：

1.发现泄露

2.找到被泄露的资源

3.决定在源码中何时何处释放该资源

最直接“发现”泄露的方式是遭受泄露引发的问题

你或许没有见过内存不足。“内存不足”提示信息极少出现。因为操作系统运行中实际内存(RAM)不足时，它会使用硬盘空间来扩展内存。（称为虚拟内存）。

在你的图形应用程序中可能更多出现的是“句柄不足”的异常。准确的异常不是System.ComponentModel.Win32Exception 就是 System.OutOfMemoryException 均包含如下信息：”创建窗体句柄错误”。这两个异常多发于两个资源被同时使用的情况下，通常都因为该释放的对象没有被释放所致。

另外一种你会经常碰到的情况是你的应用程序或是整个系统变更得越来越慢。这种情况的发生是因为你的系统资源即将耗尽。

我来做个生硬的推断：大多数应用程序的泄露在多数时间里都不是个问题，因为由泄露导致出现的问题只在你的应用程序集中使用很长时间的情况下才会出现。

如果你怀疑有些对象在应该被释放后仍逗留在内存中，那需要做的第一件事就是找出这些对象都是什么。

这看起来很明显，但是找起来却不是这样。

建议通过内存工具找到非预期逗留在内存中的高级别对象或是根容器。在项目x中，这些对象可能是类似LayoutView实例一样的对象们(我们使用了MVP(Model View Presentation )模式)。在你的实际项目中，它可能依赖于你的根对象是什么。

下一步就是找出它们该消失却还在的原因。这才是调试器与工具能真正帮忙的。它们可以显示出这些对象是如何链接在一起的。通过查看那些指向“僵尸对象”（the zombie object）的引用你就可以找到引起问题的根本原因了。

你可以选择 ninja方式（译者:间谍方式？）(参照 工具介绍章节中有关 SOS.dll 和 WinDbg 的部分)。

我在项目X中用了JetBrains的dotTrace,本文中我将继续使用它来介绍。在后面的工具相关章节中我会向你更多的介绍该工具。

你的目标是找到最终引起问题的那个引用。不要停留在你找到的第一个目标上，但是也要问问自己为什么这个家伙还在内存中。

常见内存泄露的原因

上面提到的泄露情况在.net中较常见。好消息是造成这些泄露的原因并不多。这意味着当你尝试解决一个泄露问题时，不需要在大量可能的原因间搜寻。

我们来回顾一下这些常见的罪魁祸首，我把它们区别开来：

· 静态引用

· 未注销的事件绑定

· 未注销的静态事件绑定

· 未调用Dispose方法

· Dispose方法未正常完成

除了上列典型的原因外，还有些其它情况也可能引发泄露：

· Windows Forms:绑定源滥用

· CAB:未移除对工作项的调用

我只列出了可能在你应用程序中出现的一些原因，但应该清楚你的应用程序依赖的其它.net代码、库实际使用中也可能引发泄露。

我们来举个例子。在项目x中，使用了一套第三方控件来构造界面。其中一个用来显示所有工具栏的控件，它管理着一个工具栏列表。这种方式没什么，但有一点，即使被管理的工具栏自身实现了IDisposable接口，管理类却永远也不会去调用它的Dispose方法。这是一个bug.幸运的是这发生在一个很容易发现的工作区：只能我们自身来调用所有工具样的Dispose方法了。不幸的是这还不够，工具栏类自身问题也不少：它并没有释放自身承载的控件（按钮，标签等等）。所以在解决方案中还要添加对每个工具栏中控件的释放，但是这次可就没那么简单了，因为工具栏中的每个子控件都不同。不管怎么样这只是一个特殊的例子，我要表达的观点是你应用程序中使用的任何第三方库、组件都可能引发泄漏。

最后，还有一种由.net framework造成的泄露，由一些不好的使用习惯引起。即使.net framework自身可能引发泄露,但这是你极少会遭遇到的情况。把责任推到.net身上很容易，但在我们把问题推到别人头上前，还是应该先从自身写的代码出发，看看里面有没有问题。

常见泄露演示

我已经列举出了泄露主要的来源，但我还不想仅限于此。如果每个泄露我都能举个鲜活的例子的话，我想本文会更实用些。好，我们先启动Vs 和 dotTrace ， 然后看些示例代码。我会同时演示如何解决或是避免每个泄露情况。

项目X中使用了CAB和MVP模式，这意味着界面由工作空间、视图和呈现者组成。简单起见，我决定使用包含一组窗口的Winform应用。其中使用了与Jossef Goldberg的一篇关于“Wpf应用程序内存泄露”文章中相同的方法。甚至我会直接把相同的例子和事件处理函数应用到我的Winform App中。