艾榕 - 追求创业

装修以后很快后悔的事

艾榕 — Tue, 01 Nov 2011 21:36:52 +0800

一、马桶一定要选那种，拉便便是不会溅水的，而且要冲的干净，易清理
二、绝不装射灯之类的装饰灯。顶灯也要简单的，不易落灰的，便于修理的。卧室最好能装一个能调节亮度的。床头灯少不了~~
三、要减少直角和棱角，因为会有孩子~~
四、衣柜和储物柜要尽量多，老婆和孩子的衣服会有很多很多
五、有必要在阳台或者室内装衣柜的时候专门留出放鞋子的地方，因为老婆的鞋子会有很多~~~
六、在合适的位置装一面能照全身的镜子
七、卫生间可以考虑用帘子式的淋浴；洗脸池不能装的太高；预留好洗衣机用的水龙头、插座、排水地空孔，要有两个储物架，一个在洗脸池旁边，一个在洗澡的地方。
1.后悔搞开放式厨房，说没油烟问题绝对是假的
2. 后悔卫生间、厨房没搞小水宝，热水来得快，使用时比较方便
3. 后悔吸油烟机用,欧式的，好看不中用，应该用中式的。
4. 后悔电源插座装少了，家里到处都是拖线板。能装多少应该装多少　
5. 后悔马桶边上没有预留电源插座，卫洗丽没法装
6. 浴缸PK淋浴，二选一的话，还是建议淋浴，浴缸装好，从来也没泡过澡的不是少数。淋浴不是指淋浴房，淋浴房的玻璃擦起来还是很累的，也可以选择挂根浴帘
7. 如果有2个卫生间，装一个浴缸还是有必要的，泡泡大件衣物，帮小宝宝洗澡都是不错的选择，按摩浴缸就不必，泡不了几回，还特别贵8. 后悔厨房没有装空调,哪怕搞个窗机也好
9. 如果喜欢上网，每个房间的每面墙上，都预留至少2个网口和2个以上的插座。无线路由的确可以解决问题，但是据说有时候还是不稳定 10. 后悔厨房烟道没有打出去，现在只要楼里有人烧菜，自家的脱排油烟机就必须同时打开，不然满屋子的油烟味
11. 房内各种插座的位置，与后来买的家具尺寸有偏差，浪费了很多插座
12. 如果在商场里能买到的，就千万不要叫木工做！！！！！除非这个木工手艺相当的好
13. 地板颜色要略浅的，不容易看到灰，厨卫地砖反而要略深，不容易发现到处都是头发，这样才最耐脏
14. 餐厅最好装个吊扇，超级舒服
15. 储物空间尽量多一点，入住后需要收纳的杂物会越来越多　
16. 阳台的墙面最好还是用瓷砖，比涂料更防水
17. 后悔买了装了那么多灯，其实固定用的就那几个。。。
18. 超级后悔厕所的梳洗台是玻璃的，超级容易弄脏，应该用陶瓷的
19．团购其实省不了几个钱，买的没有卖的精，要相信这个天上不会平白无故的掉馅鉼。一套房子装修下来都是以万元为单位的，还是多到市场走走看看，货比三家永不过时。千万不要在团购会上被所谓的“砍价师”吹得头脑一热当场下单。连亮居网都不敢说自己的商品绝对低价，何况别的所谓团购网？
20.后悔床头忘了装开关，每次都要下床关灯，冬天很难过的
21. 后悔买便宜五金具，浴室五金件,龙头之类的绝对是一分价钱一分货
22. 装修时尽量不要留擦不到的地方, 死角卫生很难搞
23. 将来打算要孩子的家庭，一定要算好尺寸，在床的旁边要预留可放婴儿床的位置
24. 建议所有龙头都装冷热水管，装修时多装一点花不了很多钱，事后想补救超级困难
25. 房间里的不实用的布置越少越好人民币贴上去就撕不下来了早晚过时!
26. 买任何东西时注意家里面门的大小，别买好了搬不进去
27. 实木地板脚感好但需要保养，复合地板清洁起来方便
28. 后悔买隐形门。中看不中用的，想开着透气都麻烦
29. 步入式衣柜好是好，不过比较容易积灰，敞开式的书架、置物架等（没有门的那种），好看是好

CLR如何创建运行时对象的

艾榕 — Mon, 31 Oct 2011 21:27:13 +0800

原文: Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects

文章讨论了:

SystemDomain, SharedDomain和Default Domain

对象布局和其他的内存细节

方法表布局

方法分派

文章使用的技术:

.NET Framework

因为公共语言运行时(CLR)即将成为在Windows上创建应用程序的主角级基础架构, 多掌握点关于CLR的深度认识会帮助你构建高效的, 工业级健壮的应用程序. 在这篇文章中, 我们会浏览,调查CLR的内在本质, 包括对象实例布局, 方法表的布局, 方法分派, 基于接口的分派, 和各种各样的数据结构.

我们会使用由C#写成的非常简单的代码示例, 所以任何对编程语言的隐式引用都是以C#语言为目标的. 讨论的一些数据结构和算法会在Microsoft® .NET Framework 2.0中改变, 但是绝大多数的概念是不会变的. 我们会使用Visual Studio® .NET 2003 Debugger和debugger extension Son of Strike (SOS)来窥视一些数据结构. SOS能够理解CLR内部的数据结构, 能够dump出有用的信息. 通篇, 我们会讨论在Shared Source CLI(SSCLI)中拥有相关实现的类, 你可以从msdn.microsoft.com/net/sscli下载到它们. 图表1 会帮助你在搜索一些结构的时候到SSCLI中的信息.

图表1 SSCLI索引

Item	SSCLI Path
AppDomain	\sscli\clr\src\vm\appdomain.hpp
AppDomainStringLiteralMap	\sscli\clr\src\vm\stringliteralmap.h
BaseDomain	\sscli\clr\src\vm\appdomain.hpp
ClassLoader	\sscli\clr\src\vm\clsload.hpp
EEClass	\sscli\clr\src\vm\class.h
FieldDescs	\sscli\clr\src\vm\field.h
GCHeap	\sscli\clr\src\vm\gc.h
GlobalStringLiteralMap	\sscli\clr\src\vm\stringliteralmap.h
HandleTable	\sscli\clr\src\vm\handletable.h
InterfaceVTableMapMgr	\sscli\clr\src\vm\appdomain.hpp
Large Object Heap	\sscli\clr\src\vm\gc.h
LayoutKind	\sscli\clr\src\bcl\system\runtime\interopservices\layoutkind.cs
LoaderHeaps	\sscli\clr\src\inc\utilcode.h
MethodDescs	\sscli\clr\src\vm\method.hpp
MethodTables	\sscli\clr\src\vm\class.h
OBJECTREF	\sscli\clr\src\vm\typehandle.h
SecurityContext	\sscli\clr\src\vm\security.h
SecurityDescriptor	\sscli\clr\src\vm\security.h
SharedDomain	\sscli\clr\src\vm\appdomain.hpp
StructLayoutAttribute	\sscli\clr\src\bcl\system\runtime\interopservices\attributes.cs
SyncTableEntry	\sscli\clr\src\vm\syncblk.h
System namespace	\sscli\clr\src\bcl\system
SystemDomain	\sscli\clr\src\vm\appdomain.hpp
TypeHandle	\sscli\clr\src\vm\typehandle.h

在我们开始前请注意, 这篇文章提供的信息仅适用于在x86平台架构下的.NET Framework 1.1(有可能多数信息对于Shared Source CLI 1.0中, 一些互操作情形下的多数值得注意的异常来说, 也还是正确的). 对于.NET Framework 2.0来说, 很多信息可能会改变, 所以不要创建依赖于这些内部结构不会改变的软件.

CLR辅助程序创建的域

=================

在CLR执行第一行托管代码之前, 它先创建三个应用程序域. 其中的两个是从托管代码中产生的, 是透明的, 甚至对于CLR宿主来说都是不可见的. 这两个domain只能通过CLR bootstrap进程创建出来, 这个进程受助于两个垫板作用一样的dll文件, mscoree.dll和mscorwks.dll(当是多处理器系统的时候, 为mscorsvr.dll). 在图表2中, 你可以看到System Domain和Shared Domain, 这两个都是Singleton的(只用唯一一个实例). 第三个域是default app domain, 它是一个AppDomain类的实例, 也是唯一命名的domain. 对于简单的CLR宿主程序, 比方说控制台程序, default domain的名字是由可执行镜像的名字组成的. 其他的域可以通过在托管代码中使用AppDomain.CreateDomain方法, 或者在非托管宿主代码中通过调用ICORRuntimeHost接口, 来创建. 类似ASP.NET这样的复杂的宿主, 基于Web Site的数目来创建多个域.

图表2 CLR辅助程序创建的域

系统域-System Domain

===================

系统域负责创建和初始化Shared Domain和default appdomain. 它加载系统库mscorlib.dll到Shared Domain中. 它还显式或隐式的保持着进程范围的字符串的字面值.

保存字符串的字面值(string interning)在.NET Framework 1.1中是一项有点点笨拙的优化特性, 因为CLR并不给assemblies机会来选择是否使用它. 不论如何, 它在所有的应用程序域范围内, 提供给定字符串值的唯一实例(相同值的字符串在内存中只有一份).

系统域还负责生成进程范围的接口ID, 这些接口ID被用来在每一个AppDomain中创建InterfaceVtableMaps. 系统域记录并监控着进程中的所有域, 并实现了加载和卸载AppDomain的功能.

共享域-Shared Domain

===================

所有的域-中立的代码都被加载到shared domain中.

Mscorlib, 这个系统库, 是被所有的appdomain中的用户代码使用和需要的, 它会被自动的加载到SharedDomain中. 像Object, ValueType, Array, Enum, String, 还有Delegate之类的System命名空间中的基础类型, 都会在CLR辅助程序进程(CLR bootstrapping process)中, 被预先加载到SharedDomain里.
用户代码(user code)也可以被加载到该域中, 方法是通过在调用CorBindToRuntimeEx方法时, 指定LoaderOptimization属性. LoaderOptimization属性是由CLR宿主应用程序指定的.
控制台程序可以给应用程序的main方法编写属性来加载代码到SharedDomain中, 这个属性是System.LoaderOptimizationAttribute.

共享域还管理由基地址(the base address)索引的assembly map, assembly map的功能类似于一种查找表, 这个查找表用于明确被加载到Default Domain中的assembly和在其它应用程序域的托管代码中创建的assembly的共享依赖关系.

默认域(Default Domain)是非共享的用户代码加载的地方.

默认域-DefaultDomain

===================

默认域是一个AppDomain的实例, 典型地, 应用程序代码在这个域中执行.

当一些应用程序需要在运行时创建额外的appdomain的时候(比如拥有插件式架构的应用程序, 或者是正在生成相当大量的运行时代码的应用程序), 多数的应用程序会在他们的生命期中创建一个这样的一个域: 所有执行在这个域中的代码都是在域层次上进行了上下文绑定的.

如果一个应用程序有多个appdomain, 那么任何跨domain的访问都要通过.NET Remoting proxies(.net远程代理).

额外的domain内的上下文边界可以通过继承自System.ContextBoundObject的类型来创建.

每一个AppDomain都有自己的SecurityDescriptor, SecurityContext和DefaultContext, 同样的, 还有自己的加载者堆(高频堆, 低频堆, 和Stub堆), 句柄表(句柄表, 大对象堆句柄表), 接口虚表映射管理器(Interface Vtable Map Manager), 和Assembly Cache.

加载者堆-LoaderHeaps

====================

加载者堆是用来加载各种各样的CLR runtime artifacts【译注:artifact这里可以理解为一种structure】和优化artifacts的, 这些artifacts在域的生命期中都存在.

这些堆按照可以预见的大小的块来增长, 从而最小化内存碎片.

加载者堆与GC堆(在对称的多处理器情况下, 是多重堆-multiple heap) 不同, 不同之处在于GC堆保存对象实例,而加载者堆保存的是整个类型系统.

