不用程序员操心的堆 — 托管堆
c++
程序在计算机上跑着,就不免会占用内存资源来存储在程序运行过程当中的数据,咱们按照内存资源的存取方式将内存划分为堆内存和栈内存。程序员
栈内存,一般使用的场景是:对存取速度要求较高且数据量不大。sql
典型的栈内存使用的例子就是函数栈,每个函数被调用时都会被分配一块内存,这块内存被称为栈内存,以先进后出的方式存取数据,在函数执行过程当中不断往函数栈中压入(PUSH)数据(值类型数据:int、float、对象的引用...),函数执行完后又将函数栈中的数据逐个弹出(POP),因为是以操做栈的形式来存取,因此访问速度快。数据库
堆内存,从字面意思上理解就好像是仓库里面能够存一堆破烂,你如果须要存点什么东西就尽管往里面一扔,仓库里有的是空间。事实确实也是如此,堆内存中能够存放大规格的数据(好比对象资源),这些数据是不适合存放在栈中的,由于栈空间的容量有限,这就是堆内存相对于栈内存的好处:容量大。可是它的缺点也是显而易见的,那就是存取堆内存的数据相较于存取栈内存是很是慢的,试想一下,让你在仓库里的一堆破烂里去找你想要的东西是什么感受。c#
(栈内存比堆内存详细参考:https://blog.csdn.net/boyxiaolong/article/details/8543676)函数
从内存分配方式上看,堆内存不一样于栈内存,函数栈是在每个函数被执行的时候被自动分配而且函数执行完成后自动回收,而若是你想使用堆内存,就得本身动手丰衣足食。优化
因此你会看到c语言程序员会这样去使用堆内存:this
int *p = (int*)malloc(sizeof(int)); //在堆内存中申请一块字节数为int字节数的堆内存,并返回指向该内存区域的指针 *p = 10; free(p); //释放堆内存资源
你还会看见c++程序员这样写:spa
Car* bmw = new Car(); //建立一个Car类对象,在堆内存中存放对象数据,并返回指向对象资源的指针 delete bmw; //释放堆内存资源
固然,没有接触过c/c++的小伙伴也不用惊慌,上面只不过是想让你知道在c/c++语言中,程序员要是想使用堆内存,那就必须显式地编写分配和释放堆内存资源的代码。操作系统
有人问:使用完堆内存资源后没有手动释放它会有什么后果吗?
答案是:因为堆内存资源使用者未及时释放内存会致使内存没法再次使用,从而形成内存资源的泄漏(浪费)。
就在这个时候,c#程序员笑了,只见他的手指很是轻盈优雅地在屏幕上敲出了下面这行代码:
Car bmw = new Car();
一旁围观的c程序员和c++程序员惊呆了,他们不知道本身在敲代码的时候有没有像这样轻松过。c++程序员用手抚摸着他那锃光瓦亮的额头,忽然眼睛里闪着光,喊道:“你尚未释放堆内存的资源呢,你这样是很危险的,会内存泄漏的,快,把释放堆内存的代码写上!”
c#程序员彷佛并不为所动,舒舒服服地靠在椅子上,用余光瞟了c++程序员一眼,说:“不用慌,不用慌,这个对象在托管堆上放的好好的呢,不用我操心”,因而,c#程序员便娓娓道来(呼呼大睡)...
在.NET的世界,使用new关键字建立一个对象,首先对象资源被分配在托管堆中,而后new会返回一个指向堆上对象的引用,而不是真正的对象自己。若是在方法做用域中将引用变量声明为本地变量,这个引用变量保存在栈内,以供应用程序之后使用。
托管堆,顾名思义,就是托给别人管的堆,那么是谁在管理着这个堆上的对象资源呢?
答案是:CLR(Common Lanauage Runtime),对象的实例化结束之后,GC(垃圾回收器)将会在对象再也不须要时将其销毁。
也就是说,经过容许垃圾收集器负责销毁对象,内存管理的麻烦就都交给CLR了,万事大吉。
看似问题好像都已水落石出,无非就是将堆内存资源回收交给了CLR去承担。难道你就不想知道的更多一点?好比接着而来的问题:
1、垃圾回收器如何判断一个对象何时再也不须要?
二、垃圾回收器又在何时会执行垃圾清理的操做?
别急,带着问题慢慢往下看。
c#中的new关键字最终会被编译器翻译成CIL的newobj指令,让咱们仔细查看一下CIL newobj指令的做用。
首先,须要明白托管堆不只仅是一个可由CLR访问的随机内存块。.NET垃圾回收器是堆的“清洁工”,出于优化的目的它会压缩空闲的内存块(当须要时)。为了辅助压缩,托管堆会维护一个指针(一般被叫作下一个对象指针或者是新对象指针),这个指针用来标识下一个对象在堆中分配的地址。
此外,newobj指令通知CLR来执行下列的核心任务:
(1)计算要分配的对象所需的所有内存(包括这个类型的数据成员和类型的基类所需的内存)。
(2)检查托管堆来确保有足够的空间来放置所申请的对象。若是有足够的空间,会调用这个类型的构造函数,构造函数会返回一个指向内存中这个新对象的引用,这个新对象的地址恰好就是下一个对象指针上一次所指向的位置。
(3)最后,在把引用返回给调用者以前,让下一个对象指针指向托管堆中下一个可用的位置。
下面的图解释了在托管堆上分配对象的细节。
在c#中分配对象是一个很频繁的操做,照这样下去托管堆上的空间早晚会被挥霍完,因此,重点来了,若是CLR 发现托管堆没有足够空间分配请求的类型时,它会执行一次垃圾回收来释放内存。
当执行垃圾回收时,垃圾收集器临时挂起当前进程中的全部的活动线程来保证在回收过程当中应用程序不会访问到堆。(一个线程是一个正在执行的程序中的执行路径)。一旦垃圾回收完成,挂起的线程又能够继续执行了。还好,.NET 垃圾回收器是高度优化过的,因此用户不多能察觉到应用程序中的短暂中断。
经过对CIL的new指令做用的解读,咱们知道了:若是托管堆没有足够的空间分配一个请求的对象,则会执行一次垃圾回收。
(讲到这里c#程序员停了下来,喝了口保温杯里的枸杞红枣大补茶🍵,清了清嗓子,继续开始解惑...)
应用程序根的做用 — 区分不可到达的对象
如今让咱们来讨论一下垃圾回收器怎样肯定何时“再也不须要”一个对象。为了理解细节,你须要知道应用程序根的概念。
简单来讲,一个根是一个引用,这个引用指向堆上面的一个对象的。严格来讲,一个根能够有如下几种状况:
(1) 指向全局对象的引用(尽管C#不支持,但CIL代码容许分配全局对象)
(2) 指向任何静态对象
(3) 指向一个应用程序代码中的局部对象
(4) 指向传入到一个函数中的对象参数
(5) 指向等待被终结(finalized)的对象
(6) 任何一个指向对象的CPU寄存器
在一次垃圾回收的过程当中,运行环境会检查托管堆上面的对象是否仍然是从应用程序根可到达的。为了检查可达,CLR会创建一个表明堆上每一个可达对象的图。对象图用来记录全部可达的对象。同时,注意垃圾回收器毫不会在图上标记一个对象两次,所以避免了烦人的循环引用。
假设托管堆上有名字为A,B,C,D,E,F和G的对象集合。在一次垃圾回收过程当中,会检查这些对象(同时包括这些对象可能包含的内部对象引用)是不是根可达的。一旦图被创建起来,不可达的对象(在此是对象C和F)被标记为垃圾。
下图是上述场景的一个可能的对象图(你能够把箭头读做依赖或者须要,例如"E依赖于G,间接依赖于B,“A不依赖任何对象”等)。
(建立的对象图是用来决定哪些对象是应用程序根可达的。)
一旦一个对象已经被标记为终结(此例子中是C和F--在图中没有他俩),它在内存中就被清理掉了。在此时,堆上的剩余内存空间被压缩,这会致使CLR修改活动的应用程序根集合(和对应的指针)来指向正确的内存位置(这个操做是自动透明的)。最后,调整下一个对象指针来指向下一个可用的内存位置。
下图阐明了清除和压缩堆的过程。
到这里,经过对应用程序根的做用的理解,咱们知道了如何知道一个对象是“再也不须要”的。通俗点来讲就是,这个对象在应用程序中已经无需被访问了,成为了一座“孤岛”,天然也就再也不须要它了。
(为了让c++程序员能更加理解. net垃圾回收的奥妙,c#程序员继续口若悬河…)
理解对象的代 — 垃圾回收过程的优化
在尝试找到不可达的对象时,CLR并非检查托管堆上的每一个对象。很明显,这样作会消耗大量时间,尤为在大型(例如现实中)程序中。
为了帮助优化这个过程,堆上的每一个对象被分配到一个特殊的"代”。代这个概念背后的想法很简单:对象在堆上存活的时间越长,接下来它继续存在的可能性也就越大,即较旧的对象生存期长,较新的对象生存期短。例如,实现Main()的对象一直在内存中,直到程序结束。相反,最近才被放到堆中的对象(例如在一个函数范围里分配的对象)极可能很快就不可达。
在堆上的每一个对象属于如下的某一个代:
Generation 0: 标识一个最近分配的尚未被标记为回收的对象
Generation 1: 标识一个经历了一次垃圾回收而存活下来的对象(例如,他被标记为回收,但因为堆空间够用而没有被清除掉)
Generation 2:标识一个经历了不止一轮垃圾回收而存活下来的对象。
垃圾回收器首先会检查generation 0的全部对象。若是标记并清理这些对象(译者注:由于新对象的生存期每每较短,而且指望在执行回收时,应用程序再也不使用第 0 级托管堆中的许多对象)后产生了足够使用的内存空间,任何存活下来的对象就被提高到Generation 1。为了理解一个对象的代如何影响回收的过程,能够查看下图。下图解释了generation 0中一次垃圾回收后,存活的对象被提高的过程。
(generation 0 中的存活对象被提高到generation 1)
若是全部的generation 0对象都被检查了,可是产生的内存空间仍然不够用,就检查一遍generation 1中的全部对象的可达性并回收。存活下来的generation 1对象被提高到generation 2。若是垃圾回收器仍然须要额外的内存,generation 2的对象就经历检查并被回收。此时,若是一个generation 2的对象存活下来,它仍然是一个generation 2的对象。
其实经过对象的代的设计是想达到这么一个效果:新对象(好比局部变量)会被很快回收,而老一些的对象(如一个应用程序对象)不会被常常骚扰。
说到底,对象代的设计就是为了优化垃圾回收的过程。
“我还有最后一个问题”,c++程序员按耐不住内心一直的疑惑,说到:“你说了这么多都是再讲托管资源,难道.net中就没有非托管资源吗?. net又是怎么对非托管资源进行资源释放的呢?”。
"这个问题问的好!",c#程序员大笑,因而接着又开始解惑(吹B)…
以一名c#开发者的直觉告诉你,大多数的c#类都不须要显式的清理逻辑。缘由很简单:若是类型使用了其余托管对象,一切都最终会被垃圾回收。
问:那在何时须要显式地清理呢?
答案是:在你使用非托管资源时(例如原始的操做系统文件句柄、原始的非托管数据链接或其余非托管资源),才可能须要设计一个在用完后清理自身垃圾的类。
好比说下面这个类:
//数据库上下文类 public class SqlDbContext { //...(其余被引用的对象实例) //类中包含的非托管资源(须要调用 Dispose()函数进行资源的释放) SqlConnection sqlConnection = new SqlConnection("..."); }
如今问题来了,咱们要在适当的时机调用数据库链接类对象释放资源的方法(SqlConnection类对象使用完后须要调用Dispose()方法释放资源)。这个适当的时机固然就是对象在被CLR进行垃圾回收的过程当中,因此问题又来到了,有没有一个方法是在这个时机被调用,并且是能够被扩展的呢?
是的,咱们能够利用. NET的基类System.Object中定义的名为Finalize()的虚方法,也叫做终结器方法,它是这样的:
看到这固然会很奇怪,不是说有Finalize()方法,在哪,逗我?莫惊讶,其实这里的 ~Object() 就是Finalize(),只是一个语法糖罢了。
Finalize()的调用将(最终)发生在一次"天然的"垃圾回收或用程序经过GC.Collect()强制回收的过程当中,因此这样看来,终结器方法就是让类对象释放内部非托管资源的地方。nice,如今咱们能够像这样来编写清理非托管资源的代码:
//数据库上下文类 public class SqlDbContext { //...(其余被引用的对象实例) //类中包含的非托管资源(须要调用 Dispose()函数进行资源的释放) SqlConnection sqlConnection = new SqlConnection("..."); ~SqlDbContext() { //这里清除非托管资源 this.sqlConnection.Dispose(); } }
这样被构建的对象被叫作可终结对象。
有关于终结过程的细节,在《C#与.NET4高级程序设计(第5版)》书中是这样描述的:
从以上的内容咱们得知:经过Finalize()来清除非托管资源的时机只能是在.NET对象被垃圾回收的过程当中,并且终结过程是一个消耗不小的动做。
问题又来了:不少非托管资源都很是宝贵(如数据库和文件句柄),因此这些资源应该在使用完后尽快地被清除,而不能依靠垃圾回收的发生,那么这些资源应该以怎样的形式被显示地释放呢?
除了重写 Finalize() 以外,类还能够实现 IDisposable 接口,它定义了一个名为 Dispose() 的方法:
public interface IDisposable { void Dispose(); }
它的使用方法就是:在类的Dispose()方法中编写非托管资源的释放的代码,程序员能够在这个对象再也不须要的时候手动调用对象的Dispose()方法来达到及时释放非托管资源的目的。
因而你能够像这样来编写类:
//数据库上下文类 public class SqlDbContext:IDisposable { //...(其余被引用的对象实例) //类中包含的非托管资源(须要调用 Dispose()函数进行资源的释放) SqlConnection sqlConnection = new SqlConnection("..."); public void Dispose() { //这里清除非托管资源 this.sqlConnection.Dispose(); } }
采用这种方式来释放非托管资源的类被称做为可处置对象。
在这里还要补充一点,C#提供了一个语法糖来简化调用Dispose()操做,以下:
SqlDbContext context = new SqlDbContext(); try { //在此做用域内使用SqlDbContext类对象context } finally { //确保使用完后调用Dispose()方法 context.Dispose(); }
上面这段代码等同于下面这段代码:
using (SqlDbContext context = new SqlDbContext()) { //在此做用域内使用SqlDbContext类对象context }
c++程序员说:“你这还不是要本身手动调用,若是我忘记调用 Dispose() 那岂不是一切都玩完!”
c#程序员冷笑一声,“非也,非也,我来传授你最后一招吧!”
人非圣贤,孰能无过。程序员也会有失手的时候,好比,忘记调用 Dispose() 方法...
这个时候就必须设计一个万无一失的方法,达到一个目的:就是无论有没有手动调用Dispose(),非托管资源最终都应该被妥妥地释放掉。为了解决这个问题,咱们能够以下去定义一个可处置对象类:
//数据库上下文类 public class SqlDbContext:IDisposable { //...(其余被引用的对象实例) //类中包含的非托管资源(须要调用 Dispose()函数进行资源的释放) SqlConnection sqlConnection = new SqlConnection("..."); ~SqlDbContext() { //这里清除非托管资源 this.sqlConnection.Dispose(); } public void Dispose() { //这里清除非托管资源 this.sqlConnection.Dispose(); //跳过终结过程 GC.SuppressFinalize(this); }
能够看到,这个类中即有终结方法的重写也有Dispose()方法,这样就能保证:程序员若忘记调用Dispose()方法释放非托管资源,那么对象就会在垃圾回收的过程当中调用终结方法来释放非托管资源;若程序员调用了Dispose()方法,那么 GC.SuppressFinalize(this) 会保证在垃圾回收过程当中再也不会调用对象的终结方法,避免没必要要的资源开销。可谓“双剑合璧”,保万无一失。
话音刚落,c++程序员“噗通”一声跪倒在c#程序员面前,双手死死拉住c#程序员的裤子,"师父,收我为徒吧!我也要学c#…",c#程序员不想本身的裤子被扯破,因而答应了他。掏出一本上古神书…
哦,不,拿错了。。。应该是这本。。。
全剧终…