doubts regarding Memory management in .net

I'm learning about Memory management in C# from the book "Professional C#"

The presence of the garbage collector means that you will usually not worry about objects that you no longer need; you will simply allow all references to those objects to go out of scope and allow the garbage collector to free memory as required. However, the garbage collector does not know how to free unmanaged resources (such as file handles, network connections, and database connections). When managed classes encapsulate direct or indirect references to unmanaged resources, you need to make special provision to ensure that the unmanaged resources are released when an instance of the class is garbage collected.

When defining a class, you can use two mechanisms to automate the freeing of unmanaged resources.

  • Declaring a destructor (or finalizer) as a member of your class.
  • Implementing the System.IDisposable interface in your class.
  • I didn't understand few things:

  • "unmanaged resources (such as file handles, network connections, and database connections)". Whats the big deal about them? How come they are unmanaged? (or) Why can't GC managed these resources?

  • What code would we place in finalizer or Dispose() method of the a class and what exactly that code would look like? Some examples using these resources, would be of lot of help.


  • The real question here is about urgency. As the garbage collector explicitly tracks memory, it will know when there is a need to free up memory by cleaning unreferenced objects. This can happen several times a minute, or once an hour, or even never (if no new objects needs to be created). But the important thing is that it does happen when needed.

    But memory isn't the only resource that is limited. Take files. Usually only one application at a time can open a file as it can become messy if several people tries to write to the same file. Databases have a limited amount of connections. And so on. The garbage collector doesn't track any of these resources. And it has no idea of how urgent it is to close them.

    Sure, you could open a FileStream and read from it without closing it afterwards. if you null out the reference to the object, eventually the garbage collector will probably decide to collect the FileStream object, which will have its Finalizer run and the file will get properly closed. But that could take a long time, and in the meanwhile the file is locked.

    With database connections it is far more urgent, as there is a very limited amount of collections available, so if you open too many connections without disposing of them you will eventually get an error as you will have a bunch of database objects having open connections that lie waiting in the garbage collector queue.

    Properly disposing of Disposable object is therefore good practice. Sometimes you could get away not doing so, but it is poor style. If an object implements IDisposable, it is because it wants you to clean it up when you are done using it.


    Some classes on the .NET framework are just wrappers of Windows APIs or third party assemblies. These APIs are not managed code (they can be written in C++ or they are old COM assemblies) and the garbage collector does not know when they are no longer required by the application.

    For example, when you open a file of disk, it will remain open until you tell it to close the file. If you destroy the pointer to the file (ie leaving the scope) without closing the file, this file will remain open and locked.

    The Dispose method implemented on the Framework for these classes calls the inner Close method required to finalize the instance in a clean way. So all the classes that wrap unmanaged code should implement the Disposable interface to assure that a closing method it's implemented.

    Then when you instance that class it is a good practice to do it with the using statement because then when you leave the scope the Dispose method is called automatically.


    1.) The GC does not know how to close external resources properly. Of course he could kill a network connection (which is, in fact, what he does if you don't disconnect ie a database connection). But the database isn't being notified of closing the connection.

    Similar goes for file streams. Is there still something in a buffer? Does that have to be written to file before closing the file handle? The GC does not know about this - the accessing code does.

    2.) Is what follows from that. So if you have open file streams and an internal buffer - in the dispose method you would flush the buffer, write it to the file and close the file hanlde.

    For usual, you don't directly access databases. You use libraries managing this for you.

    In most cases it's enough, to dispose those external resource managers (Db connection, filestream, network classes) if your class is being disposed.

    链接地址: http://www.djcxy.com/p/9230.html

    上一篇: 如何在C#中的Dispose()方法中处理托管资源?

    下一篇: 有关.net中内存管理的疑问