经常访问到的artifact比如MethodTables, MeghodDescs, FieldDescs和InterfaceMaps, 都在高频堆上分配, 而不那么经常访问的数据结构比如说EEClass和ClassLoader还有ClassLoader的查找表, 在低频堆(LowFrequencyHeap)上分配.

StubHeap保存着很多stub, stub可以帮助代码访问security (CAS), COM wrapper calls和P/Invoke.

简单在高层次上过了一遍各种域和加载者堆之后, 我们现在来看一下以一个简单应用程序为上下文背景的, 这些结构的物理细节. 见图表3. 我们将程序的执行中断在了”mc.Method1();”, 并且使用SOS debugger extension的DumpDomain命令dump出了域的信息, 这里是编辑过的输出结果:

—————————————————

!DumpDomain
System Domain: 793e9d58, LowFrequencyHeap: 793e9dbc,
HighFrequencyHeap: 793e9e14, StubHeap: 793e9e6c,
Assembly: 0015aa68 [mscorlib], ClassLoader: 0015ab40

Shared Domain: 793eb278, LowFrequencyHeap: 793eb2dc,
HighFrequencyHeap: 793eb334, StubHeap: 793eb38c,
Assembly: 0015aa68 [mscorlib], ClassLoader: 0015ab40

Domain 1: 149100, LowFrequencyHeap: 00149164,
HighFrequencyHeap: 001491bc, StubHeap: 00149214,
Name: Sample1.exe, Assembly: 00164938 [Sample1],
ClassLoader: 00164a78

图表3 Sample1.exe

using System;

public interface MyInterface1
{
    void Method1();
    void Method2();
}
public interface MyInterface2
{
    void Method2();
    void Method3();
}

class MyClass : MyInterface1, MyInterface2
{
    public static string str = "MyString";
    public static uint ui = 0xAAAAAAAA;
    public void Method1() { Console.WriteLine("Method1"); }
    public void Method2() { Console.WriteLine("Method2"); }
    public virtual void Method3() { Console.WriteLine("Method3"); }
}

class Program
{
    static void Main()
    {
        MyClass mc = new MyClass();
        MyInterface1 mi1 = mc;
        MyInterface2 mi2 = mc;

        int i = MyClass.str.Length;
        uint j = MyClass.ui;

        mc.Method1();
        mi1.Method1();
        mi1.Method2();
        mi2.Method2();
        mi2.Method3();
        mc.Method3();
    }
}

我们的控制台程序, Sample1.exe, 被加载到名为”Sample1.exe”的AppDomain中.

Mscorlib.dll被加载到SharedDomain中, 但是它还是被列在SystemDomain中, 因为他是核心的系统库.

每个域中都分配了自己的高频堆,低频堆,和stub堆. 系统域和共享域使用同样的ClassLoader, 而Default AppDomain使用的是它自己的ClassLoader.

输出结果中并没有显示出加载者堆保存的尺寸和已经committed的尺寸. 高频堆初始保留尺寸是32KB, committed的尺寸是4KB. 低频堆和Stub堆初始保留尺寸是8KB, committed的尺寸是4KB.

在SOS输出中同样没有显示出来的是InterfaceVtableMap堆. 每个域都有一个InterfaceVtableMap堆(后面再用的时候就简写为IVMap), 在域初始化阶段它，被创建在自己的加载者堆上. IVMap堆初始保留大小为4KB, 初始committed的大小是4KB. 我们将在接下来的部分中,探索类型布局的时候,讨论IVMap的重要性.

图表2 展示了默认的进程堆, JIT代码堆, GC堆(针对小对象的), 和大对象堆(针对大于等于85000字节的对象的), 通过他们来说明了：这些堆和加载者堆在语义上的不同.

just-in-time(JIT)编译器生成x86指令, 并且把它们存储在JIT代码堆上.

GC堆和大对象堆都是垃圾收集堆, 托管对象是在这些堆上实例化出来的.

类型基础- Type Fundamentals

========================

类型是在.NET编程中的基础单位. 在C#中, 一个类型使用关键字class, struct,和interface来声明. 多数的类型是显示的由程序员来创建的, 然而, 在特殊的互操作情形下, 或者在远程对象激活(.NET remoting)场景中, .NET CLR隐式的生成一些类型. 这些生成的类型包括COM和运行时可调用的包装器, 还有透明的代理.(COM and Runtime Callable Wrappers and Transparent Proxies).

我们接下来探索一下类型基础, 从包含一个对象引用的栈开始.(典型地, 栈是一个对象实例开始他的生命期的位置.) 代码在图表4中, 其中包括一个简单的程序, 有调用静态方法的控制台入口点. Method1创建了一个类型为SmallClass的的实例, SmallClass中包括一个字节数组, 我们通过这个数组来demo在大对象堆上的对象实例的创建. 代码的实用价值不高, 但是足够为我们的讨论服务了.

图表 4 大对象和小对象-Large Objects and Small Objects

using System;

class SmallClass
{
    private byte[] _largeObj;
    public SmallClass(int size)
    {
        _largeObj = new byte[size];
        _largeObj[0] = 0xAA;
        _largeObj[1] = 0xBB;
        _largeObj[2] = 0xCC;
    }

    public byte[] LargeObj
    {
        get { return this._largeObj; }
    }
}

class SimpleProgram
{
    static void Main(string[] args)
    {
        SmallClass smallObj = SimpleProgram.Create(84930, 10, 15, 20, 25);
        return;
    }

    static SmallClass Create(int size1, int size2, int size3,
        int size4, int size5)
    {
        int objSize = size1 + size2 + size3 + size4 + size5;
        SmallClass smallObj = new SmallClass(objSize);
        return smallObj;
    }
}

图表5 显示了断点在Create方法中的”return smallObj;”语句的栈的一个快照(snapshot), 这是一个典型的fastcall的栈框架. (Fastcall是.NET的一种调用约定, 在这种调用约定下, 传递给函数的参数在可能的情况下会通过寄存器来传递, 其他的参数从右至左的压入栈中供函数调用, 函数调用结束后, 由函数自身将栈中的参数清除.)

值类型变量objSize存储在栈框架之内.

类似smallObj的引用类型以一个固定的大小(4字节的双字), 存储在栈中, 双字的内容是在普通GC堆上的对象实例的地址.

在传统C++中, 这是一个对象指针; 在托管世界中, 这是一个对象引用. 不论如何, 它包含对象实例的地址. 我们将会对存储在对象引用的地址中的数据结构使用术语ObjectInstance.

图表5 简单程序的栈框架和堆-SimpleProgram Stack Frame and Heaps

smallObj对象的实例(object instance), 存储在普通GC堆上, 其中包含一个字节数组, 叫做_largeObj, 这个字节数组的大小是85000字节(注意, 图中显示的是85016字节, 这是真实存储的空间大小.)

CLR对待大小>=85000字节的对象, 跟对待比这小的对象的方式不同. 大对象分配在Large Object Heap(LOH)中, 而小对象是创建在普通GC堆上的. 因为普通GC堆对于对象的分配和垃圾收集是有优化的(所以适合存储小对象的效率高). 大对象堆是没有压缩的(夯实的), 而GC堆在GC垃圾收集发生的时候是压缩的. 更重要的是, 大对象堆(LOH)仅在完全垃圾回收的时候才被释放(LOH is only collected on full GC collections).

smallObj的ObjectInstance包含TypeHandle(类型句柄), TypeHandle指向相关连的类型的MethodTable.

任何一个声明了的类型都仅有一个MethodTable, 并且所有同样类型的对象的实例都指向同一份MethodTable.

MethodTable包含

关于这种类型的信息(属于哪一个? interface, abstract class, concrete class, COM Wrapper还是Proxy).

实现了的接口数量

为了方法分配而设立的接口映射表(interface map for the method dispatch)

方法表中的槽的数量(方法表中方法的数量)(number of slots in the method table)

一张满是指向方法的实现的槽的表格

一个由MethodTable指向的重要的数据结构, 是EEClass. 在MethodTable展开之前, CLR类加载器(class loader)从元数据(Metadata)中创建出EEClass. 在图表4中, SmallClass的MethodTable指向它的EEClass. 这些结构指向他们的模块和assembly.

MethodTable和EEClass典型地分配在具体域的加载者堆上. 字节数组(Byte[])是一个特例. 方法表MethodTable和EEClass分配在共享域中的加载者堆上.

加载者堆是appdomain-specific的, 任何这里提到的数据结构（MethodTable和EEClass）一旦加载起来就不会被移除, 除非它的AppDomain被卸载掉.

同样, 默认的appdomain也不能被卸载掉, 因此代码直到CLR关闭都还存在着.

对象实例-ObjectInstance

====================

正如我们提到的, 所有的值类型要么以inline(内联)地存储在线程栈中, 要么内联地存储在GC堆当中. 所有的引用类型都是在GC堆上或者大对象堆创建的. 图表6 显示了一个典型的对象实例的布局.

一个对象可以被以下的结构引用:

1. 基于栈的局部变量;

2. interop或者P/Invoke情形下的句柄表;

3. 寄存器(寄存器中的内容是:执行方法时的this指针或方法参数)

4. 服务于拥有finalizer方法的对象的finalizer queue.

OBJECTREF并不指向Object Instance的首地址, 而是指向一个以DWORD(4个字节)为单位的一个偏移量.

这个DWORD的偏移量叫做Object Header, 并且拥有一个指向SyncTableEntry表的索引值(a 1-based syncblk number). 通过索引的链锁效应, CLR在需要增长内存尺寸的情况下, 可以在内存中自由的移动SyncTableEntry表.

SyncTableEntry中保存着一个指回对象的weak reference, 这样CLR就可以追踪到SyncBlock的所有权(属于哪个对象). Weak Reference可以让GC在没有其他强引用的情况下, 收集到这个对象.

SyncTableEntry中还存着一个指向SyncBlock的指针, SyncBlock中保存着有用的信息, 但是这些信息很少被所有的对象实例使用到. 这些信息包括对象锁(object’s lock), 它的Hash Code, 一些转换数据(thunking data), 和它的AppDomain index.

对多数的对象实例来说, 他们当中没有为SyncBlock分配的存储空间, syncblk number是0. 然而,当线程执行遇到例如lock(obj), 或者obj.GetHashCode的时候, 就不同了. 就像下面的代码一样:

SmallClass obj = new SmallClass()
// Do some work here
lock(obj) { /* Do some synchronized work here */ }
obj.GetHashCode();

图表6 对象实例布局-Object Instance Layout

在这段代码中, smallObj会使用0（没有syncblk）做为它起始时的syncblk number. 那句lock语句引发了CLR创建一个syncblk entry的动作, 并用相应的数值来更新对象的object header. 由于C#的lock关键字可以展开为一个try-finally块, 用来使用Monitor类, 所以Monitor对象在为同步化(synchronization)而准备的syncblk中创建出来. 对GetHashCode方法的调用把对象的hash code填入到syncblk中.

SyncBlock中还有些其他的数据域, 它们有的用在COM的interop上, 有的用在针对非托管代码的marshaling delegate上. 但是这些数据域跟典型的对象使用无关.

TypeHandle的位置是紧跟着ObjectInstance中的syncblk number的. 为了保持连续性, 我会在详细阐述变量实例之后, 讨论TypeHandle.

在TypeHandle之后紧跟着一个实例的变量列表域. 默认情况下, 这个实例域会按照能让内存高效使用的方式来压缩, 或者按照能让内存读取高效的对齐来做最小程度的填充. 图表7中的代码显示了一个SimpleClass, 该class拥有很多包含不同大小的变量的实例.

图表7 拥有实例变量的SimpleClass- SimpleClass with Instance Variables

