博客园_to be or not to be ,that is a questtion

Silverlight 3引入了GPU加速的特性

2010-06-17T05:17:00Z

Silverlight 3引入了GPU加速的特性，该功能默认为禁用。启用该功能需要：

1. 在Silverlight plug-in上设置 <param name="enableGPUAcceleration" value="true" /> 或使用代码 Application.Current.Host.Settings. EnableGPUAcceleration= True;

2.在类型为UIElement的控件上设置 CacheMode = "BitmapCache" - 所谓GPU加速是基于GPU缓存了一些UI元素，节省了CPU的耗用

如何知道哪些控件被缓存？在Silverlight plug-in上设置 < param name = "enableCacheVisualization" value = "true" /> 后程序界面中会有颜色变化：

1. 红色表示没有被缓存

2. 正常颜色表示被缓存

3. 绿色表示没有设置 CacheMode = "BitmapCache"，但被自动缓存

由于GPU加速的原理是缓存，那么频繁变动的UIElement就不适宜使用，因为缓存的频繁更新反而会带来性能损耗。但是MideaElement例如视频使用GPU加速可以实现性能提高：

图：启用缓存的视频

但是perspetive 3d效果的视频则不可以：

图：右侧视频使用了Pespective 3d效果，显示为红色，没有缓存

GPU加速的限制：

1. GPU 加速仅支持如下动画： Scale, Rotate, Changing Opacity, Clipping (only if clip is rectangular)，其他则不支持，例如 Perspective 3d效果的动画。

2. GPU显存不足，Silverlight会默认使用CPU来实现缓存，这反而会增加CPU的负担 - 目前Silverlight还不支持查询GPU缓存大小的方法，仅提供了Analytics.GpuCollection 属性。

3. 需要支持DirectX(Windows) 或OpenGL(Mac)的显卡，且Mac上仅支持全屏模式

参考：

1. https://blogs.msdn.com/b/rahul/archive/2010/06/09/silverlight-graphics-and-hardware-acceleration.aspx

2. http://dotnetslackers.com/articles/silverlight/discovering-silverlight3-deep-dive-into-gpu-acceleration.aspx

3. http://arthraim.cn/silverlight-3-and-gpu-acceleration/

装扮小游戏换装小游戏化妆小游戏美女小游戏

原文:http://blog.csdn.net/jameszhou/archive/2010/06/14/5670852.aspx

本文链接

Flash还能走多远？

2010-02-24T05:13:00Z

谈到Flash能走多远的问题时，我们不得不先聊聊作为Flash前辈的Applet。

所以要提它，是因为人类历史上第一个运行在浏览器之上的交互式应用，本来就是Java小程序，而非什么Flash。

装扮小游戏换装小游戏化妆小游戏美女小游戏古装公主小游戏装扮仙女小游戏装扮男友小游戏情侣约会小游戏婚纱礼服小游戏阿sue小游戏做饭小游戏美女餐厅小游戏理发小游戏美甲小游戏芭比娃娃小游戏大头妹小游戏布置房间小游戏照顾宝宝小游戏祖玛小游戏连连看小游戏对对碰小游戏泡泡堂小游戏超级玛丽小游戏黄金矿工小游戏密室逃脱小游戏魔塔小游戏找茬小游戏发泄小游戏双人小游戏儿童小游戏奥特曼小游戏海绵宝宝小游戏虹猫蓝兔小游戏哆啦A梦小游戏喜羊羊与灰太狼小游戏搞笑小游戏休闲小游戏冒险小游戏模拟经营小游戏棋牌小游戏测试小游戏策略小游戏动作小游戏体育小游戏敏捷小游戏射击小游戏益智小游戏综合小游戏

早在1995年之初，当Gosling和Gage在WebRunner浏览器（即日后的HotJava浏览器）上展示3D分子模型之际，人们对Java的第一印象就是“这是种可以将静态网页变成动态的语言”，而并非这是种“开发手机应用的语言”或者这是种“开发企业级应用的语言”。

直言不讳的说，自从Java与Applet诞生之初，直到2000年Flash5出现以前，Java和Applet一直都是网站动态效果实现的首选媒介（尤其是网络教学）。而在此以前的Flash还算不得主流，登不得台面。

为什么Java(Applet)会变得不如Flash普及？

关于这点，抛开WindowsXP后期版本不再内置JVM的影响不谈，应该说同Sun高层的愚蠢无能，以及Macromedia高层的下作龌龊不如关系（某个时期的Flash真的就像流氓软件一样，不经过任何预警便自行安装，也没有必要的砂箱保护，什么都能运行）。

正是这群墨守陈规，不思进取，被Java技术所带来的惊天财富冲昏了头脑（2000-2001年Sun最兴盛时，股票峰值曾达258.75美元/股，公司估价超过2000亿美金），对技术趋势把握犹如童蒙的Sun高层，最终葬送了Java在网页乃至桌面领域的大好河山。

要知道，当时的Applet虽然有着相当完善的Java类库支持，并有稳妥的砂箱机制保证程序安全，但运行速度却异常缓慢（特指JRE1.0-1.3），运行界面也远没有Flash那么鲜艳友好，已经变得渐渐无法适应越来越复杂的网络展示需求，业界甚至开始出现关于Java与Applet的不利消息。

更关键的是，假如当时没有Macromedia的Flash，或者Flash根本就是个连Applet也不如的垃圾那还好说。可偏偏，偏偏Flash在界面效果与运行速度方面都远胜于当时的Applet！而这群理应在脸上被刻下S13星烙印的Sun高层，不单在不必要的时刻过早地与微软决裂，甚至还对Flash这样新兴技术的威胁无动于衷！

他们即不想办法走正道完善自己的Java与Applet体系，又不会运用邪道将Flash挤出市场，既没能预见到网页前端市场中蕴含的巨大商机，更无法适时的调整公司经营战略寻求新的Java赢利模式，任凭别人风生水起，自己却只管悠哉游哉的数着因股价飞涨而带来的绿色钞票。

——此辈若能成事，岂有天理乎！

事后的结果证明，相对于系统内置，小巧灵活，并有足够强大图形编辑工具支持的Flash。原有的Applet技术显得臃肿、缓慢、不易开发，甚至没有一款拿得出手的图形编辑器。

要知道，在IT领域中按资排辈这种事情根本就不曾有过。即使几十年的老店，也很可能会被某个车库中诞生的新生公司打的体无完肤。

更何况，在那些愚不可及的Sun高层眼里，网页前端甚至桌面市场或许本就是一盘可有可无的生意，赢了没什么不好，输了也不可惜。毕竟Applet只是Java功能中的一小部分，Sun有SPARC、Solaris、Java这三大法宝，即便Java中舍弃了Applet，依然有大把本钱，根本不必在意。

很明显，当时的Sun高层，对于“占领桌面，跳进口袋”这样的经营理念还缺乏认知。假如他们明白，那么无论Applet/AWT/Swing也好，J2ME也罢，也决计不会是今天这种地位。

此消彼长下，Flash的兴起与Applet的堕落几乎都成了必然，越来越多的开发者投向Flash阵营，最终导致了今天Flash的兴起与Java（Applet/AWT/Swing）在网页前端领域的没落。

在新的时代里，伴随HTML5的逐渐普及，网页技术的大洗牌时代将会再次来临。

正所谓“长江后浪推前浪，前浪死在沙滩上”，就像当时的Applet技术，会被更先进，更进取（也更流氓）的Flash技术所取代一样，新技术体系的出现，永远是旧有技术体系所无法回避的恐怖梦魇。

——就连Abode公司与Flash也无法逃避这种规律。

诚然，现今的Flash比之当初改进了很多，Abode将它变得比以前更完善（他们干脆重写了Flash核心），除了原有的小动画、小广告、小游戏之外，Flex的出现让J2EE 或其它技术体系能够利用Flash开发商业应用，ActionScript脚本让死硬技术派们可以直接编写出Flash程序而不必拖拽界面。小到AV视频展示，大到网络游戏应用，几乎到处都可以见到Flash的踪影，Flash简直成了RIA的代名词。

无论实际怎样，在当今这个时代里，“够快、够简、够普及”早已成了人们对Flash技术的潜在共识。

——然而，这些印象恐怕也只能维系到HTML5普及以前。

没错，HTML5标准的出现，将彻底颠覆现有的网页前端生态体系。

因为HTML5的诞生，很大程度上就来源于浏览器厂商们对于网页前端技术需求的反思。干脆点说，根本就是对于Flash大红大紫的一种醒悟。

在这里，我们姑且将其想象为一场阴谋，一场“HTML5”诡计。

在某个阴暗偏弊的房间里，业界的大佬们，或许曾经进行过类似这样的讨论“既然Flash用几MB的支持库就可以在浏览器上实现的功能，难道我们这些平台（浏览器）就做不到吗？既然是人人都要用到的功能，我们又为什么非要通过Flash进行中转实现呢？既然现在大家都需要这些功能，并且寻求更好的用户体验，干嘛不将它们绕过Flash，直接内置到浏览器中，以换取既快且稳的效果呢？！”

这些人大概会达成这样一种共识，那就是Flash很牛，牛到了几乎没它不成。可长此以往，兄弟们恐怕也都没得混了。所以，只好委屈Flash先走一步吧！

正如站在汽车上跑步，无论跑得再快，始终跑不过汽车一样。任凭Flash的UI再漂亮、制作再简便、运行速度再快，它又该如何超越它所在的浏览器平台本身？如何摆脱这群大佬巨鳄的魔掌呢？

事实上，HTML5所提供的API标准，彻底克制于Flash之上。一旦标准普及，毫无悬念的，HTML5将秒杀Flash。

