CLR 垃圾回收器 (GC) 将对象分为大型、小型两类。如果是大型对象，与其相关的一些属性将比对象较小时显得更为重要。例如，压缩大型对象（将内存复制到堆上的其他位置）的费用相当高。我将讨论符合什么条件的对象才能称之为大型对象，如何回收这些大型对象，以及大型对象具备哪些性能意义。

大型对象堆

.NET Framework 1.1 和 2.0 中，如果对象大于或等于 85,000 字节，将被视为大型对象。注意：此数字根据性能优化的结果确定。当对象分配请求传入后，如果符合该大小，便会将此对象分配给大型对象堆。为什么会这样呢？我们先看看NET 垃圾回收器的基础知识。

我们知道，.NET 垃圾回收器是分代回收器。它包含三代：第0代、第1代和第2代。之所以分代，是因为在良好调优的应用程序中，您可以在第0代清除大部分对象。每当触发一次垃圾回收，NET就首先扫描第0代，仍存在的对象将被放到第1代，当第1代放满后，会对第1代进行垃圾回收，仍存在的对象将被放到第2代，以此进行下去。但是，最后一代回收未处理的对象仍会被视为最后一代中的对象。从本质上讲，第1代是新对象区域与生存期较长的对象区域之间的缓冲区。回收任何一代，都会回收他以前的所有代。例如，执行第1代垃圾回收时，将同时回收第1代和第0代。执行第2代垃圾回收时，将回收整个堆。

加载 CLR 时，将分配两个初始堆栈段（一个用于小型对象，另一个用于大型对象），我将它们分别称为小型对象堆 (SOH) 和大型对象堆 (LOH)。然后，通过将托管对象置于任一托管堆栈段上来满足分配请求。如果对象小于 85,000 字节，则将其放在 SOH 段上；否则将其放在 LOH 段上。随着分配到各段上的对象越来越多，会以较小块的形式提交这些段。用户代码只能在第 0 代（小型对象）或 LOH（大型对象）中分配。只有垃圾回收器可以在第1代（通过提升第0代回收未处理的对象）和第2代（通过提升第1代和第2代回收未处理的对象）中“分配”对象。触发垃圾回收后，垃圾回收器将寻找存在的对象并将它们压缩。如果没有足够的可用空间来容纳大型对象分配请求，我会先尝试从操作系统获取更多段。如果失败，我将触发第 2 代垃圾回收以便释放一些空间。

如果大家还有所怀疑，可以看看下面windbg+sos来看看一个用户态运行的程序的GC Heap里面都是些什么：

Number of GC Heaps: 1
generation 0 starts at 0x013d1018
generation 1 starts at 0x013d100c
generation 2 starts at 0x013d1000
ephemeral segment allocation context: none
 segment    begin allocated     size
001b09f8 7a733370  7a754b98 0x00021828(137256)
001b3fc0 7b463c40  7b47a744 0x00016b04(92932)
0014df68 790d8620  790f7d8c 0x0001f76c(128876)
013d0000 013d1000  01425ff4 0x00054ff4(348148)
Large object heap starts at 0x023d1000
 segment    begin allocated     size
023d0000 023d1000  023d8e00 0x00007e00(32256)
Total Size   0xb488c(739468)
------------------------------
GC Heap Size   0xb488c(739468)
我们一个GC Heap里面有四个Heap Segment，紧接着Heap Segment的，是LOH。这些Generation是保存在一个一个的Heap Segment里面的。一个Heap Segment可以包含两个Generation或者三个，或者更多。而一个Generation可以跨越多个Heap Segment。紧接着GC Heap的内存区域，就是LOH。在默认情况下，超过85000byte的对象就被保存到这里。

