关闭顶部展开顶部

解读.net垃圾回收和CLR 4.0对垃圾回收所做的改进之一_.Net教程

编辑Tag赚U币
教程Tag:暂无Tag,欢迎添加,赚取U币!

推荐:解读.net垃圾回收和CLR 4.0对垃圾回收所做的改进之二
A survey of garbage collection and the changes CLR 4.0 brings in Part 2 - series of what is new in CLR 4.0 接前篇Continue the previous post .net垃圾回收和CLR 4.0对垃圾回收所做的改进之一 CLR4.0所带来的变化仍然没有在这篇,请看下篇。 内存释放

A survey of garbage collection and the changes CLR 4.0 brings in - series of what is new in CLR 4.0

导言Introduction

垃圾回收(Garbage Collection)在.net中是一个很重要的机制. 本文将要谈到CLR4.0对垃圾回收做了哪些改进. 为了更好地理解这些改进, 本文也要介绍垃圾回收的历史.这样我们对整个垃圾回收有一个大的印象. 这个大印象对于我们掌握.net架构是有帮助的.

  Garbage Collection is an important component of .net. The post will talk about what has been improved in CLR 4.0. To understand it, I will take a survey of the history of garbage collection. This way we can have a big picture of garbage collection. This will help us master .net architecture in comprehensive manner.

关于垃圾回收About Garbage collection
  在C++时代,我们需要自己来管理申请内存和释放内存. 于是有了new, delete关键字. 还有的一些内存申请和释放函数(malloc/free). C++程序必须很好地管理自己的内存, 不然就会造成内存泄漏(Memory leak). 在.net时代, 微软为开发人员提供了一个强有力的机制--垃圾回收. 垃圾回收机制是CLR的一部分, 我们不用操心内存何时释放, 我们可以花更多精力关注应用程序的业务逻辑. CLR里面的垃圾回收机制用一定的算法判断某些内存程序不再使用,回收这些内存并交给我们的程序再使用.

  In the times of C++, we need to allocate and release memory by ourselves carefully,  therefore there are new, delete keywords in C++, and fuctions(malloc/free) to allocate and release memory. C++ program has to manage its memory well, otherwise there will be memory leak. In .net, Microsoft provides a strong machanism to developers—Garbage collection. The Garbage collection is part of CLR. We do not need to worry about when to release memory. We can spend more time on buisness logic of applications. The Garbage colleciton of CLR adopts algorithms to decide which part of memory the program does not need any more, and then release these memory for further use.

垃圾回收的功能The functionalities of Garbage collection
  用来管理托管资源和非托管资源所占用的内存分配和释放。In charging of the releasing and re-allocation of memory of managed and unmanaged resources.

  寻找不再使用的对象,释放其占用的内存, 以及释放非托管资源所占用的内存. Find the objects no longer needed, release the memory the objects occupied, and affranchise memory occupied by unmanaged resources.

  垃圾回收器释放内存之后, 出现了内存碎片, 垃圾回收器移动一些对象, 以得到整块的内存,同时所有的对象引用都将被调整为指向对象新的存储位置。After releasing the memory no longer needed, there is memory scrap. Garbage collector shifts objects to get consecutive memory space, and then the references of objects will be adjusted according to the shifted address of objects.

下面我们来看看CLR是如何管理托管资源的. Let’s see how CLR takes care of managed resources.

托管堆和托管栈Managed heap and Managed stack:
.net CLR在运行我们的程序时,在内存中开辟了两块地方作不同的用处--托管栈和托管堆. 托管栈用来存放局部变量, 跟踪程序调用与返回. 托管堆用来存放引用类型. 引用类型总是存放于托管堆. 值类型通常是放在托管栈上面的. 如果一个值类型是一个引用类型的一部分,则此值类型随该引用类型存放于托管堆中. 哪些东西是值类型? 就是定义于System.ValueType之下的这些类型:

bool byte char decimal double enum float int long sbyte short struct uint ulong ushort

When .net CLR runs our program, CLR declares two ranges of memory for different purposes. Managed stack is to store local variables, and trace the call and return of routines. Managed heap is to store reference types. Usually value types was put on managed stack. If a value type is a part of a reference type, then the value type will be stored in managed heap along with the reference type. What are value types? They are the types defined in System.ValueType:

bool byte char decimal double enum float int long sbyte short struct uint ulong ushort

什么是引用类型呢? 只要用class, interface, delegate, object, string声明的类型, 就是引用类型.  What are reference types? The types declared with class, interface, delegate, object, stirng, are reference types.