class SimpleClass
{
    private byte b1 = 1;                // 1 byte
    private byte b2 = 2;                // 1 byte
    private byte b3 = 3;                // 1 byte
    private byte b4 = 4;                // 1 byte
    private char c1 = 'A';              // 2 bytes
    private char c2 = 'B';              // 2 bytes
    private short s1 = 11;              // 2 bytes
    private short s2 = 12;              // 2 bytes
    private int i1 = 21;                // 4 bytes
    private long l1 = 31;               // 8 bytes
    private string str = "MyString"; // 4 bytes (only OBJECTREF)

    //Total instance variable size = 28 bytes 

    static void Main()
    {
        SimpleClass simpleObj = new SimpleClass();
        return;
    }
}

图表8 显示出了SimpleClas对象实例在Visual Studio Debugger内存窗口中的一个例子. 我们在图表7的return语句上下断点, 然后用在寄存器ECX中存储的simpleObj的地址来在内存窗口中显示对象的实例. 头4个字节的块就是syncblk number. 因为我们之前没有在任何synchronizing的代码中使用这个实例, 它被设置为0. 以变量形式存在栈中的的对象引用, 指向偏移量为4的四个字节. 字节变量b1, b2, b3和b4都被一个挨着一个的排放着. 两个short型的变量被放在一起. 字符串型的变量str是一个4字节的OBJECTREF, 指向GC堆中字符串实际存在的地址. 字符串是一种特殊的类型, 在assembly加载的进程中, 它们的所有包含着相同内容的实例, 都会被指向相同的在全局字符串表中的那一份唯一实例. 这个进程叫做string interning, 是用来优化内存的使用的.

如同我们之前提到的, 在.NET Framework1.1中, 一个assbmbly不可能从这个interning process中退出(opt out of), 尽管未来的CLR版本可能会修改这种能力.

图表8 调试器内存窗口中的object instance- Debugger Memory Window for Object Instance

所以, 默认情况下, 在源代码中声明的成员变量的字面顺序, 在内存中并不会被保留下来. 在Interop的场景下, 变量的字面顺序必须被正向的依次放到内存中, StructLayoutAttribute属性可以用来完成这个设定, 该属性接受LayoutKind枚举类型的变量作为参数. LayoutKind.Sequential会为marshaled的数据设定字面的顺序, 尽管在.NET Framework 1.1中,这个设定还不会对托管布局生效.(.NET Framework 2.0就会了). 在interop场景下, 你实在需要额外的填充(padding)和显式的对于数据域顺序的控制时, LayoutKind.Explicit可以和FieldOffset这个修饰符结合起来在field level帮助您达到目的.

看过了原始内存的内容, 让我们用SOS来看一下对象实例吧. 一个有用的命令是DumpHeap, 它可以列出针对某一类型的所有堆中的内容, 还有这一类型的所有实例. 不依赖寄存器, DumpHeap命令可以show出我们创建的唯一实例的地址.

---------------------------------------------------
!DumpHeap -type SimpleClass
Loaded Son of Strike data table version 5 from
"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorwks.dll"
 Address       MT     Size
00a8197c 00955124       36
Last good object: 00a819a0
total 1 objects
Statistics:
      MT    Count TotalSize Class Name
  955124        1        36 SimpleClass

整个对象的大小是36字节. 不论字符串多大, SimpleClass的instance中只包含一个DWORD OBJECTREF. SimpleClass的实例变量只占28个字节. 剩下的八个字节是由TypeHandle(4字节), 和syncblk number(4字节)组成的.

找到了simpleObj实例的地址后, 让我们用DumpObj命令来dump出这个实例吧, 如下:

---------------------------------------------------
!DumpObj 0x00a8197c
Name: SimpleClass
MethodTable 0x00955124
EEClass 0x02ca33b0
Size 36(0x24) bytes
FieldDesc*: 00955064
      MT    Field   Offset                 Type       Attr    Value Name
00955124  400000a        4         System.Int64   instance      31 l1
00955124  400000b        c                CLASS   instance 00a819a0 str
    << some fields omitted from the display for brevity >>
00955124  4000003       1e          System.Byte   instance        3 b3
00955124  4000004       1f          System.Byte   instance        4 b4

如上所述, 由C#编译器生成的类的默认布局是LayoutType.Auto. 对于结构体来说是LayoutType.Sequential. 由于class loader重新安排了实例的数据域, 所以填充(padding)的部分达到了最小化. 我们可以用ObjSize命令来dump出实例占用空间的图示. 这里是输出结果:

---------------------------------------------------
!ObjSize 0x00a8197c
sizeof(00a8197c) =       72 (    0x48) bytes (SimpleClass)

******************************************************************************************************

Son of Strike

在本文中, SOS调试器扩展时用来展现CLR数据结构内容的.

它是.NET Framework安装程序的一部分, 位置在%windir%\Microsoft.NET\Framework\v1.1.4322.

在你加载SOS到你的进程之前, 在Visual Studio .NET的工程属性里选择允许托管代码调试.(enable managed debugging)

添加SOS.dll所在的文件夹到环境变量中. 要在断点时, 加载SOS.dll, 打开Debug | Windows | Immediate. 在Immediate窗口中,

执行.load sos.dll命令. 用!help命令来得到关于debugger 命令的帮助. 更多关于SOS的信息, 参见the June 2004 Bugslayer column

******************************************************************************************************

如果你从object graph的大小(72字节)减去SimpleClass实例的大小(36字节), 你会得到变量str的长度(36字节). 让我们通过dump出这个字符串实例来确认一下吧. 输出结果如下:

---------------------------------------------------
!DumpObj 0x00a819a0
Name: System.String
MethodTable 0x009742d8
EEClass 0x02c4c6c4
Size 36(0x24) bytes

如果你把字符串的长度(36字节)加上SimpleClass实例的大小(36字节), 你就得到了对象的整个大小(72字节), 正与前面ObjSize命令的结果相同.

注意, ObjSize方法并不包括由syncblk架构占用的内存. 在.NET Framework 1.1中, CLR并不了解被非托管资源占据的内存, 比如说GDI对象, COM对象, 文件句柄等等. 因此, 他们的大小是不会被这个命令的结果报告中反映出来的.

TypeHandle, 是一个指向MethodTable的指针, 它的位置紧跟在syncblk number之后. 在一个对象实例创建之前, CLR会查询加载了的类型,

如果这个类型没有找到就加载它, 获得类型的MethodTable的地址, 创建对象实例, 然后填充对象的TypeHandle值. JIT编译器产生的代码使用TypeHandle来寻找MethodTable, 用于实现method dispatching. CLR可以在任何时候通过TypeHandle指向的MethodTable来反向追溯已经加载了的类型.

方法表- MethodTable

=================

任何一个类或者接口, 当他们加载到AppDomain当中的时候, 都会由一个叫做MethodTable数据结构来代表. 在对象的第一个实例都还没被加载的情况下，创建出一个MethodTable是类的加载动作的执行成果。

ObjectInstance代表的是对象的状态, MethodTable代表的是对象的行为.

MethodTable把object instance与language compiler-generated memory-mapped metadata structures, 通过EEClass联系起来. 在MethodTable中的信息和metadata structure可以在托管代码中通过Systen.Type来访问到.

在托管代码中, 一个指向MethodTable的指针可以通过Type.RuntimeTypeHandle属性来获得. TypeHandle, 存在于ObjectInstance中, 它指向一个偏移量, 这个偏移量是从MethodTable的首地址算起的. 这里的偏移量默认是12字节。这开头的12个字节包含GC的一些信息, 我们并不打算在这里讨论这些信息.

图表9展现了一个典型的MethodTable的布局. 我们会show一些重要的TypeHandle的数据域, 但是为了一个更完整的列表, 还是看图表吧. 让我们从Base Instance Size开始吧, 因为它与运行时的内存轮廓有直接关系.

图表9 方法表布局- MethodTable Layout

基本实例尺寸-Base Instance Size

===========================

基本实例尺寸是由class loader计算出来的对象的大小, 是基于代码中的数据域声明来计算的. 如同前面讨论的, 当前GC的实现需要一个对象的大小至少是12个字节. 如果一个类没有任何的实例数据域被定义, 它会白白的用前4个字节作为占位字节. 剩下的8字节会被Object Header(可能包括一个syncblk number), 和TypeHandle占据. 再次强调, 对象的大小是可以被StructLayoutAttribute属性影响的.

看看图表3(MyClass和两个接口)中MyClass的MethodTable的内存快照吧(Visual Studio .NET 2003 memory window). 请拿它和SOS生成的输出结果进行比较. 在图表9中, 对象大小是在4字节的偏移量的地方的, 其值为12 (0×0000000C)字节. 下面是 SOS中命令DumpHeap的输出结果

--------------------------------------
!DumpHeap -type MyClass
 Address       MT     Size
00a819ac 009552a0       12
total 1 objects
Statistics:
    MT  Count TotalSize Class Name
9552a0      1        12    MyClass

方法槽表-Method Slot Table

======================

在MethodTable中内嵌的是一张指向各自方法的方法描述器(MethodDesc)的指针组成的表格. 他们的存在允许了这个类型拥有一些行为. Method Slot表是根据按如下顺序实现了的方法的线性表来创建的: 继承的虚函数, 新虚函数, 实例方法, 和静态方法.(Inherited virtuals, Introduced virtuals, Instance Methods, and Static Methods).

ClassLoader遍历当前类的, 基类的, 和接口的metadata, 然后创建出method table. 在layout process, 任何重载了的虚函数都会被取代, 取代并隐藏父类的方法, 创建新的slot, 必要的情况下复制slot. 对slot的复制对于创建一个illusion是必不可少的, 所谓illusion是指每个接口都有他自己的小虚函数表. 然而, 复制的slot指向相同的物理实现. MyClass有三个实例方法, 一个类构造函数(.cctor), 和一个对象构造函数(.ctor). 对象构造函数是由C#编译器为所有没有显式定义构造函数的对象,自动生成的. 类构造函数是由编译器生成的, 因为我们定义并初始化了一个静态变量. 图表10 显示出了MyClass

的方法表的布局. 布局显示出了10个方法, 为了IVMap，Method2有重复的slot，这个重复将会在后面介绍. 图表11显示了MyClass的方法表在编辑过后的SOS dump.

图表10 MyClass的方法表布局

图表11 SOS Dump of MyClass Method Table

-----------------------------------------------
!DumpMT -MD 0x9552a0
  Entry  MethodDesc  Return Type       Name
0097203b 00972040    String            System.Object.ToString()
009720fb 00972100    Boolean           System.Object.Equals(Object)
00972113 00972118    I4                System.Object.GetHashCode()
0097207b 00972080    Void              System.Object.Finalize()
00955253 00955258    Void              MyClass.Method1()
00955263 00955268    Void              MyClass.Method2()
00955263 00955268    Void              MyClass.Method2()
00955273 00955278    Void              MyClass.Method3()
00955283 00955288    Void              MyClass..cctor()
00955293 00955298    Void              MyClass..ctor()

任何类型的头四个方法永远都会是ToString, Equals, GetHashCode, 和Finalize.

他们是从System.Object继承来的虚方法. Method2的slot是duplicated的, 但是二者都指向相同的方法描述器(method descriptor). 显式编码的.cctor会和静态方法分为一组, .ctor会和实例方法分为一组. (The explicitly coded .cctor and .ctor will be grouped with static methods and instance methods, respectively.)

方法描述- MethodDesc

======================

方法描述(Method Descriptor)(MethodDesc)是方法实现的的一种封装, CLR是知道，了解这种封装的. 有好几种Method Descriptor, 他们的存在不仅使得调用托管代码的实现更容易, 而且使得对interop的实现的调用也变得容易了一些. 在这篇文章中, 我们只研究以图表3的代码为上下文的托管MethodDesc.

一个MethodDesc是作为类加载过程的一部分(class loading process)而产生出来的, MethodDesc初始情况下指向中间语言Intermediate Language(IL).

每一个MethodDesc都被一个叫做PreJitStub的填充, PreJitStub负责触发JIT的编译过程.