可以设想一下，随着HTML5的逐渐普及，当你通过一个<video>标签就可以播放高清网络视频，当你通过一个<canvas>标签就可以渲染出相当靓丽的网页动画，当WebGL让你网页硬件加速，运行出不次于《魔兽世界》的3D效果，当WebSQL让你在浏览器中保存数据就像操作桌面应用那么简单，当WebSocket轻而易举地实现浏览器与服务器端通讯之际，谁还会关心什么swf，谁还会记得什么Flash？

Ext3.0提供的<video>标记应用效果：

Web3D效果：

不客气地讲，当HTML5真正普及之日，Flash的优点都将变得不能再称为优点，而它的缺点却会开始凸现得越来越严重。

所有依靠Flash，特别是依靠Flash在网页方面养家糊口的同仁们，我劝大家千万不要相信那个关于HTML5要到2022年才会正式实施的传闻，误以为还有很长的周期让Abode改进技术甚至相信自己能在此前就熬到主管级别。

只要稍微看看最近Chrome、FireFox的更新趋势，乃至未来的IE9规划，你立刻就会发现，它们会等你到2022吗？绝对不会！不到2015年，HTML5就已经是各个浏览器的事实标准了。

看到这里，你或许会说：“胡说！Flash可不只是那么一点功能，况且现在有那么多的Flash应用，难道都能轻易舍弃吗？兼容性问题你都解决了吗？”

——没错，原有的Flash功能，就是会被人们所遗忘舍弃。

正如有声电视机取代无声电视，电话机取代传声筒一样，让你在一台免费的PSP3，一台免费的Xbox中抉择你想要哪台主机，你可能很难下决定。然而，如果换成一台是免费的小霸王，一台是白来的Xbox间抉择，该搬哪台回家，肯定不用笔者去教。

即便网络上有97%的网站在使用Flash，即便网络上有数不清的Flash/Flex应用存在，一旦更简便、更快捷、更高效的HTML5标准普及，这些都会变得毫无意义。

毕竟新近的开发者们决不会选择一种低效、缓慢、过时、并且可以被替代的技术作为自己的开发语言。

到了这时，就算你给地球上60多亿人口每人配备一个Flash应用，这60亿也将成为一个永远不会增加的死数，也就是Flash的极限。而人有寿命，网站同样也有寿命，即便某些死硬派不愿放弃，即便某些死硬网站不改初衷，他们也只能维系自己这点地盘，却丝毫影响不了别人的选择。最终，他们不是被别人吞并，就是自己也改弦更张，至多是死抱着Flash直到寿终正寝，但无论如何，迟早都是同样的下场。

谈到这里时，我希望大家不要忘记，当初Netscape的市场占有率有多少，现在又有多少？更加不要忘记，当初Applet在网页前端应用的市场占有率有多高，现在又有多高？

假如他们的被取代大家都能想通，到了Flash被取代时，我们会再犯糊涂吗？不会。

——应该说，只要未来普及了HTML5，Flash回老家结婚就是注定的。

或者你还会想，如果低端走不通，那么我就走中高端，让Flash继续增加HTML5所不具备的特性，毕竟Flash10以后的安装文件也有10多MB了，所谓“虱子多了不咬，债多了不愁”，再加点也没什么，自然有人会用。

嗯，没错，如果Abode继续复杂化Flash功能，并能够完成那些HTML5所无法实现的复杂应用固然很好。

——但是，您是不是忘了点什么，真以为Java和C#都是摆设不成？

Applet/Javafx，Silverlight这些现成的网页前端应用解决方案是摆着好看的吗？Oracle、Microsoft在复杂应用，尤其是企业级应用上是吃素的吗？莫非Flash开发者就真的集体空闲到会用N多年来逐一重复开发轮子，然后再做项目？莫非有现成的一体化解决方案不用，资方还非要用你的Flash前台，微软或甲骨文的后台？即便你一口咬定Flash开发就是简单，但这时已经有了更简便的HTML5可用（甚至连swf的加载都省了），你又何苦自残呢？照此发展下去，就算开始时真有几个想不开的，可一旦做HTML5的渐渐多了，傻子始终会不够用的……

就在此刻，只要你去下载最新版本的Chrome，稍微尝试下HTML5即将带来的全新功能，你就会发现，以前看上去那么短小精悍的swf文件，曾几何时，怎么就变得这样臃肿没用了呢？！以前那么艳丽生动的Flash动画，曾几何时，怎么就变得这样繁琐呆滞了呢？！

——我们应该清楚的看到，HTML5的出现，并不仅是一场技术革新，更是一场业界洗牌！它将彻底破坏现有网页前端技术的游戏规则，将Flash打入万劫不复之地！

再者，这么多年来Flash普及甚广，吃这碗饭的人不在少数。而反过来说，Flash程序员品质参差不齐，技术有高有低，被人利用Flash中马，被人利用Flash盗取个人信息者更不在少数，对Flash深恶痛绝者也不在少数。

且不提乔布斯这样痛骂Flash的业界领军人物，单单是你我这样的普通技术人员，又有几个从没有被网站上的Flash广告搞的页面崩溃，又有几个没有安装过FlashBlock的呢？

有些Flash开发人员看到此处或许会心有不甘，但至少在网页前端领域，Flash的衰落已不可避免，并非你我这样的凡夫俗子所能干预影响。

在这里，就让我们提前说一句：“Flash你好，Flash再见” 吧！

Flash不成了，Applet/JavaFx，Silverlight还能有什么作为？

此刻，我们回头去看Applet，就会发现到它已然错过了一场本该属于它的技术革命，错过了一场本可以大赚特赚的饕餮盛宴。

假如当时的Sun管理者有幸穿越时间隧道到现今看看，并且活着回去。我想Macromedia的下场无非两个，要么被Sun收购，要么就是被Sun打的连北都找不到了。

更直接的讲，如果当时的Sun高层来到今天，看到JavaFX这种“后知后觉”的网页前端技术，看到JDK1.6这种“迟到”的性能改进，甚至捎带手将Android的做法也学习一下，并且在那个时代就付诸实践的话，还有什么Flash/Flex？哪来什么Silverlight？Java早该“千秋万载，一统江湖”了。

——但当时又有几个人能想到，网页前端市场会发展到如今这样白热化的地步呢？

历史不允许假设，穿越的事情更是“可求而不可遇”，我们所面对的，是一个Macromedia被Abode收购，Sun被Oracle收购的时代，也是一个HTML5即将渐渐普及的时代。

放眼当今，即便Flash真如笔者所言即将成为明日黄花，抛开有微软银弹力挺的Silverlight不谈，莫非连Applet/JavaFx这路“古董货”也会有所作为吗？

——笔者认为是可能的。

事实上，任何了解Flash的人都知道，Flash是很简单，很快捷，很高效没错。

但是，这也仅仅局限于简单的动画效果，或者说仅仅局限于一些比较简单的业务实现当中。

——任何一位有经验的Flash程序员，即便你有多爱Flash，恐怕也很难讲出ActionScript是一门设计完善，性能卓越的语言吧？

以Flash开发诸如偷菜、调教秘书的小游戏，抑或制作个上传下载的简单界面确实又快又好。但轮到真正复杂的应用时，譬如让你用它开发个3D的《魔兽世界》（仅指模拟效果），甚至要求再低些，让你去搞个《传奇》级别的网游，就根本不是那么一回事了。

而Java方面，我们都知道如蓝港在线之类的国内公司，在很早以前就率先尝试过利用Java技术开发过诸如《倚天剑与屠龙刀》之类的2.5D即时战斗类游戏，现今该公司所开发的《西游记》也依旧延续了这一体系。但假如我们将它转换为Flash，而非Java开发，试问哪家游戏公司既能做出这样的即时战斗效果，又不被活活卡死？谁敢说这样的话？！

你或许会说这只是个桌面应用，那我们就单说网页游戏，我们都很清楚现在国内有不少尝试用Flash开发网页游戏的公司，更有不少Flash开发者对于《黑暗契约》之类的国外网页游戏津津乐道。

但是，当你望着屏幕上每次过屏都反复下载的各种模块时，当你望着相互PK却突然静止不动或者模糊不清的画面时，当你望着稍不留神就会CPU占用达到100%，直到被敌人杀死也未必会再动的游戏时，你除了选择清空缓存永不再玩，还能干些什么呢？

事实上，即便Flash网页游戏如同雨后春笋般发展到今天，笔者始终没有见过一款哪怕是“不太卡”的ARPG游戏，甚至于连续玩上一段后不用刷新重进的RPG类也很少见。否则，笔者也不会在某Flash网游中白投了数百元去刷金龙蛋、凤凰卵，却最终选择不玩了事了。

在这里笔者不想刻意褒贬国内的一些Flash网游，只是随意摘取了某Flash游戏GM对某玩家评语的回复，或许就能稍见端倪（玩家具体评了什么，请大家自行从对话中推导）

事实上，在这里还有一个比较鲜明的对比（好吧，我承认这是我截图的主因），那就是上面某位玩家提到了汉森的《倾城》，这是一款非常罕见的Java（Applet）网游。对比玩家的评论就不难发现，Flash与Java技术的决定性差异，究竟体现在了什么地方。

下图为《倾城》截图：

应该说，相对于适合简单图形应用的Flash而言，Applet（含JavaFX）截然相反，它庞大的类库与体积并不适应于很多需要快速加载的场合，以致某些人初次运行时会觉得它很慢。但是，只要加载过一次的应用，Applet（含JavaFX）都将自动建立其相关缓存，直到你修改相关应用并重新发布之前，Applet都不会再有重复下载的行为出现。