我们定义一个局部变量, 其类型是引用类型. 当我们给它赋一个值, 如下例:We declare a local variable, which is a reference type, and we assign a value to the local variable, like the following:

private void MyMethod()
{
   MyType  myType = new MyType();
   myType.DoSomeThing();
}
在此例中, myType 是局部变量, new实例化出来的对象存储于托管堆, 而myType变量存储于托管栈. 在托管栈的myType变量存储了一个指向托管堆上new实例化出来对象的引用. CLR运行此方法时, 将托管栈指针移动, 为局部变量myType分配空间, 当执行new时, CLR先查看托管堆是否有足够空间, 足够的话就只是简单地移动下托管堆的指针, 来为MyType对象分配空间, 如果托管堆没有足够空间, 会引起垃圾收集器工作. CLR在分配空间之前,知道所有类型的元数据,所以能知道每个类型的大小, 即占用空间的大小.

In this sample, myType is a local variable. the object instantiated by new operation is stored in managed heap, and the myType local variable is stored in managed stack. The myType local variable on managed stack has a pointer pointing to the address of the object instantiated by new operation. When CLR executes the method, CLR moves the pointer of managed stack to allocate memory for the local variable myType. When CLR executes new operation, CLR checks first whether managed heap has enough space, if enough then do a simple action – move the pointer of managed heap to allocate space for the object of MyType. If managed heap does not have space, this triggers garbage collector to function. CLR knows all the metadata of types, and knows the size of all the types, and then knows how big space the types need.

当CLR完成MyMethod方法的执行时, 托管栈上的myType局部变量被立即删除, 但是托管堆上的MyType对象却不一定马上删除. 这取决于垃圾收集器的触发条件.后面要介绍此触发条件.When CLR finishs execution of MyMethod method, the local variable myType on managed stack is deleted immediately, but the object of MyType on managed heap may not be deleted immediately. This depends on the trigger condition of garbage collector. I will talk about the trigger condition later.

上面我们了解了CLR如何管理托管资源. 下面我们来看垃圾收集器如何寻找不再使用的托管对象,并释放其占用的内存. In previous paragraphs, we learn how CLR manages managed resources. In following paragraphs, we will see how garbage collector find objects no longer needed, and release the memory.

垃圾收集器如何寻找不再使用的托管对象,并释放其占用的内存How garbage collector find objects no longer needed and release memory
前面我们了解了CLR如何管理托管栈上的对象.按照先进后出原则即可比较容易地管理托管栈的内存. 托管堆的管理比托管栈的管理复杂多了.下面所谈都是针对托管堆的管理. In previous paragraphs, we learn how CLR manages the objects on managed stack. It is easy to manage managed stack as long as you utilize the rule “first in last out”. The management of managed heap is much more complicated than the management of managed stack. The following is all about the management of managed heap.

根The root
垃圾收集器寻找不再使用的托管对象时, 其判断依据是当一个对象不再有引用指向它, 就说明此对象是可以释放了. 一些复杂的情况下可以出现一个对象指向第二个对象,第二个对象指向第三个对象,…就象一个链表. 那么, 垃圾收集器从哪里开始查找不再使用的托管对象呢? 以刚才所说的链表为例, 显然是应该从链表的开头开始查找. 那么,在链表开头的是些什么东东呢? The criteria garbage collector uses to judge whether an object is no longer needed is that an object can be released when the object does have any reference. In some complicated cases, it happends that the first object refers to the second object, and the second object points to the third object, etc. It is looking like a chain of single linked nodes. Then the question is : where does the garbage collector begins to find objects no longer needed? For the example of the single linked node chain, we can say it is obvious garbage collector starts from the beginning of the chain. Then the next question is: what are the stuff at the beginning of the chain.

是局部变量, 全局变量, 静态变量, 指向托管堆的CPU寄存器. 在CLR中,它们被称之为根. The answer is : local variables, global variables, static variables, the CPU registers pointing to managed heap. In CLR, they are called “the roots”.

有了开始点, 垃圾收集器接下来怎么做呢? Got the roots, what will garbage collector do next?