Code
 1Hashtable ht = new Hashtable();
 2for (int m = 0; m < 5; m++)
 3   ht.Add(new cuskey(m), m);
 4if (ht.ContainsKey(new cuskey(3)))
 5   {
 6        Console.WriteLine("find!");
 7   }
 8   else
 9   {
10        Console.WriteLine("can't find!");
11    }
12ht.Clear();
13
14MyTest key1 = new MyTest(10);
15ht.Add(key1, "Key1");
16if (ht.ContainsKey(key1))
17  {
18        Console.WriteLine("Is key1 contained in hashtable? {0}", true);
19   }
20   else
21   {
22        Console.WriteLine("Is key1 contained in hashtable? {0}", false);
23    }
24key1.KeyNumber = 11;
25bool isContained = ht.ContainsKey(key1);
26Console.WriteLine("Is key1 contained in hashtable? {0}", isContained);
27
28MyTest key2 = new MyTest(10);
29ht.Add(key2, "key2");
30Console.WriteLine("Hashtable counts:" + ht.Count);
31
32MyTest key3 = new MyTest(15);
33ht.Add(key3, "key3");
34Console.WriteLine("Hashtable counts:" + ht.Count);
35
36//MyTest key4 = new MyTest(10);
37//ht.Add(key4, "key4"); 

先不做解释，看看结果。

在我没有给出自定义类MyTest和cuskey的时候，如果你能猜测出MyTest和cuskey大概代码以及为什么的话，你可以省略
下面的这段内容，^_^.下面给出MyTest和cuskey的代码。

Code
 1 public class MyTest
 2    {
 3        public int KeyNumber
 4        {
 5            set
 6            {
 7                keyNumber = value;
 8            }
 9        }
10
11        private int keyNumber ;
12
13        public MyTest(int num)
14        {
15            keyNumber = num;
16        }
17
18        public override int GetHashCode()
19        {
20            return keyNumber % 5;
21        }
22
23        public override bool Equals(object obj)
24        {
25            return keyNumber == ((MyTest)obj).keyNumber;
26        }
27    }
28
29    class cuskey
30    {
31        private int keyNumber;
32        public int KeyNumber
33        {
34            set
35            {
36                keyNumber = value;
37            }
38        }
39        public cuskey(int n)
40        { 
41            keyNumber = n; 
42        }
43    }

好了，当大家看完这两个自定义的类后，我想很大部分人能通过这两个类的区别可以判断出为什么上面的显示结果会是这样的，下面我俩讲解一下。
MyTest和cuskey的最大的区别就在于MyTest重写了GetHashCode()方法，而cuskey没有重写GetHashCode()方法，我们都知道net的类型最后都是要继承Object类了，也就是说cuskey是使用Object的GetHashCode()方法，它的每个实例的hashcode的算法都是继承自Object，而MyTest重写了GetHashCode()方法，因此MyTest的每个实例的hashcode的算法都是来自重写后的算法。
如上所说，cuskey的每个实例的hashcode是不一样的(Object的GetHashCode()所采用的算法大家有兴趣可以看看)，而MyTest的每个实例的hashcode的算法是依赖其成员keyNumber的值，因此只要keyNumber的值相同，我们就认为其hashcode相同。以上我们对这两个自定义的类进行分析，下面我们回到HashTable上。
最开始我们说HashTable用于处理和表现类似key/value的键值对，Hashtable 对象由包含集合元素的存储桶组成。存储桶是 Hashtable 中各元素的虚拟子组，与大多数集合中进行的搜索和检索相比，存储桶可令搜索和检索更为便捷。每一存储桶都与一个哈希代码关联，该哈希代码是使用哈希函数生成的并基于该元素的键。哈希函数是基于键返回数值哈希代码的算法。键是正被存储的对象的某一属性的值。哈希函数必须始终为相同的键返回相同的哈希代码。Hashtable 中用作元素的每一对象必须能够使用GetHashCode()方法的实现为其自身生成哈希代码。在将一个对象添加到 HashTable时，它被存储在存储桶中，该存储桶与匹配该对象的哈希代码的哈希代码关联。在 HashTable内搜索一个值时，将为该值生成哈希代码，并且搜索与该哈希代码关联的存储桶。我们这里MyTest和cuskey的GetHashCode()方法的实现原理不同，直接导致查找的结果不同。
这样上面的例子就不难解释了，注意key4的那两句运行的话是回报错的哦，应该很简单，就是已经包含这样的key。

HashTable是个很重要的数据结构，里面哈希函数的实现是最重要的。大家有时间可以研究一下，参考《数据结构》。

1for (int m = 0; m < 5; m++)
2    ht.Add(new cuskey(m), m);
3/**//*[{Collections.cuskey}]:1                   [{Collections.cuskey}]: 4  [{Collections.cuskey}]:2                  [{Collections.cuskey}]:3                  [{Collections.cuskey}]: 0  
4*/

