欢迎使用CSDN-markdown编辑器

最新推荐文章于 2021-04-26 21:22:11 发布

奔跑的艾斯

最新推荐文章于 2021-04-26 21:22:11 发布

阅读量241

点赞数

分类专栏： c# 文章标签： c#-堆栈

c# 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

值类型和引用类型的内存分配：

值类型变量与引用类型变量的内存分配模型不一样。

为了理解清楚这个问题，读者首先必须区分两种不同类型的内存区域：线程堆栈（Thread Stack）和托管堆（Managed Heap）。

每个正在运行的程序都对应着一个进程（process），在一个进程内部，可以有一个或多线程（thread），每个线程都拥有块“自留地”，称为“线程堆栈”，大小为1M，用于保存自身的一些数据，比如函数中定义的局部变量、函数调用时传送的参数值等，这部分内存区域的分配与回收不需要程序员干涉。

所有值类型的变量都是在线程堆栈中分配的。另一块内存区域称为“堆（heap）”，在.NET 这种托管环境下，堆由CLR 进行管理，所以又称为“托管堆（managed heap）”。用new 关键字创建的类的对象时，分配给对象的内存单元就位于托管堆中。

在程序中我们可以随意地使用new 关键字创建多个对象，因此，托管堆中的内存资源是可以动态申请并使用的，当然用完了必须归还。打个比方更易理解：托管堆相当于一个旅馆，其中的房间相当于托管堆中所拥有的内存单元。

当程序员用new 方法创建对象时，相当于游客向旅馆预订房间，旅馆管理员会先看一下有没有合适的空房间，有的话，就可以将此房间提供给游客住宿。当游客旅途结束，要办理退房手续，房间又可以为其他旅客提供服务了。

引用类型共有四种：类类型、接口类型、数组类型和委托类型。

所有引用类型变量所引用的对象，其内存都是在托管堆中分配的。

严格地说，我们常说的“对象变量”其实是类类型的引用变量。但在实际中人们经常将

引用类型的变量简称为“对象变量”，用它来指代所有四种类型的引用变量。

堆栈和托管堆：

内存格局通常分为四个区

全局数据区：存放全局变量，静态数据，常量

代码区：存放所有的程序代码

栈区：存放为运行而分配的局部变量，参数，返回数据，返回地址等，

堆区：即自由存储区

堆栈和堆（托管堆）都在进程的虚拟内存中。（在32位处理器上每个进程的虚拟内存为4GB）

堆栈stack

堆栈中存储值类型。

堆栈实际上是向下填充，即由高内存地址指向低内存地址填充。

堆栈的工作方式是先分配内存的变量后释放（先进后出原则）。

堆栈中的变量是从下向上释放，这样就保证了堆栈中先进后出的规则不与变量的生命周期起冲突！

堆栈的性能非常高，但是对于所有的变量来说还不太灵活，而且变量的生命周期必须嵌套。

通常我们希望使用一种方法分配内存来存储数据，并且方法退出后很长一段时间内数据仍然可以使用。此时就要用到堆（托管堆）！

堆（托管堆）heap

堆（托管堆）存储引用类型。

此堆非彼堆，.NET中的堆由垃圾收集器自动管理。

与堆栈不同，堆是从下往上分配，所以自由的空间都在已用空间的上面。

比如创建一个对象：

[csharp] view plain copy

print ?

Student stu;
stu = new Student();

<span style="font-family:Arial Black;">Student stu;
stu = new Student();</span>

申明一个Student的引用cus，在堆栈上给这个引用分配存储空间。这仅仅只是一个引用，不是实际的Student对象！

stu占4个字节的空间，包含了存储Student的引用地址。
接着分配堆上的内存以存储Student对象的实例，假定Student对象的实例是32字节，为了在堆上找到一个存储Student对象的存储位置。

.NET运行库在堆中搜索第一个从未使用的，32字节的连续块存储Student对象的实例！

然后把分配给Student对象实例的地址赋给stu变量！

从这个例子中可以看出，建立对象引用的过程比建立值变量的过程复杂，且不能避免性能的降低！

实际上就是.NET运行库保存对的状态信息，在堆中添加新数据时，堆栈中的引用变量也要更新。性能上损失很多！

有种机制在分配变量内存的时候，不会受到堆栈的限制：把一个引用变量的值赋给一个相同类型的变量，那么这两个变量就引用同一个堆中的对象。

当一个应用变量出作用域时，它会从堆栈中删除。但引用对象的数据仍然保留在堆中，一直到程序结束或者该数据不被任何变量应用时，垃圾收集器会删除它。

栈是内存中完全用于存储局部变量或成员字段（值类型数据）的高效的区域，但其大小有限制。

托管堆所占内存比栈大得多，当访问速度较慢。托管堆只用于分配内存，一般由CLR（Common Language Runtime）来处理内存释放问题。