创建一个图, 一个描述对象间引用关系的图. Build a graph, which shows the reference relationship among objects.
垃圾收集器首先假定所有在托管堆里面的对象都是不可到达的(或者说没有被引用的,不再需要的), 然后从根上的那些变量开始, 针对每一个根上的变量, 找出其引用的托管堆上的对象, 将找到的对象加入这个图, 然后再沿着这个对象往下找,看看它有没有引用另外一个对象, 有的话,继续将找到的对象加入图中,如果没有的话, 就说明这条链已经找到尾部了. 垃圾收集器就去从根上的另外一个变量开始找, 直到根上的所有变量都找过了, 然后垃圾收集器才停止查找. 值得一提的是, 在查找过程中, 垃圾收集器有些小的优化, 如: 由于对象间的引用关系可能是比较复杂的, 所以有可能找到一个对象, 而此对象已经加入图了, 那么垃圾收集器就不再在此条链上继续查找, 转去其他的链上继续找. 这样对垃圾收集器的性能有所改善.

First garbage collector supposes all the objects in managed heap are not reachable( do not have reference, or no longer needed). Then start from the variables in the roots. For each of the variable in the roots, search the object the variable refers to, and add the found object into the graph, and search again after the found object for next refered object, etc. Check whether the found object has next reference. If has, continue to add the next found object into the graph. If not, it means this is the end of the chain, then stop searching on the chain, continue on next variable in the roots, keep searching on roots, until all the searching are finished. In the searching process, garbage collector has some optimization to improve the performance. Like: Because the reference relationship could be complicated among objects, it is possible to find an object that has been added into the graph, then garbage collector stops searching on the chain, continue to search next chain. This way helps on performance of garbage collection.

垃圾收集器建好这个图之后, 剩下那些没有在这个图中的对象就是不再需要的. 垃圾收集器就可以回收它们占用的空间.After buidling the reference graph among objects, the objects not in the graph are no longer needed objects. Garbage collector could release the memory space occupied by the no longer needed objects.

分享:如何改变.net网站的默认解决方案位置
1. 把该网站以前的解冻方案删除(默认位置:我的文档\Visual Studio 2005\Projects\XX\xx.sln) 2. 打开VS2005,选择