看看上面的代码，注释部分就是存储在HashTable的顺序，为什么与insert的顺序不同呢？待续。。。

 

[新闻]中国互联网历史上最伟大的产品TOP10（二）]]>

听了之后，很是喜欢这种风格。然后baidu了一个下载地址发给她，说是这个flash的MP3的地址，后来非要让我如何找到的….冂冏囧….只好拾起尘封了n久的hack技术…

       首先查看Page Source，找到相关的一段：

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000"

codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" width="280" height="277" id="musicMovie" align="middle">

<param name="movie"

value="/-/flash/music_player_dq.v28.swf?id=1657&un=naivete">

       <param name="quality" value="high">

       <param name="wmode" value="transparent">

       <embed src="/-/flash/music_player_dq.v28.swf?id=1657&un=naivete" quality="high"

wmode="transparent" pluginspage="http://www.macromedia.com/go/getflashplayer"

type="application/x-shockwave-flash" width="280" height="277"

name="musicMovie">

</embed>

</object>

                                                                                            </object>

       初步猜想，恩，MP3的相关的信息保存在一个xml文件里面，只需要找到这个xml，然后找到里面的mp3的对应地址就ok了。这也是类似的网站经常使用的技术。。。

       根据上面的object的信息，拼起来了这个地址然后打开：

http://www.neocha.com/-/flash/music_player_dq.v28.swf?id=1657&un=naivete

恩，这个是一个flash，初步思路是获取到这个flash，然后反编译一下，看看是读取的哪个地方的MP3的URL就ok了。

抄起迅雷，添加下载信息，直接填上这个链接，把这个flash下载下来。下载之后得到这个文件名的东西：music_player_dq.widget.v26.swf

抄起闪客精灵，反编译之…

然后查看一共21个动作的Script脚本。。。

功夫不负有心人，在名称为sprite64的动作脚本中发现了比较敏感的东西：

function loadXMl()

    {

        myxml = new com.makeit.xmlClass("music_playlist.xml");

        var _l2 = new Object();

        function xmlComplete(albumArr, musicArray, parameterArr)

        {

            com.makeit.musicDocument.thisObj.albumArr = albumArr.slice();

            com.makeit.musicDocument.thisObj.musicArray = musicArray.slice();

            com.makeit.musicDocument.thisObj.parameterObj = parameterArr;

            com.makeit.musicDocument.thisObj.setFunc();

        } // End of the function

        myxml.addListener(albumArr);

    } // End of the function

啊哈，Load Xml。而且xml文件的名称都有了，恩，立马蹭蹭蹭的构造了几个xml的路径：

http://www.neocha.com/naivete/music_playlist.xml

http://www.neocha.com/-/flash/music_playlist.xml

http://www.neocha.com/-/xml/music_playlist.xml

….

啥都没有。。sad。。不泄馁，继续寻寻觅觅，终于，在这个动作的下一个动作里面发现了感兴趣的东西：

function loadXml()

    {

        static function onLoad(success)

        {

            if (success)

            {

                com.makeit.xmlClass.thisObj.parseAlbum_fun();

            } // end if

        } // End of the function

        if (_root.id == undefined)

        {

            id = "3378";

        } // end if

        if (_root.un == undefined)

        {

            un = "banana_monkey";

        } // end if

        myxml.load("http://www.neocha.com/-/xml/music_player.jsp?id=" + _root.id +

"&un=" + _root.un + "&a=" + Math.random() * 9999);

    } // End of the function

看到这里俺就开始得意了，胜利就在眼前了，迅速构造一地址：

http://www.neocha.com/-/xml/music_player.jsp?id=3378&un= banana_monkey&a=9999

       使用IE打开去，结果很差很失望，打不开，找不到这个地址。恩，转变思路，这个jsp文件应该是负责后台的某些逻辑处理的，关掉IE，迅雷上。

       果然，出现重大转机，下载得到的文件打开如下：

<?xml version='1.0' encoding='UTF-8'?>