图表12展示了一个典型的布局. 方法表的slot entry实际指向PreJitStub, 而不是指向实际的MethodDesc. 这是一个从MethodDesc算起, 负5个字节的偏移量, 并且是每个方法继承的8个字节的填充的一部分.

那五个字节包含调用PreJitStub函数的指令. 这5字节的偏移量可以从SOS的DumpMT命令的结果输出中看到(图表11的MyClass), 因为MethodDesc总是在MethodSlot Table入口指向的位置往后数5个字节的位置上. 紧接着第一个调用, 一个对于JIT编译函数的调用被触发. 在编译结束之后, 这五个字节所包含的调用指令会被覆盖为一条无条件转移到JIT编译的x86的代码的jmp指令.

图表12 Method Descriptor

在图表12中的Method Table Slot入口指向的代码的反汇编结果中, 显示出了对于PreJitStub的调用. 这是一个删节了的Method2的在JIT之前的反汇编代码:

-------------------------------
!u 0x00955263
Unmanaged code
00955263 call        003C3538        ;call to the jitted Method2()
00955268 add         eax,68040000h   ;ignore this and the rest
                                     ;as !u thinks it as code

现在让我们执行这个方法并且反汇编同样的地址:

--------------------------------
!u 0x00955263
Unmanaged code
00955263 jmp     02C633E8        ;call to the jitted Method2()
00955268 add     eax,0E8040000h  ;ignore this and the rest
                                 ;as !u thinks it as code

只有从给定地址开始的五个字节内容是代码, 后面包含的是Method2的MethodDesc的数据. 这里的”!u”命令对这一点是不知情的, 所以生成了一些胡言乱语, 故尔你可以忽略那五个字节之后的任何东西(它们不是指令).

CodeOrIL在JIT编译之前, 包含方法实现的IL码的Relative Virtual Address(RVA). 这个数据域被一个标志位标识: 其中存储的是IL. 一经要求, CLR完成了编译之后, CLR会使用JIT处理过的代码的地址来更新这个数据域.让我们从列表中选择一个方法, 然后使用DumpMT命令dump出来JIT编译之前和之后的MethodDesc吧:

---------------------------------
!DumpMD 0x00955268
Method Name : [DEFAULT] [hasThis] Void MyClass.Method2()
MethodTable 9552a0
Module: 164008
mdToken: 06000006
Flags : 400
IL RVA : 00002068

编译之后, MethodDesc看起来像这样:

---------------------------------
!DumpMD 0x00955268
Method Name : [DEFAULT] [hasThis] Void MyClass.Method2()
MethodTable 9552a0
Module: 164008
mdToken: 06000006
Flags : 400
Method VA : 02c633e8

在方法描述器(method descriptor)中的Flags数据域会根据方法的类型来编码, 所谓方法类型是指: 静态方法, 实例方法, 接口方法, 或者是COM实现方法.

让我们看看MethodTable的复杂的另一面吧: Interface implementation.

托管环境下, Interface implementation被实现的看起来简单一些, 达到这个效果的方式是把所有的复杂度都吸收到布局过程中. 下一步, 我们将要show给你接口是如何布局的, 还有基于接口的方法分派(method dispatching)是如何工作的.

接口虚表映射和接口映射- Interface Vtable Map and Interface Map

=====================================================

在MethodTable中, 偏移量为12的位置, 存储着一个重要的指针, IVMap. 如图表9, IVMap指向一个AppDomain等级的映射表, 该映射表以一个进程等级的接口ID为索引. 这个接口ID是在接口类型第一次加载的时候生成的. 任何一个接口的实现都会有一个IVMap的入口. 如果MyInterface1被两个类实现了, 那么在接口的IVMap中就会有两个入口. 入口会指回到MyClass的方法表内嵌的sub-table的开头, 见图表9. 这个是method dispatching发生时, 基于接口的索引. IVMap是根据内嵌在方法表中的Interface Map的信息而创建出来的. Interface Map是在布局方法表的过程中, 根据类的metadata创建出来的. 一旦类型加载结束, 只有IVMap会在method dispatching中使用到.

Interface Map在偏移量28的位置, 它会指向内嵌在MethodTable中的InterfaceInfo的入口. 这样, 对于两个被MyClass实现了的接口中的任何一个接口, 都会有两个入口了.

第一个InterfaceInfo入口的头四个字节指向MyInterface1的TypeHandle(参考图表9和图表10).

接下来的WORD(两字节)被Flags占据(其中0是指继承自父类, 1指的是被当前类实现).

从Flags再接下来的WORD是Start Slot, 通过它, class loader得以编排接口实现的sub-table. 对于MyInterface1, 这个值是4, 意味slot 5 和slot 6指向implementation. 对于MyInterface2, 这个值是6, 所以, slot 7 和slot 8 指向implementation. 如果必要的话, ClassLoader会复制这些slot来创建illusion. 这里的illusion指在物理映射到相同的method descriptor的同时, 任何一个接口都得到了自己的实现. 在MyClass中, MyInterface1.Method2 和MyInterface2.Method2会指向相同的实现.

基于接口的方法分派(method dispatching)是通过IVMap发生的, 而直接的方法分派是通过各自槽的MethodDesc的地址发生的. 如前所述, .NET Framework使用fastcall这种调用约定. 如果可能的话, 头两个参数典型地被传入ECX和EDX寄存器(译注:参见文章汇编语言基础之六- 调用栈和各种调用约定的总结对比)(最左边参数, 通过ECX传递, 第二个, 通过EDX传递).

对象实例的方法中, 第一个参数永远是this指针, 通过ECX来传递. 下面的语句中”mov ecx, esi”展示了这一点.

-------------------------------------
mi1.Method1();
mov    ecx,edi                 ;move "this" pointer into ecx
mov    eax,dword ptr [ecx]     ;move "TypeHandle" into eax
mov    eax,dword ptr [eax+0Ch] ;move IVMap address into eax at offset 12
mov    eax,dword ptr [eax+30h] ;move the ifc impl start slot into eax
call   dword ptr [eax]         ;call Method1

mc.Method1();
mov    ecx,esi                 ;move "this" pointer into ecx
cmp    dword ptr [ecx],ecx     ;compare and set flags
call   dword ptr ds:[009552D8h];directly call Method1

这里的反汇编代码表明了在对MyClass的实例方法的直接调用中, 并没有使用偏移量. JIT编译器将MethodDesc的地址直接的用在了代码中. 基于接口的方法分派是通过IVMap来发生的, 并且比直接分派需要多一些指令. 一条用来拿到IVMap的地址, 另一条拿到MethodTable中接口实现的start slot. 并且, 将一个对象实例转换为一个接口也仅仅是拷贝一下这个指针到目标变量当中就可以了. 在图表3 【译注：原文中这个地方时图表2，显然有错误，应该是图表3】中, 语句 “mi1 = mc;” 只用了一条指令就把mc中的OBJECTREF拷贝给了mi1.

虚拟分派- Virtual Dispatch

========================

让我们来看一下虚拟分派吧, 恩, 再比较一下跟基于接口的直接分派有什么不同. 下面是图表3中对于虚方法MyClass.Method3调用的反汇编代码:

-----------------------------
mc.Method3();
Mov    ecx,esi               ;move "this" pointer into ecx
Mov    eax,dword ptr [ecx]   ;acquire the MethodTable address
Call   dword ptr [eax+44h]   ;dispatch to the method at offset 0x44

虚拟分派总是通过一个定死了的slot number来发生, 与给定的类的实现层次的MethodTable指针无关. 在MethodTable布局的时候, ClassLoader替换掉父类的实现, 而使用子类的实现. 结果, 对于父类对象的方法调用被分派到子类对象的实现上. 反汇编代码展现了分派通过slot number 8来发生的, debugger memory window中的DumpMT命令的输出结果也是这样(见图表10).

静态变量- Static Variables

========================

静态变量是MethodTable数据结构的重要组成部分. 他们在method table slot数组之后被分配在MethodTable上. 所有原始的静态类型都是内联的, 而静态值类型(结构体), 引用类型是通过AppDomain的handle table(句柄表)上的OBJECTREF来引用的. MethodTable中的OBJECTREF指向AppDomain的句柄表中的OBJECTREF, 这个OBJECTREF会使得堆上创建出来的对象实例一直存活下去, 直到AppDomain被卸载掉. 在图表9中, 一个静态的字符串变量, str, 指向句柄表中的OBJECTREF, 而这个OBJECTREF指向GC堆上的MyString.

EEClass

========================

EEClass在MethodTable被创建之前就存在了, 在与MethodTable结合的时候, 是一个类型声明的CLR版. 实际上, EEClass和MethodTable在逻辑上是一个数据结构(他们共同代表一个单个类型), 他们中的内容是基于使用频率不同而分开的. 非常经常使用的数据域存在MethodTable中, 而不太经常使用的数据域存在EEClass中. 所以, JIT编译函数需要的信息(比如说names, fields, 和offsets)就存在EEClass中, 然而, 运行时需要的信息(比如虚表slot和GC信息)就存在MethodTable中.

加载到AppDomain中的任何一个类型都有一个EEClass. 这里所说的类型包括: 接口, 类, 抽象类, 数组, 和结构体. 任何一个EEClass 都是被执行引擎跟踪的树的节点. 为了诸如：加载类, 布局MethodTable, 辨别类型, 类型转换，这样的目的, CLR使用这个网络来导航到需要的EEClass结构. EEClass之间的孩子到父亲的关系是基于继承关系来创建的, 然而, 从父亲到孩子的关系是建立在继承关系和类的加载顺序的联合的基础上的. 随着在托管代码的执行, 新的EEClass节点被一个个的添加, 旧的节点之间的关系被不断修补, 新的节点关系也被建立起来.

网络中EEClass的兄弟之间还有水平的关系呢. EEClass有三个数据域被用来建立加载起来的类型之间的关系: ParentClass, SiblingChain, 和ChildrenChain. 参见图表13, 来看看以图表4为上下文的MyClass的EEClass的扼要图解.

图表13展现了一些与我们的讨论相关联的数据域. 因为我们忽略了布局中的一些数据域, 我们并没有在这张图表中展现出真是的偏移量. EEClass有一个针对MethodTable的环形引用. EEClass也指向在默认AppDomain的高频堆中分配的MethodDesc块. 进程堆上有一个对FieldDesc对象列表的引用, 它提供了在MethodTable创建时的field布局信息. EEClass在AppDomain的低频堆上, 这样,操作系统可以更好的进行内存的页面管理, 因此减小了working set.

图表13 EEClass布局- EEClass Layout

================================

图表13中的其他数据域光看名字就能理解他们在MyClass(图表3)上下文中的作用了. 让我们看一下使用SOS工具dump出的EEClass的真实物理内存吧. 在mc.Method1这一行设定断点后, 运行图表3中的代码.首先, 通过运行命令!Name2EE获得MyClass的EEClass的地址:

————————————

!Name2EE C:\Working\test\ClrInternals\Sample1.exe MyClass

MethodTable: 009552a0
EEClass: 02ca3508
Name: MyClass

Name2EE命令的第一个参数是模块名称, 这个模块名称可以通过DumpDomain命令来获得. 现在我们有了EEClass的地址了, 我们来dump出EEClass的内容:

—————————————–

!DumpClass 02ca3508
Class Name : MyClass, mdToken : 02000004, Parent Class : 02c4c3e4
ClassLoader : 00163ad8, Method Table : 009552a0, Vtable Slots : 8
Total Method Slots : a, NumInstanceFields: 0,
NumStaticFields: 2,FieldDesc*: 00955224

      MT    Field   Offset  Type           Attr    Value    Name
009552a0  4000001   2c      CLASS          static 00a8198c  str
009552a0  4000002   30      System.UInt32  static aaaaaaaa  ui

图表13和DumpClass的输出结果看起来本质上是相同的. Metadata token(mdToken)代表着模块PE文件映射在内存中的metadata表的index.

指向System.Object. Sibling 链(图表13)的Parent类, 说明了他的加载是加载Program类的结果造成的.