来源:模板无忧//所属分类:.Net教程/更新时间:2009-07-19
loading.. 评论加载中....
相关.Net教程
闂傚倷鐒﹂惇褰掑春閸曨垰鍨傞梺顒€绉甸崑銈夋煛閸ヨ埖绶涚紓宥嗙墵閺屾盯鍩勯崘顏佸闂佹娊鏀辩敮妤呭Φ閸曨垰鍗虫俊銈傚亾濞存粍鍎抽—鍐Χ韫囨洜肖闂佺懓鍤栭幏锟�
濠电姷鏁搁崑娑㈩敋椤撶喐鍙忔い鎾卞灩绾惧鏌熼悙顒佺伇婵℃彃鐗撻弻锟犲磼濠靛洨銆婃繝鈷€鍕姇濞e洤锕幊鐘活敆婢跺棗浜炬繝闈涱儐閻撶喖鏌曡箛濠冩珔闁诲繑鐓¢弻鐔煎礄閵堝棗顏�
濠电姷鏁告慨鐑姐€傛禒瀣劦妞ゆ巻鍋撻柛鐔锋健閸┾偓妞ゆ帒瀚峰Λ鎴犵磼鏉堚晛浠滄い鎾冲悑瀵板嫮鈧綆浜濋楣冩煟鎼达絾鍤€閻庢凹鍘界粩鐔煎幢濞嗘劕搴婃繛鎴炴煣缁舵岸寮婚敐澶婎潊闁宠桨鑳舵导鍫ユ⒑閻熸澘娈╅柟鍑ゆ嫹
濠电姷鏁告慨鐑姐€傛禒瀣劦妞ゆ巻鍋撻柛鐔锋健閸┾偓妞ゆ帒瀚峰Λ鎴犵磼鏉堚晛浠滄い鎾冲悑瀵板嫭绻濋崟闈涙倯闂傚倷娴囬鏍垂鎼淬劌绀嬫い鎾楀嫅姘舵⒒娴g瓔鍤欓梺甯到宀h儻顦查摶鐐寸箾閹存瑥鐏柛瀣樀閺屻劑鎮ら崒娑橆伓
闂傚倸鍊烽懗鑸电仚缂備胶绮崝娆撶嵁婵犲啯鍎熼柕濞垮劤閸旓箑顪冮妶鍡楃瑨闁稿﹤鎽滈弫顕€宕奸弴鐐殿啇闁诲孩绋掑玻鍧楁儗閹烘柡鍋撶憴鍕缂佽鐗撳顐﹀箻缂佹ɑ娅㈤梺璺ㄥ櫐閹凤拷
闂傚倸鍊烽懗鑸电仚缂備胶绮崝娆撶嵁婵犲啯鍎熼柕濞垮劤閸旓箑顪冮妶鍡楀潑闁稿鎹囬弻娑橆潩椤掑鍓崇紓渚囧枛閿曨亪寮崒鐐茬鐟滃繘鎮¢幘缁樼厽閹兼惌鍨冲畝娑㈡煛閸涱喚绠為柟顖氳嫰閳诲酣骞嬮悩纰夌闯濠电偞鎸婚懝楣冩晝閵壯€鍋撳鐐
闂傚倸鍊峰ù鍥Υ閳ь剟鏌涚€n偅灏伴柕鍥у瀵粙濡歌濡插牓姊烘导娆忕槣闁革綇缍佸璇测槈濡攱鏂€闂佸綊鍋婃禍鐐烘嚄閾忓湱纾藉ù锝夋涧婵¤姤淇婇悙鑸殿棄妞ゆ洩缍佹俊鎼佸煛婵犲啯娅栨繝鐢靛仜濡瑩宕归悽鐢电當闁跨喓濮甸埛鎴︽煕濠靛棗顏╅柍褜鍓欓…鐑界嵁婵犲洤绠婚柤鍛婎問濞肩喖姊虹捄銊ユ珢闁瑰嚖鎷�
闂傚倸鍊风粈渚€骞栭锕€鐤柣妤€鐗婇崣蹇擃渻鐎n亝鎹g紒鈧繝鍌ょ唵闁兼悂娼ф慨鍫ユ煟閹垮嫮绉柟顔款潐濞碱亪骞忓畝濠傚Τ婵犵數鍋涢惇浼村磹閺囥垺绠掗梻浣瑰缁诲倸螞濞嗘垹鐭嗛柍褜鍓熷娲川婵炴碍鍨块幃褔鎮╅懠顒佹闂佽澹嗘晶妤呭疾閹间焦鐓ラ柣鏇炲€圭€氾拷
婵犵數濮烽。钘壩i崨鏉戝瀭妞ゅ繐鐗嗙粈鍫熺節闂堟稒锛嶉柣鏂挎娣囧﹪顢涘顒佸€柣搴㈡皑缁垶濡甸崟顖氱閻庨潧鎽滈悾娲煟鎼淬垻鍟查柟鍑ゆ嫹
濠电姷鏁告慨鐑姐€傛禒瀣劦妞ゆ巻鍋撻柛鐔锋健閸┾偓妞ゆ帒瀚峰Λ鎴犵磼鏉堚晛浠滄い鎾炽偢瀹曞爼濡搁妷顔荤穿濠碉紕鍋戦崐鏍箰閼姐倖宕查柛鎰典簴閸嬫挸顫濋搹顐ゅ涧婵烇絽娲ら敃顏堛€佸☉妯滄棃鍩€椤掍焦娅犻柛娆忣槺缁♀偓濡炪値鍋掗崰妤冣偓姘炬嫹
婵犵數濮烽。钘壩i崨鏉戝瀭妞ゅ繐鐗嗙粈鍫熺節闂堟稒锛嶉柣鏂挎閹便劌顪冪拠韫闁诲氦顫夊ú锕傚礈閻旂鈧礁鈻庨幘宕囶槯闂佺粯鎸哥花鍫曞磻閹剧粯鍋ㄩ柛娑橈功閸樻悂姊洪崜鎻掍簼缂佽瀚悺顓炩攽閻樻剚鍟忛柛锝庡灦楠炲繘鏁撻敓锟�
婵犵數濮烽。钘壩i崨鏉戝瀭妞ゅ繐鐗嗙粈鍫熺節闂堟稒锛嶉柣鏂挎閹便劌顪冪拠韫闂備礁鎼懟顖炲箠濮椻偓瀹曟椽鍩€椤掍降浜滈柟鍝勬娴滈箖姊虹€圭媭鍤欓梺甯秮閻涱噣骞嬮敃鈧粻娑㈡⒒閸喓鈯曟い鏂挎濮婄粯鎷呴崨濠冨創闁诲孩纰嶉幃鍌炵嵁韫囨稒鏅搁柨鐕傛嫹
婵犵數濮烽。钘壩i崨鏉戝瀭妞ゅ繐鐗嗙粈鍫熺節闂堟稒锛嶉柣鏂挎閹便劌顪冪拠韫闁诲氦顫夊ú鈺冪礊娓氣偓閻涱喚鈧綆浜栭弨浠嬫煕椤愵偄浜楃紒鎲嬫嫹
濠电姷鏁告慨鐑姐€傛禒瀣劦妞ゆ巻鍋撻柛鐔锋健閸┾偓妞ゆ帒瀚峰Λ鎴犵磼鏉堚晛浠滄い鎾冲悑瀵板嫭绻濋崟顓炲箑闂傚倷鑳堕幊鎾绘偤閵娧勫床闁告洦鍨奸弫鍌炴倵濞戞鑲╂崲閸℃ǜ浜滈柡宥庣厛濞堟柨顭胯瀵墎鎹㈠┑瀣剁稏妞ゆ棁妫勯锟�
闂傚倷娴囬褎顨ラ幖浣稿偍婵犲﹤鐗嗙粈鍫熺節闂堟侗鍎愰柛瀣儔閺岀喖骞嗛悧鍫闂佹椿鍘介〃鍛村煘閹达附鍋愰柟缁樺笚濞堫參姊烘總鍛婃锭缂傚秴锕濠氬Χ婢跺娈熼梺闈涱槶閸庨亶锝炲澶嬧拺缂備焦岣挎竟鍕磽瀹ュ嫮顦﹂柣锝呭槻閳诲酣骞樼€涙ɑ顏熼梻浣芥硶閸o箓骞忛敓锟�
UB闂傚倸鍊风粈浣革耿鏉堚晛鍨濇い鏍仜缁€澶嬩繆閵堝懏鍣界€规挷绶氶弻娑㈠Ψ閵忊剝鐝曢柣搴㈢瀹€鎼佸箖濡も偓閳藉鈻嶉搹顐㈢伌闁挎繄鍋ら弫鎾绘晸閿燂拷
闂傚倸鍊峰ù鍥ㄧ珶閸喆浠堢紒瀣儥濞兼牕鈹戦悩宕囶暡闁绘帡绠栭幃妤呮偨閻㈢偣鈧﹪鏌涚€n偅宕岄柣娑卞櫍瀹曞綊顢欓崣銉ф/濠电姷鏁告慨顓㈠磻閹剧粯鐓ラ柣鏇炲€圭€氾拷
闂傚倷娴囬褎顨ラ崫銉т笉鐎广儱顦崹鍌炴煕濠靛棗顏甸柤鏉挎健閺屾盯濮€閵忕姵顔�
闂傚倸鍊风粈渚€骞夐垾鎰佹綎缂備焦蓱閸欏繐顪冪€n亝鎹g紒鈧繝鍌ょ唵閻犻缚娅i悘閬嶆煕濡や胶顣茬紒缁樼洴瀹曞崬螖閳ь剟顢楅姀銈嗙厱闁绘劕妯婂Σ鍦磼缂佹ḿ銆掔紒杈ㄧ懇閹晠宕崟顐㈣厫闂傚倷鑳舵灙濡ょ姴绻橀獮蹇涙晸閿燂拷
缂傚倸鍊搁崐鎼佸磹閻戣姤鍊块柨鏇炲€归崑锟犳煥閺囩偛鈧悂宕归崒娑氱瘈濠电姴鍊搁顐c亜閳哄懏鏁遍柕鍥у楠炴帒顓奸崶鑸敌滅紓鍌欑劍瑜板啫锕㈤柆宥呯劦妞ゆ帒鍊告禒顖炴煕婵犲啰绠樼紒杈ㄦ尭椤繃锛愬┑鍥ㄦ珦闂備浇娉曢崳锕傚箯閿燂拷
©2017 www.mb5u.com婵犵數濮烽。钘壩i崨鏉戝瀭妞ゅ繐鐗嗙粈鍫熺節闂堟稒锛嶉柣鏂挎閹便劌顪冪拠韫闁诲孩顔栭崳顕€宕抽敐澶婄畺闁冲搫鎳庣粻鐢告煙閻戞ɑ灏柣锔兼嫹
闂傚倸鍊峰ù鍥Υ閳ь剟鏌涚€n偅宕岄柡宀€鍠栭、娑樷堪閸愮偓姣夋俊鐐€戦崕濠氬箯閿燂拷&闂傚倸鍊风粈渚€骞夐敍鍕殰闁圭儤鍤﹀☉銏犵睄闁割偆鍣ュΛ鍛存⒑鐠恒劌娅愰柟鍑ゆ嫹