当创建值类型数据时，在栈上分配内存；

当创建引用型数据时，在托管堆上分配内存并返回对象的引用。注意这个对象的引用，像其他局部变量一样也是保存在栈中的。该引用指向的值则位于托管堆中。

如果创建了一个包含值类型的引用类型，比如数组，其元素的值也是存放在托管堆中而非栈中的。当从数组中检索数据时，获得本地使用的元素值的副本，而该副本这时候就是存放在栈中的了。所以，不能笼统的说“值类型保存在栈中，引用类型保存在托管堆中”。

值类型和引用类型的区别：引用类型存储在托管堆的唯一位置中，其存在于托管堆中某个地方，由使用该实体的变量引用；而值类型存储在使用它们的地方，有几处在使用，就有几个副本存在。

对于引用类型，如果在声明变量的时候没有使用new运算符，运行时就不会给它分配托管堆上的内存空间，而是在栈上给它分配一个包含null值的引用。对于值类型，运行时会给它分配栈上的空间，并调用默认的构造函数，来初始化对象的状态。

托管堆优化：

　　看上去似乎很简单，但是垃圾收集器实际采用的步骤和堆管理系统的其他部分并非微不足道，其中常常涉及为提高性能而作的优化设计。举例来说，垃圾收集遍历整个内存池具有很高的开销。然而，研究表明大部分在托管堆上分配的对象只有很短的生存期，因此堆被分成三个段，称作generations。新分配的对象被放在generation 0中。这个generation是最先被回收的——在这个generation中最有可能找到不再使用的内存，由于它的尺寸很小（小到足以放进处理器的L2 cache中），因此在它里面的回收将是最快和最高效的。
　　托管堆的另外一种优化操作与locality of reference规则有关。该规则表明，一起分配的对象经常被一起使用。如果对象们在堆中位置很紧凑的话，高速缓存的性能将会得到提高。由于托管堆的天性，对象们总是被分配在连续的地址上，托管堆总是保持紧凑，结果使得对象们始终彼此靠近，永远不会分得很远。这一点与标准堆提供的非托管代码形成了鲜明的对比，在标准堆中，堆很容易变成碎片，而且一起分配的对象经常分得很远。
　　还有一种优化是与大对象有关的。通常，大对象具有很长的生存期。当一个大对象在.NET托管堆中产生时，它被分配在堆的一个特殊部分中，这部分堆永远不会被整理。因为移动大对象所带来的开销超过了整理这部分堆所能提高的性能。
　　关于外部资源（External Resources）的问题
　　垃圾收集器能够有效地管理从托管堆中释放的资源，但是资源回收操作只有在内存紧张而触发一个回收动作时才执行。那么，类是怎样来管理像数据库连接或者窗口句柄这样有限的资源的呢？等待，直到垃圾回收被触发之后再清理数据库连接或者文件句柄并不是一个好方法，这会严重降低系统的性能。
　　所有拥有外部资源的类，在这些资源已经不再用到的时候，都应当执行Close或者Dispose方法。从Beta2（译注：本文中所有的Beta2均是指.NET Framework Beta2，不再特别注明）开始，Dispose模式通过IDisposable接口来实现。这将在本文的后续部分讨论。
　　需要清理外部资源的类还应当实现一个终止操作（finalizer）。在C#中，创建终止操作的首选方式是在析构函数中实现，而在Framework层，终止操作的实现则是通过重载System.Object.Finalize 方法。以下两种实现终止操作的方法是等效的：
　　

[csharp] view plain copy

print ?

~OverdueBookLocator()
　　{
　　 Dispose(false);
　　}
　　和：
　　public void Finalize()
　　{
　　 base.Finalize();
　　 Dispose(false);
}

<span style="font-family:Arial Black;">~OverdueBookLocator()
　　{
　　 Dispose(false);
　　}
　　和：
　　public void Finalize()
　　{
　　 base.Finalize();
　　 Dispose(false);
　　}</span>