MyClass有8个vtable slot(可以被虚拟分派的方法). 尽管Method1和Method2并不是虚拟方法, 它们在通过接口来分派的时候,还是被认为是虚函数并添加到列表中. 算上.cctor和.ctor到列表中, 这样你就一共有10个方法了. 这个类有两个静态域, 都被列在后面了. MyClass没有实例域. 其余的域都挺自我说明问题的.

结论

=========

我们一起游历了一下CLR中最重要的一些内部信息. 很显然, 还有很多方面需要被覆盖到, 并且还要更加深入, 但是我们希望这篇文章可以给你一个CLR怎么工作的大致印象. 这里展现的很多的信息在未来版本的CLR和.NET Framework中可能会改变, 但是尽管这篇文章覆盖到的数据结构更改了, 概念是不会变的.

———————————————————–

来自：http://www.cnblogs.com/awpatp/archive/2009/11/11/1601397.html

深入理解.NET内存回收机制

艾榕 — Mon, 31 Oct 2011 21:21:57 +0800

［前言：］.Net平台提供了许多新功能，这些功能能够帮助程序员生产出更高效和稳定的代码。其中之一就是垃圾回收器（GC）。这篇文章将深入探讨这一功能，了解它是如何工作的以及如何编写代码来更好地使用这一.Net平台提供的功能。

.Net中的内存回收机制

垃圾回收器是用来管理应用程序的内存分配和释放的。在垃圾回收器出现以前，程序员在使用内存时需要向系统申请内存空间。有些语言，例如Visual Basic，可以自动完成向系统申请内存空间的工作。但是在诸如Visual C++的语言中要求程序员在程序代码中申请内存空间。如果程序员在使用了内存之后忘了释放内存，则会引起内存泄漏。但是有了垃圾回收器，程序员就不必关心内存中对象在离开生存期后是否被释放的问题。当一个应用程序在运行的时候，垃圾回收器设置了一个托管堆。托管堆和C语言中的堆向类似，但是程序员不需要从托管堆中释放对象，并且在托管堆中对象的存放是连续的。

每次当开发人员使用 new 运算符创建对象时，运行库都从托管堆为该对象分配内存。新创建的对象被放在上次创建的对象之后。垃圾回收器保存了一个指针，该指针总是指向托管堆中最后一个对象之后的内存空间。当新的对象被产生时，运行库就知道应该将新的对象放在内存的什么地方。同时开发人员应该将相同类型的对象放在一起。例如当开发人员希望向数据库写入数据的时侯，首先需要创建一个连接对象，然后是Command对象，最后是DataSet对象。如果这些对象放在托管堆相邻的区域内，存取它们就非常快。

当垃圾回收器的指针指向托管堆以外的内存空间时，就需要回收内存中的垃圾了。在这个过程中，垃圾回收器首先假设在托管堆中所有的对象都需要被回收。然后它在托管堆中寻找被根对象引用的对象（根对象就是全局，静态或处于活动中的局部变量以及寄存器指向的对象），找到后将它们加入一个有效对象的列表中，并在已经搜索过的对象中寻找是否有对象被新加入的有效对象引用。直到垃圾回收器检查完所有的对象后，就有一份根对象和根对象直接或间接引用了的对象的列表，而其它没有在表中的对象就被从内存中回收。

当对象被加入到托管堆中时，如果它实现了finalize（）方法，垃圾回收器会在它的终结列表（Finalization List）中加入一个指向该对象的指针。当该对象被回收时，垃圾回收器会检查终结列表，看是否需要调用对象的finalize（）方法。如果有的话，垃圾回收器将指向该对象的指针加入一个完成器队列中，该完成器队列保存了那些准备调用finalize（）方法的对象。到了这一步对象还不是真正的垃圾对象。因此垃圾回收器还没有把他们从托管堆中回收。

当对象准备被终结时，另一个垃圾回收器线程会调用在完成器队列中每个对象的finalize（）方法。当调用完成后，线程将指针从完成器队列中移出，这样垃圾回收器就知道在下一次回收对象时可以清除被终结的对象了。从上面可以看到垃圾回收机制带来的很大一部分额外工作就是调用finalize（）方法，因此在实际编程中开发人员应该避免在类中实现finalize（）方法。

对于finalize（）方法的另一个问题是开发人员不知道什么时候它将被调用。它不像C++中的析构函数在删除一个对象时被调用。为了解决这个问题，在.Net中提供了一个接口IDisposable。微软建议在实现带有fianlize（）方法的类的时侯按照下面的模式定义对象：

public class Class1 : IDisposable
{
public Class1()
{
}

~Class1 ()
{
//垃圾回收器将调用该方法，因此参数需要为false。
Dispose (false);
}

//该方法定义在IDisposable接口中。
public void Dispose ()
{
//该方法由程序调用，在调用该方法之后对象将被终结。
//因为我们不希望垃圾回收器再次终结对象，因此需要从终结列表中去除该对象。
GC.SuppressFinalize (this);
//因为是由程序调用该方法的，因此参数为true。
Dispose (true);
}

//所有与回收相关的工作都由该方法完成
private void Dispose(bool disposing)
{
lock(this) //避免产生线程错误。
{
if (disposing)
{
//需要程序员完成释放对象占用的资源。
}

//对象将被垃圾回收器终结。在这里添加其它和清除对象相关的代码。
}
}
}

现在我们了解了垃圾回收器工作的基本原理，接下来让我们看一看垃圾回收器内部是如何工作的。目前有很多种类型的垃圾回收器。微软实现了一种生存期垃圾回收器（Generational Garbage Collector）。生存期垃圾回收器将内存分为很多个托管堆，每一个托管堆对应一种生存期等级。生存期垃圾回收器遵循着下面的原则：

新生成的对象，其生存期越短；而对象生成时间越长的对象，其生存期也就越长。对于垃圾回收器来说，回收一部分对象总是比回收全部对象要快，因此垃圾回收器对于那些生存期短的对象回收的频率要比生存期长的对象的回收频率高。

.Net中的垃圾回收器中目前有三个生存期等级：0，1和2。0、1、2等级对应的托管堆的初始化大小分别是256K，2M和10M。垃圾回收器在发现改变大小能够提高性能的话，会改变托管堆的大小。例如当应用程序初始化了许多小的对象,并且这些对象会被很快回收的话，垃圾回收器就会将0等级的托管堆变为128K，并且提高回收的频率。如果情况相反，垃圾回收器发现在0等级的托管堆中不能回收很多空间时，就会增加托管堆的大小。
在应用程序初始化的之前，所有等级的托管堆都是空的。当对象被初始化的时候，他们会按照初始化的先后顺序被放入等级为0的托管堆中。在托管堆中对象的存放是连续的，这样使得托管堆存取对象的速度很快，因为托管对不必对内存进行搜索。垃圾回收器中保存了一个指针指向托管堆中最后一个对象之后的内存空间。图一中显示了一个包含四个对象的0等级的托管堆。

图一包含四个对象的托管堆

当0等级托管堆被对象填满后，例如候程序初始化了新的对象，使0等级托管堆的大小超过了256K，垃圾回收器会检查托管堆中的所有对象，看是否有对象可以回收。当开始回收操作时，如前面提到的，垃圾回收器会找出根节点和根节点直接或间接引用了的对象，然后将这些对象转移到1等级托管堆中，并将0等级托管堆的指针移到最开始的位置以清除所有的对象。同时垃圾回收器会压缩1等级托管堆以保证所有对象之间没有内存空隙。当1等级托管堆满了之后，会将对象转移到2等级的托管堆。

例如在图一之后，垃圾回收器开始回收对象，假定D对象将被回收，同时程序创建了E和F对象。这时候托管堆中的对象如图二所示。

图二回收对象后的0等级和1等级托管堆

然后程序创建了新的对象G和H，再一次触发了垃圾回收器。对象E将被回收。这时候托管堆中的对象如图三所示。

生存期垃圾回收器的原则也有例外的情况。当对象的大小超过84K时，对象会被放入”大对象区”。大对象区中的对象不会被垃圾回收器回收，也不会被压缩。这样做是为了强制垃圾回收器只能回收小对象以提高程序的性能。

控制垃圾回收器

在.Net框架中提供了很多方法使开发人员能够直接控制垃圾回收器的行为。通过使用GC.Collect（）或GC.Collect（int GenerationNumber）开发人员可以强制垃圾回收器对所有等级的托管堆进行回收操作。在大多数的情况下开发人员不需要干涉垃圾回收器的行为，但是有些情况下，例如当程序进行了非常复杂的操作后希望确认内存中的垃圾对象已经被回收，就可以使用上面的方法。另一个方法是GC.WaitForPendingFinalizers（），它可以挂起当前线程，直到处理完成器队列的线程清空该队列为止。

使用垃圾回收器最好的方法就是跟踪程序中定义的对象，在程序不需要它们的时候手动释放它们。例如程序中的一个对象中有一个字符串属性，该属性会占用一定的内存空间。当该属性不再被使用时，开发人员可以在程序中将其设定为null，这样垃圾回收器就可以回收该字符串占用的空间。另外，如果开发人员确定不再使用某个对象时，需要同时确定没有其它对象引用该对象，否则垃圾回收器不会回收该对象。

另外值得一提的是finalize（）方法应该在较短的时间内完成，这是因为垃圾回收器给finalize（）方法限定了一个时间，如果finalize（）方法在规定时间内还没有完成，垃圾回收器会终止运行finalize（）方法的线程。在下面这些情况下程序会调用对象的finalize（）方法：

0等级垃圾回收器已满

程序调用了执行垃圾回收的方法

公共语言运行库正在卸载一个应用程序域

公共语言运行库正在被卸载

来自：http://www.cnblogs.com/lovewangshu/archive/2004/06/04/13266.html

关于字符编码，你所需要知道的

艾榕 — Mon, 31 Oct 2011 21:19:21 +0800

字符编码的问题看似很小，经常被技术人员忽视，但是很容易导致一些莫名其妙的问题。这里总结了一下字符编码的一些普及性的知识，希望对大家有所帮助。

还是得从ASCII码说起

说到字符编码，不得不说ASCII码的简史。计算机一开始发明的时候是用来解决数字计算的问题，后来人们发现，计算机还可以做更多的事，例如文本处理。但由于计算机只识“数”，因此人们必须告诉计算机哪个数字来代表哪个特定字符，例如65代表字母‘A’，66代表字母‘B’，以此类推。但是计算机之间字符-数字的对应关系必须得一致，否则就会造成同一段数字在不同计算机上显示出来的字符不一样。因此美国国家标准协会ANSI制定了一个标准，规定了常用字符的集合以及每个字符对应的编号，这就是ASCII字符集（Character Set），也称ASCII码。

当时的计算机普遍使用8比特字节作为最小的存储和处理单元，加之当时用到的字符也很少，26个大小写英文字母还有数字再加上其他常用符号，也不到100个，因此使用7个比特位就可以高效的存储和处理ASCII码，剩下最高位1比特被用作一些通讯系统的奇偶校验。

注意，字节代表系统能够处理的最小单位，不一定是8比特。只是现代计算机的事实标准就是用8比特来代表一个字节。在很多技术规格文献中，为了避免产生歧义，更倾向于使用8位组（Octet）而不是字节（Byte）这个术语来强调8个比特的二进制流。下文中为了便于理解，我会延用大家熟悉的“字节”这个概念。

ASCII字符集由95个可打印字符（0×20-0×7E）和33个控制字符（0×00-0×19，0×7F）组成。可打印字符用于显示在输出设备上，例如荧屏或者打印纸上，控制字符用于向计算机发出一些特殊指令，例如0×07会让计算机发出哔的一声，0×00通常用于指示字符串的结束，0×0D和 0×0A用于指示打印机的打印针头退到行首（回车）并移到下一行（换行）。

那时候的字符编解码系统非常简单，就是简单的查表过程。例如将字符序列编码为二进制流写入存储设备，只需要在ASCII字符集中依次找到字符对应的字节，然后直接将该字节写入存储设备即可。解码二进制流的过程也是类似。