也就是说，Applet的慢仅仅局限于首次运行，而后便没有了那种烦恼。而Java本身固有的丰富支持库，以及超级强悍的网络通讯功能，更加不是Flash所能比拟的（更极端的讲，Java逼急了能上JNI，Flash怎么办？）。可以这样说，越复杂的游戏，对于Java就越是得心应手，越是复杂的应用，对于Java就越是驾轻就熟（类似于Sun公司的奇异特性，复杂的事简单，简单的事复杂……）。

而Flash的小巧、简单，却在这时变成了缺点，因为类库的不完备，你必须亲自开发大量的程序模块，才可能让它正常运行在诸如网游这样复杂的环境中；因为性能的不到位，你必须自行处理海量的图形资源，斤斤计较于某个对象的释放与否，才能保证程序不会突然静止不动。而即便你全部处理了这些，以Flash的固有能力来看，应用的稳定性将依旧欠佳，哪怕画面再好，只要稍微运行久些，迟早都原形毕露，该卡则卡，该崩则崩，该死则死。

更何况，一旦在Java中使用了OpenGL，那么即便是画面效果这个Flash中唯一的优点，也将不复存在。

比如Java网游中大名鼎鼎的RuneScape（http://www.runescape.com/），可以在网页前端高效运行3D游戏，却没有一丝一毫的延迟停顿。而在Flash网游的世界里，又有什么能和它比肩的3D应用（不卡的3D人物打斗示例都算）吗？如果有的话，麻烦哪位给个链接我看。

事实上，假如Sun最初就能像JRE1.6以后版本那样大幅度的提高图形运算速度，或者将DirectX与OpenGL调用更方便的绑定（直接提供API）在JDK当中的话，现在网页游戏的开发主流或许将是Applet甚至JavaFX了。

正因为Sun最初的不作为，才直接导致了后来许多人关于Java性能的误解与迷茫，造成了人们对Java性能 “低劣”这种陈芝麻烂谷子的刻板印象，最终导致了很多人误上Flash的“贼船”。（最可气的是，因为Sun的行动过于缓慢，现今虽然有了JOGL之类的拓展应用，但很多搞Java的已然变得不会用OpenGL了……）

——古人云“观古今之成败，能先见事机者，则恒受其福”，诚不我欺。

伴随HTML5的普及以及Java性能的逐渐提升，Flash在前端的领先优势将不复存在，网页低端与高端应用将会产生分流，未来Applet/JavaFx或Silverlight究竟谁主沉浮，始终还是未知之数，希望Oracle不要再走Sun的老路，真真正正的认清形势，抓住机遇吧！

本文链接

.net CLR 4.0垃圾回收机制的改进之3

2010-02-21T07:08:00Z

A survey of garbage collection and the changes CLR 4.0 brings in Part 3 - series of what is new in CLR 4.0
接前篇Continue the previous posts

.net CLR 4.0对垃圾回收机制的改进

.net CLR 4.0对垃圾回收机制的改进2

弱引用Weak Reference

mm小游戏

弱引用是相对强引用来说的。强引用指的是根有一个指针指向对象。弱引用是通过对强引用加以弱化而得到的。这个弱化的手段就是用System.WeakReference类。所以精确地说，强引用指的是根有一个非WeakReference类型的指针指向对象，而弱引用就是根有一个WeakReference类型的指针指向对象。垃圾收集器看到一个WeakReference类型的根指向某个对象，就会特别处理。所以在垃圾收集器创建对象引用关系图的时候，如果遇到一个弱引用指针，那么垃圾收集器就不会将其加入图中。如果一个对象只有弱引用指向它，那么垃圾收集器可以收集此对象。一旦将一个强引用加到对象上，不管对象有没有弱引用，对象都不可回收。

Weak reference is corresponding to strong reference. Strong reference is that a root is pointing to an object. Weaken a strong reference and get a weak reference. The facility to weaken strong reference is the System.WeakReference class. An exact definition is that, strong reference is that a root has a non-System.WeakReference type pointer pointing to an object, and weak reference is that a root has a System.WeakReference type pointer pointing to an object. Garbage collector treats the roots of WeakReference type in a special way. Therefore, when garbage collector is building the reference relationship graph, if there is a weak reference pointer, and then garbage collector will not append it to the graph. If an object only has weak references pointing to it, garbage collector can collect the object. Once a strong reference is pointing to the object, no matter whether the object has weak references or not, the object can not be collected.

垃圾收集器对WeakReference类的特别处理从new操作就开始。通常的类，只要new操作，就会从托管堆分配空间，而WeakReference类的new操作不是这样做的。我们先来看WeakReference类的构造函数：

The special treatment that garbage collector deals with WeakReference class starts from the new operation. A common class will allocate space from managed heap when new operation, but CLR does not do like that for WeakReference class when new operation. Let’s look at the constructors of WeakReference class:

WeakReference(Object target);

美女小游戏

WeakReference(Object target, Boolean trackResurrection);

此二构造函数都需要一个对象的引用，第二个构造函数还需要一个布尔值参数来表示我们是否需要跟踪对象的重生。此参数的意义后文会交代。

The two constructors both need a reference of an object, and the second constructor needs one more, a parameter of boolean type to indicate whether we need to track the resurrection of the object. The exact meaning of the parameter will be talked about later.

假设我们有两个类MyClass和MyAnotherClass，都有Finalize方法。我们声明两个对象：

Suppose we have two classesMyClass and MyAnotherClass, and both of classes have Finalize method.

MyClass myObject = new MyClass();

MyAnotherClass myAnotherObject = new MyAnotherClass();

当我们用这样的代码声明一个弱引用对象: WeakReference myShortWeakReferenceObject = new WeakReference( myObject );

When we use such a snippet of code to declare a weak reference object: WeakReference myShortWeakReferenceObject = new WeakReference( myObject );

垃圾收集器内部有一个短弱引用表，用这样声明的弱引用对象将不会在托管堆中分配空间，而是在短弱引用表中分配一个槽。此槽中记录对myObject的引用。New操作将此槽的地址返回给myShortWeakReferenceObject变量。

Garbage collector has a short weak reference table inside, the weak reference object declared in such a way will not allocate space from managed heap, and a slot will be allocated in the short weak reference table for the weak reference object. The slot records the referene of myObject. New operation returns the address of the slot to myShortWeakReferenceObject variable.

如果我们用这样的代码声明一个弱引用对象(我们要跟踪该对象的重生): WeakReference myLongWeakReferenceObject = new WeakReference( myAnotherObject, true );

When we use such a snippet of code to declare a weak reference object(We need to track resurrection of the object): WeakReference myLongWeakReferenceObject = new WeakReference( myAnotherObject, true );

垃圾收集器内部有一个长弱引用表，用这样声明的弱引用对象将不会在托管堆中分配空间，而是在长弱引用表中分配一个槽。此槽中记录对myAnotherObject的引用。New操作将此槽的地址返回给myLongWeakReferenceObject变量。

Garbage collector has a long weak reference table inside, the weak reference object declared in such a way will not allocate space from managed heap, and a slot will be allocated in the long weak reference table for the weak reference object. The slot records the referene of myAnotherObject. New operation returns the address of the slot to myLongWeakReferenceObject variable.

垃圾收集器此时的收集流程是这样的: The collecting process of garbage collector in this scenario is looking like the follwoing:

1. 垃圾收集器建立对象引用图，来找到所有的可到达对象。前文已经说过如何建立图。特别的地方是，如果遇到非WeakReference指针，就加入图，如果遇到WeakReference指针，就不加入图。这样图就建好了。Garbage collector builds up the reference ralationship graph to find all the reachable objects. The way to build up the graph is mentioned earlier. The special space is, if encounters a non-WeakReference pointer, then appends it to the graph, if meets a WeakReference pointer, then does not append it to the graph. The graph is built in this way.

2. 垃圾收集器扫描短弱引用表。如果一个指针指向一个不在图中的对象，那么此对象就是一个不可到达的对象，垃圾收集器就将短弱引用表相应的槽置空。Garbage collector scans the short weak reference table. If a pointer pointing to an object not in the graph, then the object is not a reachable object, and then garbage collector sets the slot to null in the short weak reference table.

3. 垃圾收集器扫描结束队列。如果队列中一个指针指向一个不在图中的对象，此指针将被从结束队列移到待结束队列，同时此对象被加入引用关系图中，因为此时此对象是Finalize可到达的。Garbage collector scans the Finalization queue. If a pointer in the queue pointing to an ojbect not in the graph, then the pointer will be moved to the ToBeFinalized queue, and the object will be appended to the reference relationship graph, because the object is Finalize reachable at this time.

4. 垃圾收集器扫描长弱引用表。如果一个指针指向一个不在图中的对象(注意此时图中已包含Finalize可到达的对象)，那么此对象就是一个不可到达的对象，垃圾收集器就将长弱引用表相应的槽置空。Garbage collector scans the long weak reference table. If a pointer pointing to an object not in the graph, then the object is not a reachable object, and then garbage collector sets the slot to null in the long weak reference table.
5. 垃圾收集器夯实(压缩)托管堆。 Garbage collector tamps(or compacts) the managed heap.
短弱引用不跟踪重生。即垃圾收集器发现一个对象为不可到达就立即将短弱引用表相应的槽置空。如果该对象有Finalize方法，并且Finalize方法还没有执行，所以该对象就还存在。如果应用程序访问弱引用对象的Target属性，即使该对象还存在，也会得到null。

Short weak reference does not track resurrection. It means that garbage collector sets the slot to null in the short weak reference table as soon as finds an object not reachable. If the object has a Finalize method, and its Finalize method has not been executed, then the object still exists. If the applicaiton accesses the Target property of the weak referene object, and gets null even though the object still exists.