　　在C#中，同时在Finalize方法和析构函数实现终止操作将会导致错误的产生。
　　除非你有足够的理由，否则你不应该创建析构函数或者Finalize方法。终止操作会降低系统的性能，并且增加执行期的内存开销。同时，由于终止操作被执行的方式，你并不能保证何时一个终止操作会被执行。
　　内存分配和垃圾回收的细节
　　对GC有了一个总体印象之后，让我们来讨论关于托管堆中的分配与回收工作的细节。托管堆看起来与我们已经熟悉的C++编程中的传统的堆一点都不像。在传统的堆中，数据结构习惯于使用大块的空闲内存。在其中查找特定大小的内存块是一件很耗时的工作，尤其是当内存中充满碎片的时候。与此不同，在托管堆中，内存被组制成连续的数组，指针总是巡着已经被使用的内存和未被使用的内存之间的边界移动。当内存被分配的时候，指针只是简单地递增——由此而来的一个好处是，分配操作的效率得到了很大的提升。
　　当对象被分配的时候，它们一开始被放在generation 0中。当generation 0的大小快要达到它的上限的时候，一个只在generation 0中执行的回收操作被触发。由于generation 0的大小很小，因此这将是一个非常快的GC过程。这个GC过程的结果是将generation 0彻底的刷新了一遍。不再使用的对象被释放，确实正被使用的对象被整理并移入generation 1中。
　　当generation 1的大小随着从generation 0中移入的对象数量的增加而接近它的上限的时候，一个回收动作被触发来在generation 0和generation 1中执行GC过程。如同在generation 0中一样，不再使用的对象被释放，正在被使用的对象被整理并移入下一个generation中。大部分GC过程的主要目标是generation 0，因为在generation 0中最有可能存在大量的已不再使用的临时对象。对generation 2的回收过程具有很高的开销，并且此过程只有在generation 0和generation 1的GC过程不能释放足够的内存时才会被触发。如果对generation 2的GC过程仍然不能释放足够的内存，那么系统就会抛出OutOfMemoryException异常
　　带有终止操作的对象的垃圾收集过程要稍微复杂一些。当一个带有终止操作的对象被标记为垃圾时，它并不会被立即释放。相反，它会被放置在一个终止队列（finalization queue）中，此队列为这个对象建立一个引用，来避免这个对象被回收。后台线程为队列中的每个对象执行它们各自的终止操作，并且将已经执行过终止操作的对象从终止队列中删除。只有那些已经执行过终止操作的对象才会在下一次垃圾回收过程中被从内存中删除。这样做的一个后果是，等待被终止的对象有可能在它被清除之前，被移入更高一级的generation中，从而增加它被清除的延迟时间。
　　需要执行终止操作的对象应当实现IDisposable接口，以便客户程序通过此接口快速执行终止动作。IDisposable接口包含一个方法——Dispose。这个被Beta2引入的接口，采用一种在Beta2之前就已经被广泛使用的模式实现。从本质上讲，一个需要终止操作的对象暴露出Dispose方法。这个方法被用来释放外部资源并抑制终止操作，就象下面这个程序片断所演示的那样：
　

[csharp] view plain copy

print ?

public class OverdueBookLocator: IDisposable
　　{
　　 ~OverdueBookLocator()
　　 {
　　 InternalDispose(false);
　　 }
　　 public void Dispose()
　　 {
　　 InternalDispose(true);
　　 }
　　 protected void InternalDispose(bool disposing)
　　 {
　　 if(disposing)
　　 {
　　 GC.SuppressFinalize(this);
　　 // Dispose of managed objects if disposing.
　　 }
　　 // free external resources here
　　 }
}

<span style="font-family:Arial Black;">　public class OverdueBookLocator: IDisposable
　　{
　　 ~OverdueBookLocator()
　　 {
　　 InternalDispose(false);
　　 }
　　 public void Dispose()
　　 {
　　 InternalDispose(true);
　　 }
　　 protected void InternalDispose(bool disposing)
　　 {
　　 if(disposing)
　　 {
　　 GC.SuppressFinalize(this);
　　 // Dispose of managed objects if disposing.
　　 }
　　 // free external resources here
　　 }
　　} </span>

这些都是.NET中CLR的概念，和C#没多大关系。
使用基于CLR的语言编译器开发的代码称为托管代码。
托管堆是CLR中自动内存管理的基础。初始化新进程时，运行时会为进程保留一个连续的地址空间区域。这个保留的地址空间被称为托管堆。托管堆维护着一个指针，用它指向将在堆中分配的下一个对象的地址。最初，该指针设置为指向托管堆的基址。
认真看MSDN Library，就会搞清楚这些概念。

以下代码说明的很形象：

[csharp] view plain copy

print ?

//引用类型(‘class’ 类类型)
class SomeRef { public int32 x;}
//值类型(‘struct’)
struct SomeVal(pulic Int32 x;}
static void ValueTypeDemo()
{
SomeRef r1=new SomeRef();//分配在托管堆
SomeVal v1=new SomeVal();//堆栈上
r1.x=5;//解析指针
v1.x=5;//在堆栈上修改
SomeRef r2=r1;//仅拷贝引用(指针)
SomeVal v2=v1;//先在堆栈上分配,然后拷贝成员
r1.x=8;//改变了r1,r2的值
v1.x=9;//改变了v1,没有改变v2
}

<span style="font-family:Arial Black;"><span style="font-family:Arial Black;">//引用类型('class' 类类型) 
class SomeRef { public int32 x;}