OEM字符集的衍生

当计算机开始发展起来的时候，人们逐渐发现，ASCII字符集里那可怜的128个字符已经不能再满足他们的需求了。人们就在想，一个字节能够表示的数字（编号）有256个，而ASCII字符只用到了0×00~0×7F，也就是占用了前128个，后面128个数字不用白不用，因此很多人打起了后面这 128个数字的主意。可是问题在于，很多人同时有这样的想法，但是大家对于0×80-0xFF这后面的128个数字分别对应什么样的字符，却有各自的想法。这就导致了当时销往世界各地的机器上出现了大量各式各样的OEM字符集。

下面这张表是IBM-PC机推出的其中一个OEM字符集，字符集的前128个字符和ASCII字符集的基本一致（为什么说基本一致呢，是因为前32 个控制字符在某些情况下会被IBM-PC机当作可打印字符解释），后面128个字符空间加入了一些欧洲国家用到的重音字符，以及一些用于画线条画的字符。

事实上，大部分OEM字符集是兼容ASCII字符集的，也就是说，大家对于0×00~0×7F这个范围的解释基本是相同的，而对于后半部分0×80~0xFF的解释却不一定相同。甚至有时候同样的字符在不同OEM字符集中对应的字节也是不同的。

不同的OEM字符集导致人们无法跨机器交流各种文档。例如职员甲发了一封简历résumés给职员乙，结果职员乙看到的却是rsums，因为é字符在职员甲机器上的OEM字符集中对应的字节是0×82，而在职员乙的机器上，由于使用的OEM字符集不同，对0×82字节解码后得到的字符却是。

多字节字符集（MBCS）和中文字符集

上面我们提到的字符集都是基于单字节编码，也就是说，一个字节翻译成一个字符。这对于拉丁语系国家来说可能没有什么问题，因为他们通过扩展第8个比特，就可以得到256个字符了，足够用了。但是对于亚洲国家来说，256个字符是远远不够用的。因此这些国家的人为了用上电脑，又要保持和ASCII字符集的兼容，就发明了多字节编码方式，相应的字符集就称为多字节字符集。例如中国使用的就是双字节字符集编码（DBCS，Double Byte Character Set）。

对于单字节字符集来说，代码页中只需要有一张码表即可，上面记录着256个数字代表的字符。程序只需要做简单的查表操作就可以完成编解码的过程。

代码页是字符集编码的具体实现，你可以把他理解为一张“字符-字节”映射表，通过查表实现“字符-字节”的翻译。下面会有更详细的描述。

而对于多字节字符集，代码页中通常会有很多码表。那么程序怎么知道该使用哪张码表去解码二进制流呢？答案是，根据第一个字节来选择不同的码表进行解析。

例如目前最常用的中文字符集GB2312，涵盖了所有简体字符以及一部分其他字符；GBK（K代表扩展的意思）则在GB2312的基础上加入了对繁体字符等其他非简体字符（GB18030字符集不是双字节字符集，我们在讲Unicode的时候会提到）。这两个字符集的字符都是使用1-2个字节来表示。Windows系统采用936代码页来实现对GBK字符集的编解码。在解析字节流的时候，如果遇到字节的最高位是0的话，那么就使用936代码页中的第1张码表进行解码，这就和单字节字符集的编解码方式一致了。

当字节的高位是1的时候，确切的说，当第一个字节位于0x81–0xFE之间时，根据第一个字节不同找到代码页中的相应的码表，例如当第一个字节是0x81，那么对应936中的下面这张码表：

（关于936代码页中完整的码表信息，参见MSDN：http://msdn.microsoft.com/en-us/library/cc194913%28v=MSDN.10%29.aspx.）

按照936代码页的码表，当程序遇到连续字节流0×81 0×40的时候，就会解码为“丂”字符。

ANSI标准、国家标准、ISO标准

不同ASCII衍生字符集的出现，让文档交流变得非常困难，因此各种组织都陆续进行了标准化流程。例如美国ANSI组织制定了ANSI标准字符编码（注意，我们现在通常说到ANSI编码，通常指的是平台的默认编码，例如英文操作系统中是ISO-8859-1，中文系统是GBK），ISO组织制定的各种ISO标准字符编码，还有各国也会制定一些国家标准字符集，例如中国的GBK，GB2312和GB18030。

操作系统在发布的时候，通常会往机器里预装这些标准的字符集还有平台专用的字符集，这样只要你的文档是使用标准字符集编写的，通用性就比较高了。例如你用GB2312字符集编写的文档，在中国大陆内的任何机器上都能正确显示。同时，我们也可以在一台机器上阅读多个国家不同语言的文档了，前提是本机必须安装该文档使用的字符集。

Unicode的出现

虽然通过使用不同字符集，我们可以在一台机器上查阅不同语言的文档，但是我们仍然无法解决一个问题：在一份文档中显示所有字符。为了解决这个问题，我们需要一个全人类达成共识的巨大的字符集，这就是Unicode字符集。

Unicode字符集概述

Unicode字符集涵盖了目前人类使用的所有字符，并为每个字符进行统一编号，分配唯一的字符码（Code Point）。Unicode字符集将所有字符按照使用上的频繁度划分为17个层面（Plane），每个层面上有2¹⁶=65536个字符码空间。

其中第0个层面BMP，基本涵盖了当今世界用到的所有字符。其他的层面要么是用来表示一些远古时期的文字，要么是留作扩展。我们平常用到的Unicode字符，一般都是位于BMP层面上的。目前Unicode字符集中尚有大量字符空间未使用。

编码系统的变化

在Unicode出现之前，所有的字符集都是和具体编码方案绑定在一起的，都是直接将字符和最终字节流绑定死了，例如ASCII编码系统规定使用7 比特来编码ASCII字符集；GB2312以及GBK字符集，限定了使用最多2个字节来编码所有字符，并且规定了字节序。这样的编码系统通常用简单的查表，也就是通过代码页就可以直接将字符映射为存储设备上的字节流了。例如下面这个例子：

这种方式的缺点在于，字符和字节流之间耦合得太紧密了，从而限定了字符集的扩展能力。假设以后火星人入住地球了，要往现有字符集中加入火星文就变得很难甚至不可能了，而且很容易破坏现有的编码规则。

因此Unicode在设计上考虑到了这一点，将字符集和字符编码方案分离开。

也就是说，虽然每个字符在Unicode字符集中都能找到唯一确定的编号（字符码，又称Unicode码），但是决定最终字节流的却是具体的字符编码。例如同样是对Unicode字符“A”进行编码，UTF-8字符编码得到的字节流是0×41，而UTF-16（大端模式）得到的是0×00 0×41。

常见的Unicode编码

UCS-2/UTF-16

如果要我们来实现Unicode字符集中BMP字符的编码方案，我们会怎么实现？由于BMP层面上有2¹⁶=65536个字符码，因此我们只需要两个字节就可以完全表示这所有的字符了。

举个例子，“中”的Unicode字符码是0×4E2D(01001110 00101101)，那么我们可以编码为01001110 00101101（大端）或者00101101 01001110 （小端）。

UCS-2和UTF-16对于BMP层面的字符均是使用2个字节来表示，并且编码得到的结果完全一致。不同之处在于，UCS- 2最初设计的时候只考虑到BMP字符，因此使用固定2个字节长度，也就是说，他无法表示Unicode其他层面上的字符，而UTF-16为了解除这个限制，支持Unicode全字符集的编解码，采用了变长编码，最少使用2个字节，如果要编码BMP以外的字符，则需要4个字节结对，这里就不讨论那么远，有兴趣可以参考维基百科：UTF-16/UCS-2。

Windows从NT时代开始就采用了UTF-16编码，很多流行的编程平台，例如.Net，Java，Qt还有Mac下的Cocoa等都是使用UTF-16作为基础的字符编码。例如代码中的字符串，在内存中相应的字节流就是用UTF-16编码过的。

UTF-8

UTF-8应该是目前应用最广泛的一种Unicode编码方案。由于UCS-2/UTF-16对于ASCII字符使用两个字节进行编码，存储和处理效率相对低下，并且由于ASCII字符经过UTF-16编码后得到的两个字节，高字节始终是0×00，很多C语言的函数都将此字节视为字符串末尾从而导致无法正确解析文本。因此一开始推出的时候遭到很多西方国家的抵触，大大影响了Unicode的推行。后来聪明的人们发明了UTF-8编码，解决了这个问题。

UTF-8编码方案采用1-4个字节来编码字符，方法其实也非常简单。

（上图中的x代表Unicode码的低8位，y代表高8位）

对于ASCII字符的编码使用单字节，和ASCII 编码一摸一样，这样所有原先使用ASCII编解码的文档就可以直接转到UTF-8编码了。对于其他字符，则使用2-4个字节来表示，其中，首字节前置1的数目代表正确解析所需要的字节数，剩余字节的高2位始终是10。例如首字节是1110yyyy，前置有3个1，说明正确解析总共需要3个字节，需要和后面 2个以10开头的字节结合才能正确解析得到字符。

关于UTF-8的更多信息，参考维基百科：UTF-8。

GB18030

任何能够将Unicode字符映射为字节流的编码都属于Unicode编码。中国的GB18030编码，覆盖了Unicode所有的字符，因此也算是一种Unicode编码。只不过他的编码方式并不像UTF-8或者UTF-16一样，将Unicode字符的编号通过一定的规则进行转换，而只能通过查表的手段进行编码。

关于GB18030的更多信息，参考：GB18030。

Unicode相关的常见问题

Unicode是两个字节吗？

Unicode只是定义了一个庞大的、全球通用的字符集，并为每个字符规定了唯一确定的编号，具体存储为什么样的字节流，取决于字符编码方案。推荐的Unicode编码是UTF-16和UTF-8。

带签名的UTF-8指的是什么意思？

带签名指的是字节流以BOM标记开始。很多软件会“智能”的探测当前字节流使用的字符编码，这种探测过程出于效率考虑，通常会提取字节流前面若干个字节，看看是否符合某些常见字符编码的编码规则。由于UTF-8和ASCII编码对于纯英文的编码是一样的，无法区分开来，因此通过在字节流最前面添加 BOM标记可以告诉软件，当前使用的是Unicode编码，判别成功率就十分准确了。但是需要注意，不是所有软件或者程序都能正确处理BOM标记，例如 PHP就不会检测BOM标记，直接把它当普通字节流解析了。因此如果你的PHP文件是采用带BOM标记的UTF-8进行编码的，那么有可能会出现问题。

Unicode编码和以前的字符集编码有什么区别？

早期字符编码、字符集和代码页等概念都是表达同一个意思。例如GB2312字符集、GB2312编码，936代码页，实际上说的是同个东西。但是对于Unicode则不同，Unicode字符集只是定义了字符的集合和唯一编号，Unicode编码，则是对UTF-8、UCS-2/UTF-16等具体编码方案的统称而已，并不是具体的编码方案。所以当需要用到字符编码的时候，你可以写gb2312，codepage936，utf-8，utf-16，但请不要写unicode（看过别人在网页的meta标签里头写charset=unicode，有感而发）。

乱码问题

乱码指的是程序显示出来的字符文本无法用任何语言去解读。一般情况下会包含大量?或者�。乱码问题是所有计算机用户或多或少会遇到的问题。造成乱码的原因就是因为使用了错误的字符编码去解码字节流，因此当我们在思考任何跟文本显示有关的问题时，请时刻保持清醒：当前使用的字符编码是什么。只有这样，我们才能正确分析和处理乱码问题。

例如最常见的网页乱码问题。如果你是网站技术人员，遇到这样的问题，需要检查以下原因：

服务器返回的响应头Content-Type没有指明字符编码
网页内是否使用META HTTP-EQUIV标签指定了字符编码
网页文件本身存储时使用的字符编码和网页声明的字符编码是否一致

