For managed resources, .NET's GC mechanism can recover unwanted garbage. However, for non-hosting resources, you must manually release its resources. What is a non-managed resource? For example, file access, network access, etc., these resources need to be cleared manually. Is it true? Let's do an experiment. Establish a class
Public class filegc {? private filegc ()? {?? m_srfile = file.open (".// 1.txt", filemode.openorcreate, fileaccess.write);?}} This class is simple, Create or open the 1.txt file when instantiated.
Create a form that adds a button above. Add the following events when the form is initialized. Private Void BTGC_Click (Object Sender, System.EventArgs E) {? gc.collect ();
In this way, when the form is initialized, a useless resource fileGC f is generated. To verify that 1.TXT is opened, you can try to delete 1.txt in the directory. At this point you will find that the prompt file is being accessed. When you press the button, the program enforces GC operation, and the F object is destroyed. In fact, the M_SRFILE object at this time is also destroyed. For verification, try to delete 1.txt. success. Waiting for one, there is a conflict here that the GC mechanism cannot be released for non-hosting resources? How is the M_SRFILE object to turn off for 1.TXT?
Theoretically, F object is cleared, but because the m_srfile object is used by non-managed resources, it cannot be cleared. But the fact is that the m_srfile object is cleared. Is Stream how to clear itself? Glues are not enough. Use ILDASM to open the mscorlib.dll file, this file is the main accessory of the .NET Framework class, Mscorlib.dll contains most of our class. Take it out.
After opening, see a tree directory system-> system.io-> stream to see the statement of this class. .class public abstract auto ansi beforefieldinit Stream ?????? extends System.MarshalByRefObject ?????? implements System.IDisposableextends System.MarshalByRefObject description which is derived from System.MarshalByRefObject. Implements System.idisposable and uses the System.IDisposable interface.
The IL of the entire stream did not find the operation of the recycling file handle. Whether we find the wrong direction and see the type of File.Open open files. System.io.file.open looks at its code. .method public hidebysig static ??????? class 'system.io'. 'filestream' ??????? 'open', ???????????? ?? ValueType 'system.io'. 'filemode' 'mode', ?????????????? valueetype 'system.io'. 'fileaccess' 'Access', ?????? ???????? valueetype 'system.io'. 'fileshare' 'Share') CIL Managed The original return type is FileStream instead of stream. Let's take a look at the type of FileStream. First look at the type of defined class public auto ANSI Beforefieldinit 'filestream' extends 'system.io'. 'Stream' can see Since FileStream is inherited from stream, it can be converted to Stream after FILE.OPEN. Look down, you will see the Finalize method. Yes, it is it, when the GC finds it useless, perform the operations that clear it to occupy the memory. Name destructor, here can be similar to C .
Open this method. You will find an important statement callvirt ?? instance void 'system.io'. 'Filestream' :: '4e' (bool) is originally executing the Dispose method before performing GC operation. We understand this. It turns out that Net has been doing these things for us. Similarly, I also viewed some other resources such as networks, and found that .NET has been doing these operations for us. Although it is non-managed resource, you don't have to worry about resource leakage. Unless you use the API function to open, you must write a Finalize method yourself. I am very shallow, and the mistake is also forgotten to criticize the guidelines. Also welcome to discuss issues with like-minded friends who are interested in .NET. Contact: QQ: 85627584 mailbox: fjl716@163.com
