如何理解Dotnet的垃圾回收
本篇内容介绍了“如何理解Dotnet的垃圾回收”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
创新互联公司是一家专业提供抚顺企业网站建设,专注与成都做网站、成都网站制作、成都外贸网站建设、H5场景定制、小程序制作等业务。10年已为抚顺众多企业、政府机构等服务。创新互联专业网络公司优惠进行中。
在说垃圾回收之前,先说说两个概念:
托管代码,是由CLR管理的代码
非托管代码,是由操作系统直接执行的代码
在早期C++的时候,内存分配和释放都是由我们手动处理的,而在公共语言进行时CLR中,多了一个垃圾收集器GC,来充当自动内存管理器,完成同样的工作。从此,对于开发人员来说,我们可以不需要用显式的代码来执行内存管理。这样做的好处是明显的:大量相关内存的错误被消除了,比方没有释放对象导致的内存泄露,或试图访问已经释放的对象的内存,等等。
一、回收和管理托管资源
上面说了,垃圾回收GC在Dotnet中是一个自动的内存管理器,是一种机制,用来清理和回收堆内存中未引用的部分。
通常CLR会在这些情况下启动垃圾回收:
需要在堆上分配内存给一个新对象,但没有足够的空闲内存时;
对象被强制Dispose时;
托管堆上已分配对象的内存超过了阀值(这个阀值会动态调整);
调用了GC.Collect方法
这些内容都是基础,了解了非常好,面试时有话可说。不了解也没关系,不会影响做一个好的程序出来。
下面的内容如果能记住,倒是对于程序开发很有帮助。
在Dotnet的垃圾回收机制中,回收器会自行优化并适用于多种方案。但是,我们仍然可以根据运行环境来设置垃圾回收的类型。
Dotnet的CLR提供了下面两种类型的垃圾回收:
工作站垃圾回收
服务器垃圾回收
这两种回收机制,有一定的区别。
工作站回收,主要是为客户端应用设计的,也是程序默认的回收机制。垃圾回收的过程,跑在触发垃圾回收的用户线程上,并使用相同的优先级。这种方式,优点是不会被挂起或延迟,缺点是需要与其它线程竞争CPU时间。当运行环境中只有一个CPU时,系统会自动采用工作站方式,不管你设置成什么。
服务器回收,针对的是高吞吐的服务器应用,回收过程跑在专用的高优先级线程上,而且默认是多线程在跑,所以效率更高,缺点是占用的资源会更多,而且由于线程之间的干扰和上下文切换,会影响整体性能。
所以,选择什么样的回收机制,需要认真分析。通常普通应用,工作站回收就好。如果是服务器端的API服务,需要选择服务器回收。而如果是在服务端需要启动多个实例进行处理,比方对总线的数据保存,那还是工作站回收好。
设置垃圾回收方式,在开发时,可以在xxx.csproj文件中加入:
true
其中,设置true就是服务器模式,设置false就是工作站模式,当然,去掉这一行,默认也是工作站模式。
对于生产环境中已经上线的应用,也可以修改回收模式。找到程序目录中的xxx.runtimeconfig.json文件,在里面加入:
"configProperties": { "System.GC.Server": true }
这两个配置的关系是:如果开发时在.csproj中加入了ServerGarbageCollection,那在发布时会自动在.runtimeconfig.json中加入System.GC.Server。
二、回收和管理非托管资源
上面说到的回收机制,针对的是托管资源。
对于非托管资源,GC不会主动进行回收。回收非托管资源,只能手工编写代码并显式的释放。
通常来说,程序中用到的操作系统的资源文件、网络或数据库连接等,都属于非托管资源,需要手工清理。
有两种方法可以清理非托管理资源:
使用终结器Finalize,并由GC回收
手动处理Dispose
2.1 使用终结器Finalize
终结器Finalize是System.Object的一个虚方法,这个方法在GC回收对象的内存之前由垃圾回帐调用。我们可以重写这个方法,来释放非托管资源。
多说两句:似乎MS对这个部分有些犹豫,所以这儿规则一直处在两可之间。C#在析构函数的支持上并不严格。System.Object支持重写Object.Finalize方法,但它创建的类却不支持,重写会报错,而只能通过改写析构函数来实现,并由编译器将代码包装在try块中的析构函数或重写的Finalize中,并由finally调用Object.Finalize来实现。
使用终结器,缺点也是比较明显的。GC检测到一个对象需要回收时,会在一段不确定的时间之后调用终结器。这个不确定很讨厌,我们很难预料什么时候对象被实际释放。
Finalize虽然看着是手动清除非托管资源,其实还是由垃圾回收器去做的。它的最大作用是确保非托管资源一定被释放。
2.2 手动处理Dispose
手动处理最重要的理由,是在需要的时候立即释放,而不是让垃圾回收器进行不确定延时后的释放。
手动释放,主要的工作是提供一个IDisposable.Dispose的实现,来实现非托管资源的确定性释放。这样,当需要释放时,调用Dispose方法,就会立即释放非托管资源。
手动处理实现起来很简单。框架提供了一个接口System.IDisposable:
public interface IDisposable { void Dispose(); }
他只包含一个方法Dispose。使用时,需要实现这个方法,在使用完成后及时释放非托管资源。
同时,Dispose方法还提供了GC.SuppressFinalize方法,来告诉GC对象已经被手动处理,不再需要调用终结器。
public void Dispose() { GC.SuppressFinalize(this); }
这种方式下,对象的内存可以做到提前回收。
在某些情况下,可能无法调用IDisposable.Dispose方法来释放非托管资源,但场景下又确实需要确定性地释放,这时候可能通过重写Object.Finalize来实现:
public class MyClass { ~MyClass() { //TODO: 释放未托管的资源 } }
有点奇怪,是不是?
其实,这就是上边我说MS犹豫的地方。如果你直接重写Object.Finalize,像下面这样:
public class MyClass { protected override void Finalize() { //TODO: 释放未托管的资源 } }
编译时会报错Do not override object.Finalize. Instead, provide a destructor.,而他正确的写法,就是析构函数。
上面说的内容,做成一个套路模板,就会是这样的:
public class MyClass : IDisposable { private bool disposedValue; protected virtual void Dispose(bool disposing) { if (!disposedValue) { if (disposing) { // TODO: 释放托管状态(托管对象) } // TODO: 释放未托管的资源(未托管的对象)并替代终结器 // TODO: 将大型字段设置为 null disposedValue = true; } } ~MyClass() { Dispose(disposing: false); } public void Dispose() { Dispose(disposing: true); GC.SuppressFinalize(this); } }
如果你看到了这儿,建议把上面这个套路模板存下来。这算是最完整的一个版本,网上能找到的,大多是简化版。
其实,我们经常使用的很多类,都实现了IDisposable接口。比如说,凡是可以用using来进行调用类,就都实现了IDisposable接口。另外有一些类,把Dispose改成了一个别的名字,比方IO里的Close方法,就是一个Dispose。
另外,如果对象实现了IDisposable接口,而我们直接new了这个对象,那在使用结束后,我们就需要Dispose这个对象。因为既然设计者选择了Dispose,那结束时调用Dispose就是正确的。
三、总结
最后做个简单的总结。
垃圾回收模式选择:应用程序可分配的资源少,或者能够竞争到的资源少,就使用工作站模式,反之就使用服务器模式。
在回收处理上,托管资源就扔给GC自动处理,非托管资源需要手动处理:
其中:
Finalize是标记出非托管资源可被回收,然后由GC去执行回收工作
Dispose是直接调用,并即时回收。
“如何理解Dotnet的垃圾回收”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站,小编将为大家输出更多高质量的实用文章!
文章题目:如何理解Dotnet的垃圾回收
转载来源:http://hbruida.cn/article/gpoogs.html