注意，网页解析的过程如果使用的字符编码不正确，还可能会导致脚本或者样式表出错。具体细节可以参考我以前写过的文章：文档字符集导致的脚本错误和Asp.Net页面的编码问题。

不久前看到某技术论坛有人反馈，WinForm程序使用Clipboard类的GetData方法去访问剪切板中的HTML内容时会出现乱码的问题，我估计也是由于WinForm在获取HTML文本的时候没有用对正确的字符编码导致的。Windows剪贴板只支持UTF-8编码，也就是说你传入的文本都会被UTF-8编解码。这样一来，只要两个程序都是调用Windows剪切板API编程的话，那么复制粘贴的过程中不会出现乱码。除非一方在获取到剪贴板数据之后使用了错误的字符编码进行解码，才会得到乱码（我做了简单的WinForm剪切板编程实验，发现GetData使用的是系统默认编码，而不是UTF-8编码）。

关于乱码中出现?或者�，这里需要额外提一下，当程序使用特定字符编码解析字节流的时候，一旦遇到无法解析的字节流时，就会用?或者�来替代。因此，一旦你最终解析得到的文本包含这样的字符，而你又无法得到原始字节流的时候，说明正确的信息已经彻底丢失了，尝试任何字符编码都无法从这样的字符文本中还原出正确的信息来。

必要的术语解释

字符集（Character Set），字面上的理解就是字符的集合，例如ASCII字符集，定义了128个字符；GB2312定义了7445个字符。而计算机系统中提到的字符集准确来说，指的是已编号的字符的有序集合（不一定是连续）。

字符码（Code Point）指的就是字符集中每个字符的数字编号。例如ASCII字符集用0-127这连续的128个数字分别表示128个字符；GBK字符集使用区位码的方式为每个字符编号，首先定义一个94X94的矩阵，行称为“区”，列称为“位”，然后将所有国标汉字放入矩阵当中，这样每个汉字就可以用唯一的“区位”码来标识了。例如“中”字被放到54区第48位，因此字符码就是5448。而 Unicode中将字符集按照一定的类别划分到0~16这17个层面（Planes）中，每个层面中拥有2¹⁶=65536个字符码，因此Unicode总共拥有的字符码，也即是Unicode的字符空间总共有17*65536=1114112。

编码的过程是将字符转换成字节流。

解码的过程是将字节流解析为字符。

字符编码（Character Encoding）是将字符集中的字符码映射为字节流的一种具体实现方案。例如 ASCII字符编码规定使用单字节中低位的7个比特去编码所有的字符。例如‘A’的编号是65，用单字节表示就是0×41，因此写入存储设备的时候就是 b’01000001’。GBK编码则是将区位码（GBK的字符码）中的区码和位码的分别加上0xA0（160）的偏移（之所以要加上这样的偏移，主要是为了和ASCII码兼容），例如刚刚提到的“中”字，区位码是5448，十六进制是0×3630，区码和位码分别加上0xA0的偏移之后就得到 0xD6D0，这就是“中”字的GBK编码结果。

代码页（Code Page）一种字符编码具体形式。早期字符相对少，因此通常会使用类似表格的形式将字符直接映射为字节流，然后通过查表的方式来实现字符的编解码。现代操作系统沿用了这种方式。例如Windows使用936代码页、Mac系统使用EUC-CN代码页实现GBK字符集的编码，名字虽然不一样，但对于同一汉字的编码肯定是一样的。

大小端的说法源自《格列佛游记》。我们知道，鸡蛋通常一端大一端小，小人国的人们对于剥蛋壳时应从哪一端开始剥起有着不一样的看法。同样，计算机界对于传输多字节字（由多个字节来共同表示一个数据类型）时，是先传高位字节（大端）还是先传低位字节（小端）也有着不一样的看法，这就是计算机里头大小端模式的由来了。无论是写文件还是网络传输，实际上都是往流设备进行写操作的过程，而且这个写操作是从流的低地址向高地址开始写（这很符合人的习惯），对于多字节字来说，如果先写入高位字节，则称作大端模式。反之则称作小端模式。也就是说，大端模式下，字节序和流设备的地址顺序是相反的，而小端模式则是相同的。一般网络协议都采用大端模式进行传输。

——Kevin Yang

参考链接：

来自：http://www.cnblogs.com/KevinYang/archive/2010/06/18/1760597.html

男人不得不看的十大励志电影

艾榕 — Thu, 27 Oct 2011 16:42:27 +0800

1、《阿甘正传》　课程：执着

每次想起阿甘在美国东西海岸之间的奔跑，心里都会止不住的伤感，还有振奋。

你相信一个智障儿的成功吗？你相信这世上得到最多的人正是那些不计得失的人吗？

阿甘不懂得他不能总跟着一个女人帮她打架，也不懂得一个成年人不该总把***话挂在嘴边。阿甘什么都不知道，他只知道凭着直觉在路上不停地跑，并且最终他跑到了终点。

另外，《阿甘正传》还会教给你一个男人必须具备的一种素质——困境中的幽默感。 2、《东方不败》　课程：才华

男人不应该不看武侠片，如果你只能看一部武侠电影，你会选择什么？我想应该是《东方不败》.满堂花醉三千客，一剑霜寒十四州，剑客的身姿随着剑在空气中的游走而起舞，翩若惊鸿，宛若游龙。金庸的《笑傲江湖》讲的是对自由的追求，徐克、程小东、张叔平、李连杰等一干天才用电影再现了金庸笔下这个瑰丽无比的武侠世界。沧海一声笑的曲子传唱至今，成为我们一个幻想的凭籍，一个逃避现实的出口。

3、《美国往事》　课程：人生

《美国往事》包含了一个男人在这个世界上所能遇到的一切。友情、爱情、幻想、责任、冲突。它更像是一场让人不愿醒来的梦，当面条躺在床上，在温暖的灯　光和的迷离的电话铃声中回到那些逝去了的岁月，这场梦便开始了，直到最后的面条终于露出笑容，我们才回到自己的人生，去继续那些不尽的故事。什么帮派，什么仇杀，原来都不重要，印象中只有一个毛躁的少年，偷看一个美丽女孩儿跳舞；只有一个负罪的兄弟，每天早早地上床睡觉；只有一个白发苍苍的老人，面对背叛了的友谊，语调平和，不动声色。《美国往事》带着你作了一个三小时四十五分钟的梦。人生如梦，这也许是惟一的感受。

4、《罗马假日》　课程：爱情

也许《罗马假日》有点瞎浪漫的嫌疑，但奥黛丽。赫本的出现使它真的成了一部童话。她就像是游历人间的天使，美丽得不染纤尘。记者吻过湿淋淋的公主，然后看着她慢慢地走向自己的官邸。那一刻，你是否会在心里默默地说，“别走”？

在罗马的宫殿里，两个人站得那样近，也离得那样远。乔只能说：“你的朋友绝不会让你失望。”而公主也只能这样回答，“罗马，当然是罗马。”在人的一生里，即便只有这样一刻心灵的相通，也会少却多少遗憾！

5、《勇敢的心》　课程：勇气

也许英雄并不是无所不能的神明，但英雄一定是无所畏惧的勇士。在你站在霓虹闪烁的街头，当你面对卑鄙委琐的笑脸，你又想起了那个让你汗颜的华莱士，这时你收起脸上惯带的笑容，默默地向梅尔。吉布森致敬，从来没有这么庄重。因为他让我们明白，什么才是真正的英雄。“Freedom ！”华莱士临死前的一声呐喊，把你的血也点燃了。

6、《辛德勒的名单》　课程：责任

所谓责任，就是未必做得成却必须去做的事。对于辛德勒来说，救助落难的犹太人是作为一个真正的人的责任。而把那段历史搬上银幕，则是斯皮尔伯格作为一个犹太艺术家的责任。《辛德勒的名单》包含着对受难者的祭奠，对拯救者的敬意，和对光明一定到来的信念。在影片放映后的一片赞誉声中，斯皮尔伯格平静地把影片的全部收益捐给了美国的纳粹大屠杀纪念馆。

7、《肖申克的救赎》　课程：信念

“有一种鸟儿是永远也关不住的，因为它的每片羽翼上都沾满了自由的光辉。”
一个人能够在十五年痛苦的牢狱生活里，不放弃对自由的向往，这是一种怎样的精神力量？所以他成功了，成功夺回了自由。《肖申克的救赎》中有这样一句话：体制化是这样一种东西，一开始你排斥它，后来你习惯它，直到最后你离不开它。想想看，我们的身体已经有多大一部分被体制化了？

8、《E.T》　课程：童心

如果看《E.T》时你流泪了，你不要害怕也不要惭愧，不管你有多大的年纪。实际上，能够和孩子们一起为E.T 的遭遇而悲喜，是一件多么让人庆幸的事，这代表着我们还有一点童心未曾泯灭，代表着我们有一些梦想还藏在心底。当长着一双孩子的眼睛的E.T 用超能力让孩子们的自行车飞上夜空，穿过那轮明月的时候，你是否感到了震憾？是否对自己一些已经习惯了的东西产生了怀疑？

9、《现代启示录》　课程：痛苦

战争是一种秩序的破坏，世界上最可悲最痛苦的事莫过于战争，最痛苦的战争电影莫过于《现代启示录》。《现代启示录》讲的是人性的倒退，秩序的破坏。但文明的进程却没有人能够阻挡。

10、《第七封印》　课程：哲思

我不敢说我看懂了《第七封印》，但如果要我在临死之前看一部电影，我一定选择《第七封印》。

101部欧美经典科幻电影推荐

艾榕 — Thu, 27 Oct 2011 16:34:50 +0800

先记录下来吧，以后我慢慢开始看这些电影的时候会给补充bt下载链接的（也欢迎大家补充下载地址）：

1. Alien (1979) 《异形》
2. Aliens (1986) 《异形续集》
3. Alien 3 (1992) 《异形3》
4. Alien: Resurrection (1997)《异形4:复活》
5. Armageddon (1998)《世界末日/绝世天劫》
6. Battle Beyond the Stars (1980)《世纪争霸战》
7. Black Hole, The (1979) 《黑洞》
8. Contact (1997) 《超时空接触》
9. Chronicles of Riddick, The (2004)《星际传奇2》
10.Deep Impact (1998)《彗星撞地球/天地大冲撞》
11.Dune (1984) 《沙丘》
12. Enemy Mine (1985) 《第五惑星》
13. Event Horizon (1997) 《黑洞表面》
14. Fifth Element, The (1997) 《第五元素》
15.Ghosts of Mars (2001) 《火星幽灵》
16.Independence Day (1996) 《独立日/天煞地球反击战》
17.Last Starfighter, The (1984) 《星空战士》
18. Lifeforce (1985) 《宇宙天魔》
19. Lost in Space (1998) 《星际迷航》
20. Mission to Mars (2000) 《火星任务》
21. Pitch Black (2000) 《星际传奇/漆黑一片》
22. Starship Troopers (1997) 《星河战队》
23. Star Trek: The Motion Picture (1979) 《星舰迷航记》
24. Star Trek II: The Wrath of Khan (1982) 《星际迷航记 2:天汗的愤怒》
25. Star Trek III: The Search for Spock (1983) 《星舰迷航记III》
26. Star Trek IV: The Voyage Home (1986)《星际迷航记 4：抢救未来》
27. Star Trek V: The Final Frontier (1989) 《星舰迷航记5：终极先锋》
28. Star Trek VI: The Undiscovered Country (1991) 《星舰迷航记 6:迈入未来》
29. Star Trek Generations (1994) 《星际迷航7-星空奇兵》
30. Star Trek: First Contact (1996) 《星际旅行：第一类接触》
31. Star Trek: Insurrection (1998) 《星际叛变》
32. Star Trek Nemesis (2002) 《星际迷航记之复仇女神》
33. Star Wars Episode I: The Phantom Menace (1999) 《星战前传之魅影危机》
34. Star Wars Episode II: Attack of the Clones (2002) 《星战前传2：克隆人的进攻》
35. Star Wars Episode III: Revenge of the Sith (2005)《星战前传3：西斯的反击》
36. Star Wars Episode IV: A New Hope (1977)《星球大战IV_新的希望》
37. Star Wars Episode V: The Empire Strikes Back (1980) 《星球大战之帝国反击战》
38. Star Wars Episode VI: Return of the Jedi (1983) 《星球大战VI-绝地大反击》
39. Stargate (1994) 《星际奇兵》
40. Sunshine (2007) 《太阳危机》
41. Superman (1978) 《超人》
42. Supernova (2000) 《超新星/超级外星历险》
43. Titan A.E. (2000, animated) 《冰冻星球》
44. Total Recall (1990) 《宇宙威龙》

