我有下面的课。
public class Foo
{
private string _DirName;
private FileStream _MyfileStream;
public FileStream MyfileStream
{
get { return _MyfileStream; }
}
public string DirName
{
get { return _DirName; }
set
{
_DirName = value;
_MyfileStream = new FileStream(value, FileMode.Create);
}
}
}
我创建了一个Foo列表,如下所示:
List<Foo> FooList = new List<Foo>();
FooList.Add(new Foo() { DirName = @"F:\sample\sample.txt" });
FooList.Add(new Foo() { DirName = @"D:\sample\file.pdf" });
因此,每个列表项都在创建一个文件流。因此,流的数量随着列表项数量的增加而增加。如何为这些流分配内存?
可能Foo
应该实现IDisposable
。然后,您可以迭代该dublist
,并在不再需要时对每个项目调用Dispose
。
所有Foo对象及其打开的流都将保留在内存中,不会被垃圾收集,而傻瓜对象仍然可以从应用程序中的任何点访问。例如,如果傻瓜是一个静态成员变量,或WinForm中的一个实例成员变量,则情况就是这样。
另一方面,如果愚人主义是方法中的局部变量,那么一旦该方法存在,愚人主义将不再是可访问的,列表和Foo对象迟早会被垃圾收集。我敢肯定你的溪流也会被垃圾收集。它们将通过终结器自动关闭。
在大多数情况下,使用显式Dispose方法是可选的。通常,Dispose用于确定地释放共享资源,例如文件流、打开的网络端口等。需要Dispose的类通常从终结器调用Dispose,以确保在垃圾收集时进行清理(如果开发人员/程序之前没有这样做)。但是,在Foo类中打开文件流不会阻止它们被垃圾收集。
此外,请听CodeCaster和M.kazem,如果不立即使用,请不要立即打开流。这只是消耗资源和不必要地锁定文件。
当垃圾收集器运行并释放内存时,内存会返回操作系统还是作为进程的一部分保留下来。我的强烈印象是,内存实际上从未释放回操作系统,而是作为内存区域/池的一部分保留下来,供同一进程重复使用。 因此,进程的实际内存永远不会减少。提醒我的一篇文章是这样的,Java的运行时是用C/C写的,所以我想同样的事情也适用? 更新< br >我的问题是关于Java的。我提到C/C是因为我假设Java的分配/释放是由JRE
问题内容: 有人问我这个问题: 根据以上详细信息,在以下代码的println语句之前创建了多少String对象和多少参考变量? 我的回答是,此代码片段的结果是spring winter spring summer 有两个参考变量s1和s2。总共创建了八个String对象,如下所示:“ spring”,“ summer”(丢失),“ spring summer”,“ fall”(丢失),“ spri
问题内容: 就我的理解而言,finalize()和GC是两个不同的方面。GC使用finalize()方法释放对象内存。我们无法声明何时发生GC(即使我们显式调用System.gc())。但是我们可以在对象上显式调用finalize()。 同样,按照docs,对于任何给定对象,Java虚拟机都不会多次调用finalize方法。 因此,当我们先调用finalize()且GC在以后的时间点发生时,会发生
问题内容: 当垃圾收集器运行并释放内存时,该内存将返回操作系统,还是作为进程的一部分保留。我印象深刻的是,该内存实际上从未释放回OS,而是保留为内存区域/池的一部分,以供同一进程重用。 结果,进程的实际内存将永远不会减少。一篇使我想起的文章是Java的Runtime是用C / C ++编写的,所以我想同样的事情适用吗? 更新 我的问题是关于Java的。我之所以提到C / C ++,是因为我假设Ja
我正在为我的应用程序使用GC选项。 由于大多数人都已经体验过JVM擅长将堆增加到最大堆大小,但它不会将内存释放回操作系统。我遇到了