长弱引用跟踪重生。即垃圾收集器发现一个对象是Finalize可到达的对象，就不将相应的槽置空。因为Finalize方法还没有执行，所以该对象就还存在。如果应用程序访问弱引用对象的Target属性，可以得到该对象；但是如果Finalize方法已经被执行，就表明该对象没有重生。

Long weak reference tracks resurrection. It means that garbage collector does not set the slot to null in the long weak reference table when garbage collector meets an object is Finalize reachable. Because the Finalize method has not been executed, the object still exists. If the application accesses the Target property of the weak reference object, and gets the object. But if the Finalize method has been executed, then the object is not resurrected.

按照上面的例子，如果执行如下代码会发生什么呢？Continue the above example, what will happen if we execute the following code?

//File: MyClass.cs
using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication2

美女小游戏打分装扮小游戏古装公主小游戏装扮仙女小游戏装扮男友小游戏婚纱礼服小游戏大头妹小游戏芭比娃娃小游戏布置房间小游戏照顾宝宝小游戏心理测试小游戏连连看对对碰找不同泡泡堂祖玛超级玛丽黄金矿工

{
    class MyClass
    {
        ~MyClass()
        {
            Console.WriteLine("In MyClass destructor+++++++++++++++++++++++++++");
        }
    }
}//File: MyAnotherClass.cs
using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication2
{
    public class MyAnotherClass
    {
        ~MyAnotherClass()
        {
            Console.WriteLine("In MyAnotherClass destructor___________________________________");
        }
    }
}//File: Program.cs
using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication2
{
    class Program
    {
        static void Main(string[] args)
        {
            MyClass myClass = new MyClass();
            MyAnotherClass myAnotherClass = new MyAnotherClass();
            WeakReference myShortWeakReferenceObject = new WeakReference(myClass);
            WeakReference myLongWeakReferenceObject = new WeakReference(myAnotherClass, true);
            Console.WriteLine("Release managed resources by setting locals to null.");
            myClass = null;
            myAnotherClass = null;

Console.WriteLine("Check whether the objects are still alive.");
CheckStatus(myShortWeakReferenceObject, "myClass ", "myShortWeakReferenceObject");
CheckStatus(myLongWeakReferenceObject, "myAnotherClass", "myLongWeakReferenceObject");

Console.WriteLine("Programmatically cause GC.");
GC.Collect();

Console.WriteLine("Wait for GC runs the finalization methods.");
GC.WaitForPendingFinalizers();

//Check whether the objects are still alive.
CheckStatus(myShortWeakReferenceObject, "myClass ", "myShortWeakReferenceObject");
CheckStatus(myLongWeakReferenceObject, "myAnotherClass", "myLongWeakReferenceObject");

Console.WriteLine("Programmatically cause GC again. Let's see what will happen this time.");
GC.Collect();

myAnotherClass = (MyAnotherClass)myLongWeakReferenceObject.Target;

Console.ReadLine();
}

static void CheckStatus(WeakReference weakObject, string strLocalVariableName, string strWeakObjectName)
        {
            Console.WriteLine(strLocalVariableName + (weakObject.IsAlive ? " is still alive." : " is not alive."));
            Console.WriteLine(strWeakObjectName + (weakObject.Target != null ? ".Target is not null." : ".Target is null."));
            Console.WriteLine();
        }
    }
}
请大家想一想如果MyAnotherClass类没有Finalize方法呢? Please think about what if the MyAnotherClass class does not have Finalize method.

或者:如果我们注释掉这行: GC.WaitForPendingFinalizers();, 试着多执行此代码多次, 看看每次会输出什么呢？是不是Finzalization方法被执行的时机不确定? Or, if we comment the line: GC.WaitForPendingFinalizers();, and try to execute the code multiple times, let’s see what will be the outputs. Is it that the time to execute Finalization methods is uncertain?

弱引用是为大对象准备的。在实际当中，如果不用弱引用，只用强引用，则用过了该大对象，然后将强引用置null，让GC可以回收它，但是没过多久我们又需要这个大对象了，但是已经没有办法找回原来的对象，只好重新创建实例，这样就浪费了创建实例所需的计算资源；而如果不置null，就会占用很多内存资源。对于这种情况，我们可以创建一个这个大对象的弱引用，这样在内存不够时将强引用置null，让GC可以回收，而在没有被GC回收前，如果我们短时间内还需要该大对象，我们还可以再次找回该对象，不用再重新创建实例。是不是节省了一些开销？

Weak reference is for large objects. In our daily practice, if we do not use weak reference, only use strong reference, it happens that we use a largae object and set it to null and let GC collect it, and we need the large object soon later, but there is no way find the original object back, we have to instanciate a new large object. That way we are wasting computer resources to create the old instance, but if we do not set the object to null, it occupies lot of memory. In this case, we can create a weak reference of the large object, and set strong reference object to null when there is not enough memory and let GC collect the large object, and we can find the large object back when we have requirement before the large object has not been collected by GC. No need to create a new instance, does this way save costs?

垃圾收集的一般流程The common process of garbage collection
以下是垃圾收集的一般流程，受应用场景(如服务器应用，并发和非并发)影响，具体的垃圾回收流程可能有所不同。The following is the common process of garbage collection, because of different scenarios and factors(like server application scenario, concurrent or non-concurrent), the actual processes are a little different.

1. 挂起.net应用的所有线程Suspend all the threads of .net application

2. 找到可回收的对象Find all the reclaimable objects

3. 回收可回收的对象并压缩托管堆Reclaim the reclaimable objects and compact the managed heap

4. 继续.net应用的所有线程Resume all the threads of .net application

垃圾收集的模式The modes of Garbage collection
CLR4.0之前，一共有三种模式的GC，分别针对不同类型的应用程序而优化：Server版非并发GC, Workstation版并发GC, 和Workstation版非并发GC. Before CLR 4.0, there are three different modes of GC, which are optimized for different types of applications: Server version Non–concurrent GC, Workstation version concurrent GC, and Workstation version Non-concurrent GC.

Server GC - Non Concurrent
Server GC是针对服务器应用而进行优化的，目的是为了保证其高吞吐量和高的规模可扩展性。The server non-concurrent GC is optimized for high throughput and high scalability in server applications.

Server GC 为每一个处理器分配一个托管堆和一个GC线程。各GC线程独立工作在各自的堆上，这样最大程度地减少了锁，从而保证了此种情况下的高效。这些GC线程是非并发的（第0代，第1代，第2代都是非并发的，即在收集时都要停止所有应用程序的线程，直到收集结束）。同时这些GC线程是专门的线程，不同于应用程序的线程。The server GC allocates one heap and one GC thread for each of processors. The GC threads work on their respective heaps, and this minimizes the possibilities to lock resources, and ensures high efficiency in the server situation. The GC threads are non-concurrent(Gen 0, Gen 1 and Gen 2 are non concurrent, meaning that garbage collector suspends all the threads of application at collecting cycles of generations until the collecting finishes). Meanwhile the GC threads are dedicated threads, different from the threads of application.

实际的Server GC工作流程是这样的:The actual work flow of server GC is looking like the following:

1. 应用程序的线程在其托管堆上分配空间The application threads are doing allocations on their corresponding managed heap;

2. 其托管堆没有更多空间来分配托管对象They run out of allocations on the heaps their allocating on;

3. 于是触发一个事件，让GC线程来做收集，并等待GC线程完成收集That signals an event to wake the GC threads to do a GC and waits for it to finish;

4. GC线程运行，完成收集并发出完成事件(在GC线程运行期间，应用程序线程是暂停的)GC threads run, finish with the GC and signal an event that says GC is complete (When GC is in progress, all the application threads are suspended);

5. 应用程序的线程继续运行The application threads resume running.

这种类型的GC只有在多处理器的机器上可见，如果你在单处理器上的设置这种模式，那你将得到workstation版本非并发的GC。The Server Non-concurrent GC is only available on multi processor machines. If you try to set the server GC on a machine with single processor you will instead get the workstation version with non concurrent GC.

Asp.net的应用在多cpu的机器上默认使用这种模式，还有其他一些类型的服务器应用也在多cpu的机器上使用这种模式。例如如果你想在Windows服务上使用server GC模式，你可以在应用程序配置文件中做如下设置：ASP.NET applications use the mode by default on multiproc machines, as well as a number of other types of server applications. For example, if you want to use the server GC in a windows service you can do so by setting in the application’s config file:

Workstation GC – Concurrent
Winform应用程序和Windows services 服务程序默认采用这种模式。This is the default setting for win forms applications and windows services.

这种模式是针对交互式应用程序优化的，这种程序要求应用程序不能暂停，即使是一个相对很短暂的时间也是不行的。因为暂停进程会让用户界面闪烁或者当点击按钮的时候感觉应用程序没有响应。The Workstation GC is optimized for interactive applications that can’t allow for the application to be paused even for relatively short periods since pausing the threads would cause flicker in the user interface or make the application feel non responsive to button clicks etc.

在这种模式下，第0代和第1代的收集仍然是要暂停应用程序的线程直到收集完毕，因为第0代和第1代的收集速度很快，所以没有必要去做并行。所谓的并发是在需要第2代收集时，我们可以选择让第2代收集并行地执行或者暂停应用程序的所有线程直到收集结束。如果我们没有做选择，那么默认的就是第2代收集是并行的。In this mode, the collection of gen 0 and gen 1 still need to pause all the threads of application until the collection of gen 0 and gen 1 finishe. Since the gen 0 and gen 1 collections are very fast, it does not make sense to have concurrent GC when we do gen 0 and gen 1 collections. The concurrent is that we can choose whether we do concurrent collection when it is gen 2 collection or suspend all the threads of application until the collection finish. If we do not make the choice, then the default is that the gen 2 collection is concurrent.