选自外形生物科幻电影目录
45. The Abyss (1989)《深渊》
46. Alien Nation (1988)《异形帝国》
47. Alien vs. Predator (2004)《异形大战铁血战士》
48. Aliens vs. Predator: Requiem (2007)《异形大战铁血战士2》
49. The Arrival (1996)《外星人入侵/天袭》
50. Battlefield Earth (2000)《地球战场》
51. Body Snatchers (1993)《异型基地/外星人入侵》
52. Close Encounters of the Third Kind (1977)《第三类接触》
53.Cocoon (1985)《魔茧》
54.Doom (2005)《毁灭战士》
55.Dreamcatcher (2003)《劫梦惊魂/捕梦网/漏网之灵》
56.E.T. the Extra-Terrestrial(1982)《外星人 E.T》
57.Galaxy Quest (1999)《银河访客》
58.H.G. Wells’ War of the Worlds (2005)《世界大战》
59.The Hitchhiker’s Guide to the Galaxy (2005)《银河系漫游指南》
60.Impostor (2002)《强殖入侵》
61.Indiana Jones and the Kingdom of the Crystal Skull (2008)《夺宝奇兵4：水晶头骨》
62. K-PAX (2001)《K星异客》
63.Liquid Sky (1982)《明朗的天空》
64.Lost in Space (1998)《迷失太空》
65.Mac and Me (1988)《新外星人》
66.Mars Attacks! (1996)《星战毁灭者/火星人玩转地球/火星人大侵袭/外星人进攻》
67.Men in Black (1997)《黑超特警组》
68.Men in Black II (2002)《黑超特警组2》
69.Predator (1987)《铁血战士》
70.Predator 2 (1990)《铁血战士2》
71.Signs (2002)《天兆/惊兆/灵异象限》
72.Slither (2006)《撕裂人》
73.Species (1995)《异种》
74.Species II (1998)《异种2》
75.Species III (2004)《异种3》
76.Starman (1984)《外星恋》
77.Superman II (1980)《超人II》
78.Superman III (1983)《超人3》
79.Superman IV: The Quest for Peace (1987)《超人第4集：决战核能人》
80. Superman Returns (2006)《超人归来/超人再起》
81.The Forgotten (2004)《灵异拼图》
82.Transformers (2007)《《变形金刚》》
83.Treasure Planet (2002)《星银岛》
84.Virus (1999)《病毒/异形总动员/天魔驱人》
85.WALL-E (2008)《机器人总动员》
86.The War of the Worlds (1953) 《外星人大战地球》
87.The X Files (1998)《X档案征服未来》

还有几部有外星生物(或非生物)的
88. Flight of the Navigator (1986)《飞碟领航员》
89. batteries not included (1987)《鬼使神差》
90. Lilo & Stitch (2002)《星际宝贝》
91. Evolution (2001)《进化》

剩下的和外星人、外星球没什么关系，不过是尚算好看的科幻片。
92. The Matrix (1999)《黑客帝国/骇客帝国》
93. The Matrix Reloaded (2003)《黑客帝国2：重装上阵》
94. The Matrix Revolutions (2003)《矩阵革命/黑客帝国3：最后战役/》
95. The Terminator (1984)《终结者》
96. Terminator 2: Judgment Day (1991) 《终结者2/魔鬼终结者2/未来战士2》
97. Terminator 3: Rise of the Machines (2003) 《终结者3/终结者Ⅲ：机器的兴起》
98. The Thirteenth Floor (1999)《异次元骇客》
99.Innerspace (1987)《惊异大奇航》
100. Short Circuit (1986) 《霹雳五号》
101.Aeon Flux (2003)《魔力女战士》

更换到 Forigi 主题

艾榕 — Thu, 27 Oct 2011 16:26:02 +0800

在WPchina上看到了这款主题，一下子就喜欢上了它，内容很丰富，定制性很高，对于一个特别喜欢的尝鲜而又喜欢高度可定制性的我来说，forigi 满足了我在wordpress主题上追求，我可以随心所欲的定制侧边栏要显示什么，更重要的是：像最新文章，评论之类的，都是已经直接集成在主题内了，无需再手动拖到“小工具”上，小工具上我就可以定制我真正想要的东西了。

对于广告的集成也很丰富，预留的几个广告位也很能吸引人的眼球，我以前不想再blog上放置广告啥的，一来是我的blog访问量少的可怜，根本也不可能产生啥效益；另外我也不指望这个能给我带来收益。不过换了这个主题后，我还真想不出来那几个广告位可以放点什么，所以索性还是弄个Google Adsense放上吧，这个不知道算是forigi的优点呢还是缺点呢？仁者见仁，智者见智吧；你需要的我可能不需要，我不需要的你可能需要，想要完全满足自己的要求，免费的完全公开的主题应该满足不了每一个人。

曾经我已经要求自己不要再在折腾主题上花费什么功夫了，所以就弄了个最简单的主题换上了，但是看到这个主题，再折腾一把的欲望又占了上风，折腾就折腾吧，人不折腾枉少年！哦，不！实际上我已经过了少年时代了。

就像玩弄智能手机一样，买回来就像装上一大堆的软件尝鲜，然后用着不爽的就卸载，用着爽的也不知道多长时间才能用上一次，总之就是有了比没有好，我想我花在玩弄网站和计算机上激情和时间应该不亚于那些玩机狂吧。

forigi的功能列表可以自己去秦唐网查看，我就不罗嗦了，在试用过程中发现一个bug：如果在主题的设置里面贴进去了自己的微博秀的代码，那么必须在“小工具”里面把“我的微博秀”这个小工具给添加到Sidebar上，不然就会出现一些异常的Warnning信息。

少壮不努力，一生在内地

艾榕 — Mon, 19 Sep 2011 17:45:53 +0800

少壮不努力，一生在内地!

对中国人性的最好评价！

艾榕 — Mon, 19 Sep 2011 17:38:43 +0800

“一个连自由平等都得不到的民族却总想着要回钓鱼岛，想着复兴，想着国耻。”我觉得这是对中国人性的最好评价！

逼上梁山

艾榕 — Thu, 08 Sep 2011 16:22:22 +0800

“杀人者，安道全是也”都是被自己人逼上梁山的；看了很多集的新水浒了，感觉那个时候想陷害个人还得用什么计谋啥的，现在想杀个人“躲猫猫”，“喝水”就可以了；看起来宋朝末年还是挺法制的，不知道所谓的好汉造的什么反

您可能也喜欢：
How to use Sql Azure	暴寒的一位父亲对孩子的现场灭日教育!!!	今日嘀咕(2009.12.27-12.28)	人来人往	10.4，准备结婚了
无觅

您可能也喜欢：
深入理解.NET内存回收机制	关于字符编码，你所需要知道的	ADO.NET Transaction的隔离级别解析	在.NET项目中使用log4net	我也可以做出这么完美的设计
来自无觅网络的相关文章：
安徽电气工程职业技术学院2011年运动会百米决赛。黑色4号；起跑太销魂了 (@letaoba)	技术文，绝对是牛叉的技术文！把妹高手谈如何跟刚搭讪认识的妹子发短信 (@letaoba)	顽固的基因：一个技术型创业团队的理想与现实 (@fuozu)	FANCL 店设计 (@ycy8)	[技术贴]看乳沟怎么算胸围。乃可以好好学的！ (@letaoba)
无觅

您可能也喜欢：
CLR如何创建运行时对象的	关于字符编码，你所需要知道的	ADO.NET Transaction的隔离级别解析	在.NET项目中使用log4net	如何制作网页能够尽量保证各种浏览器的兼容性
来自无觅网络的相关文章：
安徽电气工程职业技术学院2011年运动会百米决赛。黑色4号；起跑太销魂了 (@letaoba)	John Ryland概念摩托车设计 (@ycy8)	技术文，绝对是牛叉的技术文！把妹高手谈如何跟刚搭讪认识的妹子发短信 (@letaoba)	RSS 订阅地址改为 feed.surdark.net (@surdark)	顽固的基因：一个技术型创业团队的理想与现实 (@fuozu)
无觅

您可能也喜欢：
深入理解.NET内存回收机制	CLR如何创建运行时对象的	ADO.NET Transaction的隔离级别解析	在.NET项目中使用log4net	如何制作网页能够尽量保证各种浏览器的兼容性
来自无觅网络的相关文章：
John Ryland概念摩托车设计 (@ycy8)	令人难以置信的技术，创意平衡木 (@xepark)	FANCL 店设计 (@ycy8)	买保险是对冲技术在生活中的重要应用 (@tlmm123)	宝马创新的眼光ConnectedDrive (@ycy8)
无觅

您可能也喜欢：
101部欧美经典科幻电影推荐	生活需要一定的规则	科目三考试顺利通过	[搞笑] 恶搞包青天之再审采花贼	看相声剧有感
来自无觅网络的相关文章：
劲爆的搞笑gif动图（9p） (@hnbang)	搞笑gif动图（9p） (@hnbang)	很搞笑，两只袋鼠打架~ (@hnbang)	周末更有搞笑动图（8p） (@hnbang)	笑到吐的gif（9p） (@hnbang)
无觅

您可能也喜欢：
男人不得不看的十大励志电影	超级搞笑：世界上最惨的人	[搞笑] 恶搞包青天之再审采花贼	超级搞笑: 世界上最倒霉的一跳	生活中随处可见的雷人图片
来自无觅网络的相关文章：
192部经典电影完美画面剪接 (@letaoba)	周末更有搞笑动图（8p） (@hnbang)	搞笑gif送别周末（9p） (@hnbang)	中国电影的英文译名，翻译太TMD有才了！ (@letaoba)	很搞笑，两只袋鼠打架~ (@hnbang)
无觅

您可能也喜欢：
让IE 6,7,8支持部分的CSS3属性	解决IE6下的png图片透明问题	烦人的IE6	关于字符编码，你所需要知道的	整合BuddyPress到WordPress博客
无觅

您可能也喜欢：
穷男人一生的写照	一句让老婆感动一生的脏话……….	人的一生最后悔什么	[The Winter]冬之物语	开心一天
来自无觅网络的相关文章：
我叫奶茶-记录奶茶的一生 (@xepark)	7个习惯改变一生 (@fuozu)	五句话改变你一生的财运 (@fuozu)	彼尔盖茨的十句话,绝对让你改变一生 (@fuozu)	可口可乐分：该批零度可乐原液本来是给中国内地用的，不慎运到台湾 (@hnbang)
无觅

您可能也喜欢：
生活不容易但仍要开心生活	生活日记	生活中随处可见的雷人图片	生活与成长	生活的乐趣
无觅

您可能也喜欢：
设计模式新解	人的一生最后悔什么	媒体总结09年官员雷人语录	101部欧美经典科幻电影推荐	2009年之最
来自无觅网络的相关文章：
恶搞《新水浒传》，军师，吓到贫道了~~ (@hnbang)	恶搞《新水浒传》的片段 (@hnbang)	《新水浒传》的武松被杰克船长上身 (@hnbang)	《新水浒传》潘金莲（甘婷婷）和西门庆（杜淳）被删激情戏份曝光 (@hnbang)	让口水飞！潘金莲吃火锅中毒死真相 (@ohidea)
无觅