<music-player>

       <albums>             

       <album>

       <album-id>0</album-id>

       <album-title>未分类&nbsp;</album-title>                  <album-picture>http://www.neocha.com/-/res/banana_monkey/20080414131625686093_t.jpg</album-picture>

       <album-link>http://www.neocha.com/banana_monkey/record!0.html</album-link>

       <musics>                           

       <music>

       <music-id>3378</music-id>

       <music-title>Baby in Red (Lovely Version)</music-title>                         <music-picture>http://www.neocha.com/-/res/banana_monkey/20080414131625686093_o.jpg</music-picture>                               <music-file>http://www1.neocha.com:90/-/res/banana_monkey/20080414131625702094.mp3</music-file>                              <music-link>http://www.neocha.com/banana_monkey/music!3378.html</music-link>

                                   <music-artist>Banana Monkey&nbsp;</music-artist>

                                   <music-album>未分类&nbsp;</music-album>

                                   <music-corp>&nbsp;</music-corp>

                                   <music-publish>&nbsp;</music-publish>

                                   <music-genres>Rock摇滚,8-Bit8比特&nbsp;</music-genres>

                                   <music-comment-cnt>0</music-comment-cnt>                                     <music-comment-url>http://www.neocha.com/banana_monkey/music!3378.html#comment</music-comment-url>                         

<music-favorite-cnt>0</music-favorite-cnt>                                   <music-favorite-url>http://www.neocha.com/banana_monkey/music!3378.html</music-favorite-url>

       <music-vote-cnt>0</music-vote-cnt>                              <music-vote-url>http://www.neocha.com/banana_monkey/music!3378.html</music-vote-url>

       <music-favorited>2</music-favorited>

</music>

       </musics>

       </album>

       </albums>

       <username>banana_monkey</username>

       <user-url>&nbsp;</user-url>

       <user-picture>&nbsp;</user-picture>

       <default-album-id>0</default-album-id>

       <!-- 默认播放的专辑 -->

       <auto-start>1</auto-start>

       <!-- 1自动 0 手动 播放-->

       <color1>#000000</color1>

       <color2>#999999</color2>

       <color3>#FFFF00</color3>

       <color4>#FFFF00</color4>

</music-player>

<script src="http://www.neocha.com/-/js/urchin.js" type="text/javascript"></script>

<script type="text/javascript">

_uacct = "UA-828246-1";

urchinTracker();

</script>

看到没，看到MP3这个后缀的时候，第一感觉找到了。

不过很遗憾，下载了这首MP3之后发现，是一首Rock…

感觉世界一下灭了。。这个时候决定转变思路。。

抄起嗅探工具，好多年前的winsock也不在身边了，唉，只好问liunice要一个ie的插件，装了起来….

看来又要分析IE的数据包了…

安装插件的时候，仔细的看了下载的这个文件的格式，忽然灵光一现，music标签下面的不就是动作script里面的好多的参数的么。。豁然开朗了：

这个文件就是上面的那个jsp文件根据参数读取数据库动态生成的flash的MP3文件地址的xml配置文件。

找到了key Point：

<music-link>http://www.neocha.com/banana_monkey/music!3378.html</music-link>

打开这个链接，链接的格式是如此的熟悉，打开之后，出现了刚才的那个下载的熟悉的banana的Rock，oh yeah！

搞定！

回到开头的最开始安小落MM发的URL：

http://www.neocha.com/naivete/music!1657.html

根据这个URL来构造这首MP3：

http://www.neocha.com/-/xml/music_player.jsp?id=3378&un= banana_monkey&a=9999

两个地址相加，得到最终地址：

http://www.neocha.com/-/xml/music_player.jsp?id=1657&un=naivete&a=9999

迅雷下载这个URL，在<music-file>标签找到了想要的东西：

<music-file>http://www1.neocha.com:90/-/res/naivete/20071124214646754207.mp3</music-file>

呵呵，剩下的事情，就是永久的拥有这首好听的“穿格子衬衫的teddy熊”了。

恩，还有，破解和这个网站整个的flash播放音乐隐藏真实地址是如何实现的。。不过这不是主要目的。。

lbq1221119 5/24/2008 11:26:19 PM 首发lbq1221119.cnblogs.com

       最终效果，是实现了非托管平台下托管代码执行的混合型线程插入。

       在开发CLR的时候，MS将CLR作为一个COM服务器放到了一个DLL