有一个专门的GC线程来并行地收集垃圾。在第2代收集时，用更多CPU周期和堆内存来换取更短的用户界面停顿时间。There is a dedicated GC thread collecting garbage in parallel mode. This is done by trading a little bit more CPU cycles and heap memory usage for shorter UI pause time when doing gen 2 collections.

并行收集仍然需要在收集过程中暂停应用程序多次，但这几次暂停相对较短，对UI线程影响较小。应用程序线程在并行收集进行中可以同时分配对象。这就要求第0代有较大的空间和较高的触发Gen 0收集的阀值。如果应用程序用完第0代的内存，而并行收集还没有进行完毕，那么应用程序不得不暂停下来，等待并行收集的完成。Concurrent collection still needs to suspend the application multiple times during the concurrent collecting cycle. , but the the times of pause are shorter than usual, have less impact on the UI thread. The application can allocate objects while the concurrent collection is going on. This requires that the gen 0 has bigger space and higher threshold to trigger collection on gen 0. If the application exhausts the memory of gen 0, and the concurrent collection is not finished, then the application has to suspend to wait for the concurrent collection finishes.

如果我们要做选择，让应用程序在并行模式下运行，可以在应用程序的config文件中写上: If we make the choice to let the application run under concurrent mode, please leave this in the config file of the application.

</runtime>

</configuration>

注: Jeffrey Richter似乎在其书<<CLR via c#>>中说concurrent GC只有在多CPU机器上有。但是经过Mark的调查，实际上concurrent GC在单CPU上也有。

Note: Jeffrey Richter seemed to mention in his book <<CLR via c#>> that concurrent GC is only available on multiple CPUs machine, but according to Mark’s investigation, concurrent GC is also available on single CPU machine.

Workstation GC – Non Concurrent
这种模式与Server GC类似，推荐为那种运行在单个cpu机器上服务类型的应用程序使用。与Server GC不同的是：其收集线程即等同于应用程序线程。这是这种模式的工作流程：The mode is similar to the Server GC mode, and is recommended for the server applications running on single processor machine. The collection happens on the same threads of application, which is different from what the Server GC does. The following is the work flow of the mode:

1) 应用程序线程在堆上分配对象Application threads are doing allocations on the heap;

2) 第0代没有足够空间It runs out space in gen 0.

3) 在同一线程上引发垃圾收集It triggers a GC which will be running on this very thread;

4) 垃圾收集器调用SuspendEE函数暂停应用程序线程GC calls SuspendEE to suspend the application’s threads;

5) GC做收集工作GC does its work;

6) GC调用RestartEE来继续应用程序的线程GC calls RestartEE to restart the application’s threads;

7) 应用程序的线程继续运行Application threads start running again.

可以修改应用程序的配置来把 concurrency 关闭。We could close concurrency using the following setting in the application’s config file.

下面是三种模式的对比表This is the comparison matrix of the modes:

Concurrent WS
Non-Concurrent WS
Server GC

Design Goal
Balance throughput and responsiveness for client apps with UI
Maximize throughput on single-proc machines
Maximize throughput on MP machines for server apps that create multiple threads to handle the same types of requests

Number of heaps
1
1
1 per processor (HT aware)

GC threads
The thread which performs the allocation that triggers the GC
The thread which performs the allocation that triggers the GC
1 dedicated GC thread per processor

Execution Engine Suspension
EE is suspended much shorter but several times during a GC
EE is suspended during a GC
EE is suspended during a GC

Config setting
<gcConcurrent enabled="true">
<gcConcurrent enabled="false">
<gcServer enabled="true">

On a single processor machine
WS GC + non-concurrent

以上我们说到了CLR 4.0以前垃圾收集的大部分方面。掌握前面的知识有助于理解CLR 4.0所带来的变化。We introduced most of aspects of garbage collection prior to CLR 4.0. Master the legacy to help undetstand the changes CLR 4.0 brings in.

CLR 2.0以后GC有哪些变化呢?What are the changes since CLR 2.0?
CLR V4.0带来的后台垃圾收集The background GC brought to you by CLR 4.0
前面我们已经提到已经有了并发垃圾收集。后台垃圾收集是来替代并发垃圾收集。后台垃圾收集是并发垃圾收集的进化。We mentioned there has been concurrent GC. Background GC is to replace concurrent GC. Background GC is an evolution to concurrent GC.

当应用程序的活动量不大(包括分配和修改引用)并且堆不太大时，并发垃圾收集工作得好。由并发垃圾收集带来的延迟是可接受的。但是当人们编写更大的应用程序，需要用到更大的堆，这时由并发收集带来的延迟就变得不可接受。When the program activity (including making allocations and modifying references) is not really high and the heap is not very large concurrent GC works well – the latency caused by the GC is reasonable. But as people start writing larger applications with larger heaps that handle more stressful situations, the latency can be unacceptable.

后台垃圾收集的显著改进是：在后台垃圾收集进行中，如果需要的话，我们可以做短的垃圾收集(第0代和第1代收集)。与并发垃圾收集类似，后台垃圾收集也是只有在全部垃圾收集时才有。并且短的垃圾收集(第0代和第1代收集)总是按阻断方式进行垃圾收集(暂停应用程序)。后台垃圾收集在一个专门的线程上运行。那些与后台垃圾收集同时进行的短垃圾收集(第0代和第1代收集)被称为前台垃圾收集。

The significance of background GC is we can do ephemeral GCs(gen 0 and gen 1 GC) while a background GC is in progress if needed. As with concurrent GC, background GC is also only applicable to full GCs and ephemeral GCs are always done as blocking GCs(suspend the application), and a background GC is also done on its dediated GC thread. The ephemeral GCs(gen 0 and gen 1 GC) done while a background GC is in progress are called foreground GCs.

于是，当后台垃圾收集正进行中而第0代空间不足，就会触发一个第0代垃圾收集(有可能升级成第1代收集，取决于垃圾收集器的内部决策)。后台垃圾收集线程会经常检查安全点(比如前台垃圾收集发生)。当有前台垃圾收集时，后台垃圾收集会自己暂停并让前台垃圾收集可以开始开始工作。在前台垃圾收集完成之后，后台垃圾时线程和应用程序的线程就继续它们的工作。

So when a background GC is in progress and you’ve allocated enough in gen0, we will trigger a gen0 GC (which may stay as a gen0 GC or get elevated as a gen1 GC depending on GC’s internal tuning). The background GC thread will check at frequent safe points (ie, when we can allow a foreground GC to happen) and see if there’s a request for a foreground GC. If so it will suspend itself and a foreground GC can happen. After this foreground GC is finished, the background GC thread and the user threads can resume their work.

后台垃圾收集不仅在较低的代将无用的对象清除，同时它提高了对象停留在短生命周期段的限制--如果后台垃圾收集进行中需要扩展堆，我们可以在第1代收集时这样做。而这在CLR1.0和CLR2.0只有在第2代收集时才会发生。

Not only does this allow us to get rid of dead objects in young generations, it also lifts the restriction of having to stay in the ephemeral segment – if we need to expand the heap while a background GC is going on, we can do so in a gen1 GC. In CLR1.0 and CLR 2.0, this only happens when gen 2 GC .

后台垃圾收集比并发收集的好处体现在：在后台收集进行中，应用程序耗尽了第0代的空间，如果是并发收集，应用程序必须暂停以等待并发收集完成。而现在不同了，可以用前台收集对第0代或者第1代进行收集。于是就不必等待。同时，如果需要，可以在第1代收集就扩展堆(增加内存段)，而不必等到第2代收集。这减少了让UI应用程序暂停的机会。Advantages of Background GC(versa to concurrent GC) are : During background GC, the application runs out memory in gen 0, if it is concurrent GC, the application has to suspend and wait for the finish of concurrent GC. But now it is different, we can use forground GC to do collection on gen 0 or gen 1. therefore no need to wait for the finish of concurrent GC. And meanwhile, we can expand the heap(by adding new memory segment) at gen 1 if required, do not have to wait until gen 2 GC. These minimize the possibilities to suspend the UI application.

我们通过并行地做更多事情改进了后台垃圾收集的性能，所以需要暂停应用程序线程的时间更短。我们现在没有在CLRV4.0中为Server GC提供后台垃圾收集。那将是后续的工作。We also made some performance improvement in background GC which does better at doing more things concurrently so the time we need to suspend managed threads is also shorter. We are not offering background GC for server GC in V4.0. That is coming work.

.net 3.5 SP1中的全部收集通知机制Full GC notification in .net 3.5 SP1
全部收集通知机制是为担负大量请求的服务器应用准备的。因为存在一些情况，CLR的全部收集会带来较大的延迟，从而影响服务器应用的性能，导致用户请求超时。针对这种情况，全部收集通知机制应运而生。当一个全垃圾收集将要开始时，你会得到通知并可以采取相应动作，如将请求导向别的服务器。

.net 3.5 SP1的GC类增加了几个方法:

GC.RegisterForFullGCNotification

GC.WaitForFullGCApproach

GC.WaitForFullGCComplete

GC.CancelFullGCNotification

并在System命名空间下增加了一个枚举

GCNotificationStatus

这个GC.RegisterForFullGCNotification 用来注册当前应用将要接收全部垃圾收集的通知。当一个全部垃圾收集将要发生时，注册了的应用程序就可收到通知。同时，当一个全部垃圾收集完成时，注册了的程序也会收到通知。这是GC.RegisterForFullGCNotification 的申明方式:

[PermissionSetAttribute(SecurityAction.LinkDemand, Name = "FullTrust")]
public static void RegisterForFullGCNotification(
int maxGenerationThreshold,
int largeObjectHeapThreshold
)maxGenerationThreshold是1-99之间的数.指的是第2代中存活的对象个数达到这个阀值就要通知. largeObjectHeapThreshold也是1-99之间的数.指的是大对象堆中分配的对象个数达到这个阀值就要通知.

WaitForFullGCApproach用来获得垃圾收集器是否将要进行全部垃圾收集. 它的声明是这样的:

[PermissionSetAttribute(SecurityAction.LinkDemand, Name = "FullTrust")]
public static GCNotificationStatus WaitForFullGCApproach()或者[PermissionSetAttribute(SecurityAction.LinkDemand, Name = "FullTrust")]
public static GCNotificationStatus WaitForFullGCApproach(
int millisecondsTimeout
)第2个调用方式可以带一个等待时间, 单位是毫秒. 其返回的是枚举GCNotificationStatus, 如果是GCNotificationStatus.Succeeded, 那么我们就可以将请求导向其他服务器.与WaitForFullGCApproach类似的, WaitForFullGCComplete用来获得垃圾收集器是否已经完成全部垃圾收集, 它的声明是这样的:

[PermissionSetAttribute(SecurityAction.LinkDemand, Name = "FullTrust")]
public static GCNotificationStatus WaitForFullGCComplete()或者

[PermissionSetAttribute(SecurityAction.LinkDemand, Name = "FullTrust")]
public static GCNotificationStatus WaitForFullGCComplete(
int millisecondsTimeout
)第2个调用方式可以带一个等待时间, 单位是毫秒. 其返回的是枚举GCNotificationStatus, 如果是GCNotificationStatus.Succeeded, 那么我们就可以将此服务器重新声明可以接受外界的请求.

WaitForFullGCApproach和WaitForFullGCComplete设计时就是要一起使用的。如果只使用一个而不使用另一个就会导致不可知的结果。

GC.CancelFullGCNotification是用来将已经注册的垃圾收集通知取消. 与GC.RegisterForFullGCNotification 一起成对配合使用.

通常的使用方法是这样的:

1.首先在主线程调用GC.RegisterForFullGCNotification 来准备收获通知

2.启动一个值守线程, 在值守线程中调用WaitForFullGCApproach和WaitForFullGCComplete来获取当前GC状态, 如果是将要进行全部垃圾收集，就做相应处理，如将请求导向其他服务器。如果是全部垃圾收集完毕，则可做相应处理, 如将此服务器标记为可接受请求.值守线程中需要不断循环来轮循GC状态.

3.当主线程将要结束, 调用GC.CancelFullGCNotification并发消息通知值守线程, 值守线程退出循环，结束.

4.主线程退出

对于asp.net应用, 可以在Application_Start中调用GC.RegisterForFullGCNotification并启动一个值守线程. 同时可以在Application_End中通知值守线程结束.

全部垃圾收集通知机制的典型用途就是在多服务器的场景.用NLB(Network load balance)搭建的Web Farm或者硬件load balance的多服务器场景. 一个比较复杂的场景是每个服务器上还有web garden设置.

注意事项: 全部垃圾收集通知机制只有在非并发模式时才可用. WinForm和Console应用都是默认为并发模式. 例如msdn上的那个例子程序，就需要在程序的app.config中加上

全文完. 谢谢各位!

参考文献References

Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework By Jeffrey Richter http://msdn.microsoft.com/en-us/magazine/bb985010.aspx

Garbage Collection Part 2: Automatic Memory Management in the Microsoft .NET Framework By Jeffrey Richter http://msdn.microsoft.com/en-us/magazine/bb985011.aspx

Garbage Collector Basics and Performance Hints By Rico Mariani at Microsoft http://msdn.microsoft.com/en-us/library/ms973837.aspx

http://drowningintechnicaldebt.com/blogs/royashbrook/archive/2007/06/22/top-20-net-garbage-collection-gc-articles.aspx

Large Object Heap Uncovered By Maoni Stephens http://msdn.microsoft.com/en-us/magazine/cc534993.aspx

Garbage collection in msdn http://msdn.microsoft.com/en-us/library/0xy59wtx.aspx

How does the GC work and what are the sizes of the different generations? By Tess Ferrandez http://blogs.msdn.com/tess/archive/2008/04/17/how-does-the-gc-work-and-what-are-the-sizes-of-the-different-generations.aspx

So, what’s new in the CLR 4.0 GC? By Maoni Stephens http://blogs.msdn.com/maoni/archive/2008/11/19/so-what-s-new-in-the-clr-4-0-gc.aspx

Using GC Efficiently – Part 1 http://blogs.msdn.com/maoni/archive/2004/06/15/156626.aspx

Using GC Efficiently – Part 2 http://blogs.msdn.com/maoni/archive/2004/09/25/234273.aspx

Using GC Efficiently – Part 3 http://blogs.msdn.com/maoni/archive/2004/12/19/327149.aspx

Using GC Efficiently – Part 4 http://blogs.msdn.com/maoni/archive/2005/05/06/415296.aspx

The mystery of concurrent GC http://www.julmar.com/blog/mark/PermaLink,guid,3670d081-0276-48e6-b97d-1b644093b52e.aspx

http://blogs.msdn.com/clyon/archive/2004/09/10/228104.aspx

http://blogs.msdn.com/clyon/archive/2004/09/08/226981.aspx

http://msdn.microsoft.com/en-us/library/cc713687.aspx

本文链接

.net CLR 4.0对垃圾回收机制的改进2

2010-02-19T23:11:00Z

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所带来的变化仍然没有在这篇，请看下篇。

内存释放和压缩
创建对象引用图之后，垃圾回收器将那些没有在这个图中的对象(即不再需要的对象)释放。释放内存之后, 出现了内存碎片, 垃圾回收器扫描托管堆，找到连续的内存块，然后移动未回收的对象到更低的地址, 以得到整块的内存，同时所有的对象引用都将被调整为指向对象新的存储位置。这就象一个夯实的动作。

After building up the reference relationship graph, garbage collector reclaims the objects not in the graph(no longer needed), after releasing the objects not in the graph, there is memory scrap. Garbage collector scans the managed heap to find continous memory block, and shifts the remaining objects to lower address to get consecutive memory space, and then adjusts the references of objects according to the shifted address of objects. This is looking like a tamping on the managed heap.

下面要说到的是代的概念。代概念的引入是为了提高垃圾收集器的整体性能。We come to the concept of generations next. The importing of generation concept is to improve the performance of garbage collector.

代Generations
请想一想如果垃圾收集器每次总是扫描所有托管堆中的对象，对性能会有什么影响。会不会很慢？是的。微软因此引入了代的概念。

Please think about what will happen if garbage collector scans all the objects in the whole heap in every garbage collecting cycle. Will it be very slow? Yes, therefore Microsoft imported the concept of generations.

为什么代的概念可以提高垃圾收集器的性能？因为微软是基于对大量编程实践的科学估计，做了一些假定而这些假定符合绝大多数的编程实践:

Why generation concept can help improve performance of garbage collector? Because Microsoft did scientific valuation on mass of programming practice, and made assumptions and the assumptions conform to most of programming practice:

越新的对象，其生命周期越短。The newer an object is, the shorter its lifetime will be.
越老的对象，其生命周越长。The older an object is, the longer its lifetime will be.
新对象之间通常有强的关系并被同时访问。Newer objects tend to have strong relationships to each other and are frequently accessed around the same time.
压缩一部分堆比压缩整个堆快。Compacting a portion of the heap is faster than compacting the whole heap.
有了代的概念，垃圾回收活动就可以大部分局限于一个较小的区域来进行。这样就对垃圾回收的性能有所提高。After importing the concept of generations, most of garbage collecting will be limited in in smaller range of memory. This enhances the performance of garbage collector.

让我们来看垃圾收集器具体是怎么实现代的: Let’s see how generations are exactly implemented in garbage collector:

第0代：新建对象和从未经过垃圾回收对象的集合 Generation 0: A collection of newly created object and the objects never collected.

第1代：在第0代收集活动中未回收的对象集合 Generation 1: A collection of objects not collected by garbage collector in collecting cycle of generation 0.

第2代：在第1和第2代中未回收的对象集合, 即垃圾收集器最高只支持到第2代, 如果某个对象在第2代的回收活动中留下来，它仍呆在第2代的内存中。 Generation 2: A collection of objects not collected by garbage collector in generation 1 and generation 2. This means the highest generation that garbage collector supports is generation 2. If an object survives in generation 2 collecting cycle, it still remains in memory of generation 2.

当程序刚开始运行，垃圾收集器分配为每一代分配了一定的内存，这些内存的初始大小由.net framework的策略决定。垃圾收集器记录了这三代的内存起始地址和大小。这三代的内存是连接在一起的。第2代的内存在第1代内存之下，第1代内存在第0代内存之下。应用程序分配新的托管对象总是从第0代中分配。如果第0代中内存足够，CLR就很简单快速地移动一下指针，完成内存的分配。这是很快速的。当第0代内存不足以容纳新的对象时，就触发垃圾收集器工作，来回收第0代中不再需要的对象，当回收完毕，垃圾收集器就夯实第0代中没有回收的对象至低的地址，同时移动指针至空闲空间的开始地址(同时按照移动后的地址去更新那些相关引用)，此时第0代就空了，因为那些在第0代中没有回收的对象都移到了第1代。