//值类型('struct') 
struct SomeVal(pulic Int32 x;}
static void ValueTypeDemo() 
{ 
  SomeRef r1=new SomeRef();//分配在托管堆 
  SomeVal v1=new SomeVal();//堆栈上 
  r1.x=5;//解析指针 
  v1.x=5;//在堆栈上修改
  SomeRef r2=r1;//仅拷贝引用(指针) 
  SomeVal v2=v1;//先在堆栈上分配,然后拷贝成员
  r1.x=8;//改变了r1,r2的值 
  v1.x=9;//改变了v1,没有改变v2 
} </span></span>

垃圾回收机制：

首先声明一点所谓垃圾回收，回收的是分配在托管堆上的内存，对于托管堆外的内存，它无能为力。

讨论垃圾回收机制就不得不提内存的分配，在C运行时堆（C-runtime heap)中，堆是不连续的，我们new一个新的对象时，系统会检查内存，找一块足够大的内存然后初始化对象，对象被销毁后，这块空间会用于初始化新的对象。这样做有什么弊端？随着程序运行一直有对象生成释放，内存会变得碎片化，这样有新的大的对象要生成时就必须扩展堆的长度，碎片内存无法得到充分利用，还有一个弊端是每次创建一个对象时都要检查堆内存，效率不高。而C#托管堆采取连续内存存储，新创建对象时只要考虑剩下的堆内存是否足够大就成，但一直生成对象而不析构会使托管堆无限增大，怎么维护这样一块连续内存呢？这也就引出了垃圾回收机制。托管堆的大小是特定的，垃圾收集器GC负责当内存不够的时候释放掉垃圾对象，copy仍在使用的对象成一块连续内存。而这就带来了性能问题，当对象很大的时候，频繁的copy移动对象会降低性能，所以C#的垃圾收集引入了世代和大对象堆小对象堆的概念。

所谓大对象堆小对象堆从字面意义就能看出其作用，大对象堆主要负责分配大的对象，小对象堆分配小的。但对象大小怎么确定呢？在.NET Framework中规定，如果对象大于或等于 85,000 字节，将被视为大型对象。当对象分配请求传入后，如果符合该大小阈值，便会将此对象分配给大型对象堆。这个85000字节是根据性能优化的结果确定。值得注意的是垃圾回收对大对象堆和小对象堆都起作用。那么分大对象和小对象堆作用是什么呢？还是性能，对于大对象和小对象区别对待采取不同灵活的垃圾回收策略必定比一棍子打死死板的采用同一种策略要好。下面我们讨论一下在SOH(大型对象堆)和LOH(小型对象堆)不同的垃圾收集策略：

先说一下世代，之所以分世代，是因为在第0代就能清除大部分对象。请注意，世代是个逻辑上的概念，物理上并没有世代这个数据结构。以小对象堆垃圾回收为例：当一个对象被创建的时候，它被定义为第0代对象，而经历一次垃圾收集后还存余的对象就被归入了第1代对象，同理经过两次或者两次以上仍然存在的对象就可以看成第2代对象。虽然世代只是逻辑概念，但它却是有大小的，对于SOH对象来说，由于每次垃圾回收都会压缩移动对象，所以世代数越大越在堆底。经历一次垃圾回收，对象都会被移入下一个世代的内存空间中（下图以小对象堆上垃圾回收为例。对象W至少经过两次垃圾回收而不死，所以放入世代2，X经历了一次垃圾回收）。而每次一个世代内存达到其阙值，都会引发垃圾收集器回收一次。这么做的好处就是每次垃圾回收器只是回收一个世代的内存，从整体上来看，减少了对象复制移动的次数。

以上讨论都是针对于SOH，对于SOH对象来说复制移动较之LOH成本性能要小一点，那么对于LOH呢？复制一个LOH的对象并且清除原来内存位置的字节，成本相当大，怎么确保它的垃圾回收呢？首先从物理上来说，LOH在托管堆的堆底，SOH在其上，逻辑上讲LOH对象都分配在第二世代，也就是说前边第0代和第1代的垃圾收集回收的都是第OH对象，这也就解释了为什么前两个世代垃圾回收中允许复制移动对象。但对于第二世代垃圾回收呢？第二代垃圾回收之后的对象仍是第二世代，其回收时并不移动仍在使用的对象，压缩空间，而只是清除垃圾对象。当一个新LOH对象创建时，它会从堆底遍历寻找LOH中能够满足要求的内存，如果没有接着向堆顶创建（这个过程和C运行时工作原理一样，所以也存在相同的弊端，LOH堆内存有可能存在碎片）。此时如果堆顶已经超出阙值，引发垃圾回收器回收内存空间。

从上边讨论中我们可以总结一下：我们new出一对象时它要么小对象会被放入第0代，大对象会被分在LOH中，只有垃圾回收器才能够在第1代和第2代中“分配”对象，这里所说分配对象是指移动复制对象。