C#.Net对象内存模型及堆/栈数据结构详解 (四)
C#.Net对象内存模型及堆/栈数据结构详解 (四)
C# Heap(ing) Vs Stack(ing) in .NET: Part IV 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 look into Garbage Collection (GC) and some ways to keep our applications running efficiently. Graphing Let''s look at this from the GC''s point of view. If we are responsible for "taking out the trash" we need a plan to do this effectively. Obviously, we need to determine what is garbage and what is not (this might be a bit painful for the pack-rats out there). In order to determine what needs to be kept, we''ll first make the assumption that everything not being used is trash (those piles of old papers in the corner, the box of junk in the attic, everything in the closets, etc.) Imagine we live with our two good friends: Joseph Ivan Thomas (JIT) and Cindy Lorraine Richmond (CLR). Joe and Cindy keep track of what they are using and give us a list of things they need to keep. We''ll call the initial list our "root" list because we are using it as a starting point. We''ll be keeping a master list to graph where everything is in the house that we want to keep. Anything that is needed to make things on our list work will be added to the graph (if we''re keeping the TV we don''t throw out the remote control for the TV, so it will be added to the list. If we''re keeping the computer the keyboard and monitor will be added to the "keep" list). This is how the GC determines what to keep as well. It receives a list of "root" object references to keep from just-in-time (JIT) compiler and common language runtime (CLR) (Remember Joe and Claire?) and then recursively searches object references to build a graph of what should be kept. Roots consist of:
In the above diagram, objects 1, 3, and 5 in our managed heap are referenced from a root 1 and 5 are directly referenced and 3 is found during the recursive search. If we go back to our analogy and object 1 is our television, object 3 could be our remote control. After all objects are graphed we are ready to move on to the next step, compacting. Compacting Now that we have graphed what objects we will keep, we can just move the "keeper objects" around to pack things up. Fortunately, in our house we don''t need to clean out the space before we put something else there. Since Object 2 is not needed, as the GC we''ll move Object 3 down and fix the pointer in Object 1. Next, as the GC, we''ll copy Object 5 down Now that everything is cleaned up we just need to write a sticky note and put it on the top of our compacted heap to let Claire know where to put new objects. Knowing the nitty-gritty of CG helps in understanding that moving objects around can be very taxing. As you can see, it makes sense that if we can reduce the size of what we have to move, we''ll improve the whole GC process because there will be less to copy. What about things outside the managed heap? As the person responsible for garbage collection, one problem we run into in cleaning house is how to handle objects in the car. When cleaning, we need to clean everything up. What if the laptop is in the house and the batteries are in the car? There are situations where the GC needs to execute code to clean up non-managed resources such as files, database connections, network connections, etc. One possible way to handle this is through a finalizer. class Sample { ~Sample() { // FINALIZER: CLEAN UP HERE } } During object creation, all objects with a finalizer are added to a finalization queue. Let''s say objects 1, 4, and 5 have finalizers and are on the finalization queue. Let''s look at what happens when objects 2 and 4 are no longer referenced by the application and ready for garbage collection. Object 2 is treated in the usual fashion. However, when we get to object 4, the GC sees that it is on the finalization queue and instead of reclaiming the memory object 4 owns, object 4 is moved and it''s finalizer is added to a special queue named freachable. There is a dedicated thread for executing freachable queue items. Once the finalizer is executed by this thread on Object 4, it is removed from the freachable queue. Then and only then is Objet 4 ready for collection. So Object 4 lives on until the next round of GC. Because adding a finalizer to our classes creates additional work for GC it can be very expensive and adversely affect the performance garbage collection and thus our program. Only use finalizers when you are absolutely sure you need them. A better practice is to be sure to clean up non-managed resources. As you can imagine, it is preferable to explicitly close connections and use the IDisposable interface for cleaning up instead of a finalizer where possible. IDisposaible Classes that implement IDisposable perform clean-up in the Dispose() method (which is the only signature of the interface). So if we have a ResouceUser class instead of using a finalizer as follows: public class ResourceUser { ~ResourceUser() // THIS IS A FINALIZER { // DO CLEANUP HERE } } We can use IDisposable as a better way to implement the same functionality: public class ResourceUser : IDisposable { #region IDisposable Members public void Dispose() { // CLEAN UP HERE!!! } #endregion } IDisposable in integrated with the using keyword. At the end of the using block Dispose() is called on the object declared in using(). The object should not be referenced after the using block because it should be essentially considered "gone" and ready to be cleaned up by the GC. public static void DoSomething() { ResourceUser rec = new ResourceUser(); using (rec) { // DO SOMETHING } // DISPOSE CALLED HERE // DON''T ACCESS rec HERE } I like putting the declaration for the object in the using block because it makes more sense visabally and rec is no longer available outside of the scope of the using block. Whis this pattern is more in line with the intention of the IDisposible interface, it is not required. public static void DoSomething() { using (ResourceUser rec = new ResourceUser()) { // DO SOMETHING } // DISPOSE CALLED HERE } By using using() with classes that implement IDisposible we can perform our cleanup without putting additional overhead on the GC by forcing it to finalize our objects. Static Variables: Watch Out! class Counter { private static int s_Number = 0; public static int GetNextNumber() { int newNumber = s_Number; // DO SOME STUFF s_Number = newNumber + 1; return newNumber; } } If two threads call GetNextNumber() at the same time and both are assigned the same value for newNumber before s_Num} If two threads call GetNextNumber() at the same time and both are assigned the same value for newNumber before s_Number is incremented they will return the same result!word is one way to ensure only one thread can access a block of code at a time. As a best practice, you should lock as little code as possible because threads have to wait in a queue to execute the code in the lock() block and it can be inefficient. class Counter { private static int s_Number = 0; public static int GetNextNumber() { lock (typeof(Counter)) { int newNumber = s_Number; // DO SOME STUFF newNumber += 1; s_Number = newNumber; return newNumber; } } } Static Variables: Watch Out... Number 2! The next thing we have to watch out for objects referenced by static variables. Remember, how anything that is referenced by a "root" is not cleaned up. Here''s one of the ugliest examples I can come up with: class Olympics { public static Collection<Runner> TryoutRunners; } class Runner { private string _fileName; private FileStream _fStream; public void GetStats() { FileInfo fInfo = new FileInfo(_fileName); _fStream = _fileName.OpenRead(); } } Because the Runner Collection is static for the Olympics class, not only will objects in the collection will not be released for garbage collection (they are all indirectly referenced through a root), but as you probably noticed, every time we run GetStats() the stream is opened to the file. Because it is not closed and never released by GC this code is effectively a disaster waiting to happen. Imagine we have 100,000 runners trying out for the Olympics. We would end up with that many non-collectable objects each with an open resource. Ouch! Talk about poor performance! Singleton One trick to keep things light is to keep only one instance of a class in memory at all times. To do this we can use the GOF Singleton Pattern. One trick to keep things light is to keep only one instance of a utility class in memory at all times. One easy way to do this we can use the GOF Singleton Pattern. Singletons should be used with caution because they are really "global variables" and cause us much headached and "strange" behavior in multi-threaded applications where different threads could be altering the state of the object. If we are using the singleton pattern (or any global variable) we should be able to justify it (in other words... don''t do it without a good reason). public">{ private static Earth _instance = new Earth(); private Earth() { } public static Earth GetInstance() { return _instance; } } We have a private constructor so only Earth can execute it''s constructor and make an Earth. We have a static instance of Earth and a static method to get the instance. This particular implementation is thread safe because the CLR ensures thread safe creation of static variables. This is the most elegant way I have found to implement the singleton pattern in C#. In Conclusion... So to wrap up, some things we can do to improve GC performance are:
Next time we''ll look even more closely at the GC process and look into ways to check under the hood as your program executes to discover problems that may need to be cleaned up. 本文来源:
参考文档:
将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内容管理系统 | |