When the program initializes, garbage collector allocates memory for generations. The initial size of memory blocks are determined according to the strategies of the .net framework. Garbage collector records the start address and size of the memory block for generations. The memory blocks of generations are continuous and adjacent. The memory of generation 2 is under the memory of generation 1, and the memory of generation 1 is under the memory of generation 0. CLR always allocates memory for new objects in generation 0. If there is enough memory in generation 0, CLR simply moves the pointer to allocate memory. This is really fast. When there is not enough memory in generation 0 to accommodate new objects, CLR triggers garbage collector starts to collect objects no longer needed from generation 0. When the collecting action in generation 0 finishs, garbage collector tamps(or compacts) the objects not collected in generation 0 to lower address, and moves the pointer to start address of free memory(and updates the related references according to the shifted address of objects). At this time, generation 0 is empty, because the objects survived in generation 0 are moved to generation 1.

当只对第0代进行收集时，所发生的就是部分收集。这与之前所说的全部收集有所区别(因为代的引入)。对第0代收集时，同样是从根开始找那些正引用的对象，但接下来的步骤有所不同。当垃圾收集器找到一个指向第1代或者第2代地址的根，垃圾收集器就忽略此根，继续找其他根，如果找到一个指向第0代对象的根，就将此对象加入图。这样就可以只处理第0代内存中的垃圾。这样做有个先决条件，就是应用程序此前没有去写第1代和第2代的内存，没有让第1代或者第2代中某个对象指向第0代的内存。但是实际中应用程序是有可能写第1代或者第2代的内存的。针对这种情况，CLR有专门的数据结构(Card table)来标志应用程序是否曾经写第1代或者第2代的内存。如果在此次对第0代进行收集之前，应用程序写过第1代或者第2代的内存，那些被Card Table登记的对象(在第1代或者第2代)将也要在此次对第0代收集时作为根。这样，才可以正确地对第0代进行收集。

When collecting generation 0 only, it is partial collection. It is different from full collection mentioned earlier(because of the generations). When collecting generation 0, garbage collector starts from the roots, which is the same as the full collection, but it is different in coming steps. When garbage collector finds a root pointing to an address of generation 1 or 2, garbage collector ignores the root, and goes to next root. If garbage collector finds a root pointing to an object of generation 0, garbage collector addes the object into the graph. That way garbage collector processes the objects of generation 0 only. There is a pre-condition to do that. It is that the application does not write to the memory of generation 1 and 2, does not allow some objects of generation 1 or 2 refer to the memory of generation 0. But in our daily work, the applicaiton is possible to write the memory of generation 1 or 2. In this case, CLR has a dedicated data structure called Card Table to record whether the application writes the memory of generation 1 or 2. If the application writes the memory of generation 1 or 2 before the collecting on generation 0, the objects recorded by the Card Table will become roots during the collecting on generation 0. Garbage collection on generation 0 can be done correctly in this case.

以上说到了第0代收集发生的一个条件，即第0代没有足够内存去容纳新对象。执行GC.Collect()也会触发对第0代的收集。另外，垃圾收集器还为每一代都维护着一个监视阀值。第0代内存达到这个第0代的阀值时也会触发对第0代的收集。对第1代的收集发生在执行GC.Collect(1)或者第1代内存达到第1代的阀值时。第2代也有类似的触发条件。当第1代收集时，第0代也需要收集。当第2代收集时，第1和第0代也需要收集。在第n代收集之后仍然存留下来的对象将被转移到第n+1代的内存中，如果n=2, 那么存留下来的对象还将留在第2代中。

We mentioned a criteria to trigger collecting on generation 0 in above paragraphs: generation 0 does not have enough memory to accommodate new objects. When execute GC.Collect(), it launches collecting on generation 0 also. In addition, garbage collector sets up a threshold for each of generations. When the memory of generation 0 reaches the threshold, collecting on generation 0 happens also. Collecting on generation 1 happens when executing GC.Collect() or the memory of generation 1 reaches the threshold of generation 1. Generation 2 has similar trigger conditions. When collecting on generation 1, collecting on generation 0 happens also. When collecting on generation 2, collecting on generation 1 and 0 happen also. The survived object in collecting generation n will be moved to the memory of generation n+1. If n=2, the remaining objects still stay in generation 2.

对象结束Finalization of objects
对象结束机制是程序员忘记用Close或者Dispose等方法清理申请的资源时的一个保证措施。如下的一个类，当一个此类的实例创建时，在第0代中分配内存，同时此对象的引用要被加入到一个由CLR维护的结束队列中去。

Finalization is an ensuring mechanism when programmers forget to use Close or Dispose method to clean up resources. For exmaple, a class like the following, when an instane of the class is created, it is allocated in memory of generation 0, and a reference of the object is appended to Finalization queue maintained by CLR.

