C#.Net对象内存模型及堆/栈数据结构详解 (三)
C#.Net对象内存模型及堆/栈数据结构详解 (三)
C# Heap(ing) Vs Stack(ing) in .NET: Part III Even though with the .NET framework we don''t have to actively worry about memory management and garbage collection (GC), we still have to keep memory management and GC in mind in order to optimize the performance of our applications. Also, having a basic understanding of how memory management works will help explain the behavior of the variables we work with in every program we write. In this article we''ll cover an issue that arises from having reference variables in the heap and how to fix it using ICloneable. A Copy Is Not A Copy. To clearly define the problem, let''s examine what happens when there is a value type on the heap versus having a reference type on the heap. First we''ll look at the value type. Take the following class and struct. We have a Dude class which contains a Name element and two Shoe(s). We have a CopyDude() method to make it easier to make new Dudes. public struct Shoe{ public string Color; } public class Dude { public string Name; public Shoe RightShoe; public Shoe LeftShoe; public Dude CopyDude() { Dude newPerson = new Dude(); newPerson.Name = Name; newPerson.LeftShoe = LeftShoe; newPerson.RightShoe = RightShoe; return newPerson; } public override string ToString() { return (Name + " : Dude!, I have a " + RightShoe.Color + " shoe on my right foot, and a " + LeftShoe.Color + " on my left foot."); } } Our Dude class is a variable type and because the Shoe struct is a member element of the class they both end up on the heap.
When we run the following method: public static void Main() { Class1 pgm = new Class1(); Dude Bill = new Dude(); Bill.Name = "Bill"; Bill.LeftShoe = new Shoe(); Bill.RightShoe = new Shoe(); Bill.LeftShoe.Color = Bill.RightShoe.Color = "Blue"; Dude Ted = Bill.CopyDude(); Ted.Name = "Ted"; Ted.LeftShoe.Color = Ted.RightShoe.Color = "Red"; Console.WriteLine(Bill.ToString()); Console.WriteLine(Ted.ToString()); } We get the expected output: Bill : Dude!, I have a Blue shoe on my right foot, and a Blue on my left foot. What happens if we make the Shoe a reference type? Herein lies the problem. If we change the Shoe to a reference type as follows: public class Shoe{ public string Color; } and run the exact same code in Main(), look how our input changes: Bill : Dude!, I have a Red shoe on my right foot, and a Red on my left foot The Red shoe is on the other foot. This is clearly an error. Do you see why it''s happening? Here''s what we end up with in the heap.
Because we now are using Shoe as a reference type instead of a value type and when the contents of a reference type are copied only the pointer is copied (not the actual object being pointed to), we have to do some extra work to make our Shoe reference type behave more like a value type. Luckily, we have an interface that will help us out: ICloneable. This interface is basically a contract that all Dudes will agree to and defines how a reference type is duplicated in order to avoid our "shoe sharing" error. All of our classes that need to be "cloned" should use the ICloneable interface, including the Shoe class. ICloneable consists of one method: Clone() public object Clone() { } Here''s how we''ll implement it in the Shoe class: public class Shoe : ICloneable { public string Color; #region ICloneable Members public object Clone() { Shoe newShoe = new Shoe(); newShoe.Color = Color.Clone() as string; return newShoe; } #endregion } Inside the Cone() method, we just make a new Shoe, clone all the reference types and copy all the value types and return the new object. You probably noticed that the string class already implements ICloneable so we can call Color.Clone(). Because Clone() returns a reference to an object, we have to "retype" the reference before we can set the Color of the shoe. Next, in our CopyDude() method we need to clone the shoes instead of copying them public Dude CopyDude() { Dude newPerson = new Dude(); newPerson.Name = Name; newPerson.LeftShoe = LeftShoe.Clone() as Shoe; newPerson.RightShoe = RightShoe.Clone() as Shoe; return newPerson; } Now, when we run main: public static void Main() { Class1 pgm = new Class1(); Dude Bill = new Dude(); Bill.Name = "Bill"; Bill.LeftShoe = new Shoe(); Bill.RightShoe = new Shoe(); Bill.LeftShoe.Color = Bill.RightShoe.Color = "Blue"; Dude Ted = Bill.CopyDude(); Ted.Name = "Ted"; Ted.LeftShoe.Color = Ted.RightShoe.Color = "Red"; Console.WriteLine(Bill.ToString()); Console.WriteLine(Ted.ToString()); } We get: Bill : Dude!, I have a Blue shoe on my right foot, and a Blue on my left foot Which is what we want.
Wrapping Things Up. So as a general practice, we want to always clone reference types and copy value types. (It will reduce the amount of aspirin you will have to purchase to manage the headaches you get debugging these kinds of errors.) So in the spirit of headache reduction, let''s take it one step further and clean up the Dude class to implement ICloneable instead of using the CopyDude() method. public class Dude: ICloneable { public string Name; public Shoe RightShoe; public Shoe LeftShoe; public override string ToString() { return (Name + " : Dude!, I have a " + RightShoe.Color + " shoe on my right foot, and a " + LeftShoe.Color + " on my left foot."); } #region ICloneable Members public object Clone() { Dude newPerson = new Dude(); newPerson.Name = Name.Clone() as string; newPerson.LeftShoe = LeftShoe.Clone() as Shoe; newPerson.RightShoe = RightShoe.Clone() as Shoe; return newPerson; } #endregion } And we''ll change the Main() method to use Dude.Clone() public static void Main() { Class1 pgm = new Class1(); Dude Bill = new Dude(); Bill.Name = "Bill"; Bill.LeftShoe = new Shoe(); Bill.RightShoe = new Shoe(); Bill.LeftShoe.Color = Bill.RightShoe.Color = "Blue"; Dude Ted = Bill.Clone() as Dude; Ted.Name = "Ted"; Ted.LeftShoe.Color = Ted.RightShoe.Color = "Red"; Console.WriteLine(Bill.ToString()); Console.WriteLine(Ted.ToString()); } And our final output is: Bill : Dude!, I have a Blue shoe on my right foot, and a Blue on my left foot. So all is well. Something interesting to note is that the assignment operator (the "=" sign) for the System.String class actually clones the string so you don''t have to worry about duplicate references. However you do have to watch our for memory bloating. If you look back at the diagrams, because the string is a reference type it really should be a pointer to another object in the heap, but for simplicity''s sake, it''s shown as a value type. In Conclusion. As a general practice, if we plan on ever copying of our objects, we should implement (and use) ICloneable. This enables our reference types to somewhat mimic the behavior of a value type. As you can see, it is very important to keep track of what type of variable we are dealing with because of differences in how the memory is allocated for value types and reference types. In the next article, we''ll look at a way to reduce our code "footprint" in memory. 本文来源:
参考文档:
将SQLServer数据类型转换为C#.Net类型 Delphi程序调用C#.Net编译的DLL并打开窗体(详解) C#.Net C/S结构开发框架中数据访问层(DAL)的作用 C#.Net 静态构造器使用详解 C#.Net对象内存模型及堆/栈数据结构详解 (一) C#.Net对象内存模型及堆/栈数据结构详解 (二) C#.Net对象内存模型及堆/栈数据结构详解 (四) C#.Net COM交操作性 - 强类型RCW和弱类型CCW详解 标签:C#.Net组件开发 - 自定义设计器持久化对象的属性 C#.NET C/S结构版本自动升级解决方案2.0详解 (一) C#.NET C/S结构版本自动升级解决方案之升级策略 C# ASP.NET WebApi服务器搭建详解 - IIS服务承载(IIS Hosting IIS宿主) C#数据转换类ConvertEx,封装.Net的Convert对象 CSFramework代码生成器根据数据库表结构生成实体对象模型(C#代码) C# FastReport.NET批量打印条形码报表详解教程
其它资料:
什么是C/S结构? | C/S框架核心组成部分 | C/S框架-WebService部署图 | C/S框架-权限管理 | C/S结构系统框架 - 5.1旗舰版介绍 | C/S结构系统框架 - 功能介绍 | C/S结构系统框架 - 产品列表 | C/S结构系统框架 - 应用展示(图) | 三层体系架构详解 | C/S架构轻量级快速开发框架 | C/S框架网客户案例 | WebApi快速开发框架 | C/S框架代码生成器 | 用户授权注册软件系统 | 版本自动升级软件 | 数据库底层应用框架 | CSFramework.CMS内容管理系统 | |