public class BaseObj { public BaseObj() { } protected override void Finalize() { // Perform resource cleanup code here... // Example: Close file/Close network connection Console.WriteLine("In Finalize."); }}当此对象成为垃圾时，垃圾收集器将其引用从结束队列移到待结束队列中，同时此对象会被加入引用关系图。一个独立运行的CLR线程将一个个从待结束队列(Jeffrey Richter称之为Freachable queue)取出对象，执行其Finalize方法以清理资源。因此，此对象不会马上被垃圾收集器回收。只有当此对象的Finalize方法被执行完毕后，其引用才会从待结束队列中移除。等下一轮回收时，垃圾回收器才会将其回收。

When the object becomes garbage, garbage collector moves the reference from Finalization queue to ToBeFinalized queue(Jeffrey Richter called it Freachable queue), and appends the object to the reference graph. A standalone thread of CLR will fetch objects from the ToBeFinalized queue one by one, and execute the Finalize() method of objects to clean up resources. Therefore, the object will not be collected right away by garbage collector. After the Finalize() method is executed, its reference will be removed from the ToBeFinalizaed queue. When next collecting comes, garbage collector reclaims its memory.

GC类有两个公共静态方法GC.ReRegisterForFinalize和GC.SuppressFinalize大家也许想了解一下，ReRegisterForFinalize是将指向对象的引用添加到结束队列中(即表明此对象需要结束)，SuppressFinalize是将结束队列中该对象的引用移除，CLR将不再会执行其Finalize方法。

There are two public static methods of GC class you guys may want to know: GC.ReRegisterForFinalize and GC.SuppressFinalize. ReRegisterForFinalize is to append the reference of objects to finalization queue(meaning the objects need to be finalized), SuppressFinalize is to remove the reference of objects from finalization queue, then CLR would not execute the Finalize method of the object.

因为有Finalize方法的对象在new时就自动会加入结束队列中，所以ReRegisterForFinalize可以用的场合比较少。ReRegisterForFinalize比较典型的是配合重生(Resurrection)的场合来用。重生指的是在Finalize方法中让根又重新指向此对象。那么此对象又成了可到达的对象，不会被垃圾收集器收集，但是此对象的引用未被加入结束队列中。所以此处需要用ReRegisterForFinalize方法来将对象的引用添加到结束队列中。因为重生本身在现实应用中就很少见，所以ReRegisterForFinalize也将比较少用到。

Because the objects with Finalize method will be appended to Finalization queue when new operation, there are few scenarios to use ReRegisterForFinalize method. A typical scenario is to use ReRegisterForFinalize with Resurrection. Resurrection is that we let a root point to the object again in Finalize method, and then the object becomes reachable again, therefore it will be not collected by garbage collector. But the reference of the object has not been appended to Finalization queue, therefore we can use ReRegisterForFinalize to append the object to Finalization queue. Because there are few requirement in reality to use resurrection, ReRegisterForFinalize will be used in low rate.

相比之下，SuppressFinalize更常用些。SuppressFinalize用于同时实现了Finalize方法和Dispose()方法来释放资源的情况下。在Dispose()方法中调用GC.SuppressFinalize(this)，那么CLR就不会执行Finalize方法。Finalize方法是程序员忘记用Close或者Dispose等方法清理资源时的一个保证措施。如果程序员记得调用Dispose()，那么就会不执行Finalize()来再次释放资源；如果程序员忘记调用Dispose(), Finalize方法将是最后一个保证资源释放的措施。这样做不失为一种双保险的方案。

Comparing to ReRegisterForFinalize, SuppressFinalize has more frequent utilization. When we implement both Finalize method and Dispose method to release resources, we need to use SuppressFinalize method. Call GC.SuppressFinalize(this) in the body of Dispose() method and then CLR will not execute the Finalize method. Finalization is an ensuring mechanism when programmers forget to use Close or Dispose method to clean up resources. If programmers do call Dispose(), then CLR will not call Finalize method to release resources again. If programmers forget to call Dispose(), then Finalize method will be the final ensuring mechnism for resource releasing. That way it is a dual fail-safe solution.

对象结束机制对垃圾收集器的性能影响比较大，同时CLR难以保证调用Finalize方法的时间和次序。因此，尽量不要用对象结束机制，而采用自定义的方法或者名为Close, Dispose的方法来清理资源。可以考虑实现IDisposable接口并为Dispose方法写好清理资源的方法体。

Finalization has significant impact on performance of garbage collector, and CLR can not be sure on the time and order to call Finalize methods of objects, therefore please do not use finalization of objects as possible as you can, instead, you could use self defined methods, Close method or Dispose method to clean up resources. Please think about to implement the IDisposable interface and write method body for the Dispose method to clean up resources.

大对象堆Large object heap
大对象堆专用于存放大于85000字节的对象。初始的大对象内存区域堆通常在第0代内存之上，并且与第0代内存不邻接。第0,第1和第2代合起来称为小对象堆。CLR分配一个新的对象时，如果其大小小于85000字节，就在第0代中分配，如果其大小大于等于85000自己，就在大对象堆中分配。

Large object heap is to store objects that its size is over 85000 bytes. The initial memory block of large object heap is above the memory block of generation 0, and it is not adjacent to memory block of generation 0. Generation 0,1 and 2 is called small object heap. When CLR allocates a new object, if its size is lower than 85000 bytes, then allocates memory in generation 0; If its size is over 85000 bytes, then allocates memory in large object heap.

因为大对象的尺寸比较大，收集时成本比较高，所以对大对象的收集是在第2代收集时。大对象的收集也是从根开始查找可到达对象，那些不可到达的大对象就可回收。垃圾收集器回收了大对象后，不会对大对象堆进行夯实操作(毕竟移动大对象成本较高)，而是用一个空闲对象表的数据结构来登记哪些对象的空间可以再利用，其中两个相邻的大对象回收将在空闲对象表中作为一个对象对待。空闲对象表登记的空间将可以再分配新的大对象。

Because size of large object is significant, the cost of collection is significant also. Collection of large objects happens when collecting generation 2. Collection of large objects starts from the roots also and searches for reachable objects. Non-reachable large objects will be collected. After collecting non-reachable large objects, garbage collector will not tamp the large object heap(because the cost of moving a large object is high), instead, garbage collector uses a free object table to record memory ranges that can be re-used, if there are two adjacent large object collected, then treats the two large objects as one large object in free object table. The memory ranges in free object table can be re-used by new large objects.

大对象的分配，回收的成本都较小对象高，因此在实践中最好避免很快地分配大对象又很快回收，可以考虑如何分配一个大对象池，重复利用这个大对象池，而不频繁地回收。

The cost of allocation and collection of large objects is higher than the cost of allocation and collection of small objects, therefore it would better avoid to allocate large object and release it soon. Please think about allocate a pool of large objects, try to re-use the pool of large objects, do not frequently reclaim large objects.

未完待续To be continued…

参考文献References

Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework By Jeffrey Richter http://msdn.microsoft.com/en-us/magazine/bb985010.aspx

Garbage Collection Part 2: Automatic Memory Management in the Microsoft .NET Framework By Jeffrey Richter http://msdn.microsoft.com/en-us/magazine/bb985011.aspx

Garbage Collector Basics and Performance Hints By Rico Mariani at Microsoft http://msdn.microsoft.com/en-us/library/ms973837.aspx

http://drowningintechnicaldebt.com/blogs/royashbrook/archive/2007/06/22/top-20-net-garbage-collection-gc-articles.aspx

Large Object Heap Uncovered By Maoni Stephens http://msdn.microsoft.com/en-us/magazine/cc534993.aspx

Garbage collection in msdn http://msdn.microsoft.com/en-us/library/0xy59wtx.aspx

本文链接

.net CLR 4.0对垃圾回收机制的改进

2010-02-19T11:11:00Z

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.

未完待续To be continued…

参考文献References
Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework By Jeffrey Richter http://msdn.microsoft.com/en-us/magazine/bb985010.aspx

Garbage Collection Part 2: Automatic Memory Management in the Microsoft .NET Framework By Jeffrey Richter http://msdn.microsoft.com/en-us/magazine/bb985011.aspx

Garbage Collector Basics and Performance Hints By Rico Mariani at Microsoft http://msdn.microsoft.com/en-us/library/ms973837.aspx

http://drowningintechnicaldebt.com/blogs/royashbrook/archive/2007/06/22/top-20-net-garbage-collection-gc-articles.aspx

本文链接

测一测你的浏览器

2010-02-19T10:40:00Z

Acid3 测试
Acid3 由网页标准计划小组（Web Standards Project，WaSP）设计，是一份网页浏览器及设计软件之标准兼容性的测试网页，于 2008年3月3日正式发布。更多关于Acid3的信息，您可以查看Acid3维基百科
要得到100分才算完整通过Acid3测试，Chrome是目前为数不多的满分通过测试的浏览器。
点此测试

Javascript性能测试
从各种常用指令的执行速度上，衡量浏览器Javascript性能，测试结果是毫秒，越小越好
点此测试

谷歌提供的V8测试
一个较纯粹的脚本性能测试，分数越高越好
点此测试

本文链接

每个人都宣称自己是别人-译稿:UserAgent的历史变迁

2010-02-14T12:45:00Z

刚看到园子的一篇文章提到UserAgent的那些事,本人顺藤摸瓜，找到了这篇译稿，一看还挺有趣的，发到首页也给大家新年娱乐一回！

Google推出的Chrome让大家热议纷纷，只有专业用户才会注意到用Chrome访问网页时发出的“Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13”UserAgent字符串，貌似天书，它到底是怎么回事儿代表什么呢？我们来看看吧.

　　最早的时候有一个浏览器叫NCSA Mosaic，把自己标称为NCSA_Mosaic/2.0 (Windows 3.1)，它支持文字显示的同时还支持图片，于是Web开始好玩起来。

然后出现了一个新的网页浏览器，“Mozilla”，其实就是“Mosaic终结者”的意思，这搞的Mosaic很不爽，（毕竟Mosaic出道早，江湖老），新浏览器最后正式公布的名称是Netscape，它把自己标称为Mozilla/1.0 (Win3.1)，更好玩了。Netscape支持框架显示，后来框架在大家中间流行起来了，但Mosaic不支持框架啊，于是伟大的“用户代理人探测”技术出现了，如果是“Mozilla”，那就发给支持框架的页面，至于其他的浏览器，则发给不含框架的页面。

Netscape想逗Microsoft玩儿，把Windows叫做“几乎不曾做过调试的设备驱动器”，后者很恼火。Microsoft于是推出了自己的网页浏览器，叫做Internet Explorer，希望它能成为“Netscape终结者”。Internet Explorer也支持框架，但它不是Mozilla啊，所以没人给它发送带有框架的页面。Microsoft慢慢烦躁起来，不再寄希望于网站管理员逐渐认识IE并给它发框架，而是宣称自己是“兼容Mozilla”的，开始模仿Netscape，把自己标称为Mozilla/1.22 (compatible; MSIE 2.0; Windows 95)，这样Internet Explorer也能收到框架了，整个Microsoft狂喜，但网站管理员开始有点被搞糊涂了。

Microsoft把IE和Windows一起卖，并且把产品也弄得比Netscape更好了，拉开了第一场浏览器之战。结果和大家知道的一样，Netscape被干掉了，Microsoft大胜、大喜。但是后来Netscape以Mozilla的新名称重生了，构造了Gecko，标称其为Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826，Gecko属于渲染引擎，表现优异。Mozilla开发了Firefox，标称为Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.5) Gecko/20041108 Firefox/1.0，并且Firefox表现也非常优秀。Gecko扩张迅速，一些浏览器使用了它的代码并标称为Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040825 Camino/0.8.1 ，这是一个，还有Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.8) Gecko/20071008 SeaMonkey/1.0，另一个，它们都伪装成Mozilla，同时也都是基于Gecko支持的。

Gecko表现优秀，IE则很差劲，于是身份甄别再次发生，输送给Gecko的是设计良好的网页代码，其他浏览器就没有这个待遇了。Linux的跟随者很伤心，因为他们创建了基于KHTML引擎支持的Konqueror，但却不会被输送好代码，虽然他们自己认为KHTML和Gecko一样优秀，于是Konquerer开始伪装自己“像Gecko”那样以得到好的网页，并标称自己为Mozilla/5.0 (compatible; Konqueror/3.2; FreeBSD) (KHTML, like Gecko)，这个世界更让人困惑了.

mm小游戏

后来出现了Opera这样的主儿，宣称“允许用户自己决定让浏览器装成谁”，它的菜单中提供了Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 9.51， Mozilla/5.0 (Windows NT 6.0; U; en; rv:1.8.1) Gecko/20061208 Firefox/2.0.0 Opera 9.51，Opera/9.51 (Windows NT 5.1; U; en) 供大家来选择，选谁是谁。

Apple开发了Safari，使用了KHTML，同时也增加了很多新特性，后来干脆一锅煮，另起炉灶叫了WebKit，但是它有希望能够得到那些为KHTML编写的网页，于是Safari标称自己为Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5，这个世界更混乱了。

Microsoft越来越担心Firefox的发展，重新启动了Internet Explorer的开发，标称自己为Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0) ，可以很好的渲染代码，但那要看网站管理员是否指示它这么做。

美女小游戏

Google也开发了自己的浏览器Chrome，使用了Webkit，有点像Safari，希望能得到为Safari编写的网页，于是决定装成Safari。这样啊，Chrome使用了WebKit渲染引擎，想装成Safari，而WebKit呢又伪装自己是KHTML，KHTML呢又是伪装成Gecko的，同时所有的浏览器又都宣称自己是 Mozilla，于是，Chrome宣称自己是Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13,，UserAgent字符串彻底混乱了，也几乎不再发挥任何作用，每个人都宣称自己是别人，混乱充斥人间啊。

装扮小游戏

本文链接

C#获取 Flv视频文件信息

2009-08-13T04:37:00Z

FLV文件结构解析http://noahgenius.javaeye.com/blog/164782FLV是一个二进制文件，由文件头（FLV header）和很多tag组成。tag又可以分成三类:audio,video,script，分别代表音频流，视频流，脚本流（关键字或者文件信息之类）。FLV Header一般比较简单，包括文件类型之类的全局信息文件类型3bytes总是FLV（0x46 0x4...

巧用泛型和Lambda解决只读对象的缓存技巧

2009-01-14T07:40:00Z

[代码]Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->///<summary>///只读缓存辅助///</summary>///<typeparamname="KeyType">键类型</typeparam&...

我对Singleton模式的泛型解决方案的改进

2009-01-09T05:53:00Z

原文:http://www.cnblogs.com/adonio/archive/2007/07/17/821066.html原文缺点: 构造函数只能是public的,导致可能由开发人员的失误引发多个Instance改进:用反射调用private的构造函数。[代码]Code highlighting produced by Actipro CodeHighlighter (freeware)htt...