Silverlight Memory leakage (2) address memory leakage and misuse of Dispose

Document directory

•  

The second article in sequence should be "how to detect SIlverlight Memory leakage", but this series of logs solve the actual problem. Some detection results are not saved, and it is impossible to write these articles, and reproduce the bug. Write it wherever you think.

We can see many articles that unregister the event in Dispose to release resources when the event is resolved to cause memory leakage, which may cause unexpected problems.

Introduction to the Dispose Mode

Reference: Valid tive C #-Clause 18: implementing the Standard Dispose Mode

Key points:

By implementing the IDisposable interface, you have written two things: first, a mechanism is provided to release all the hosted resources in a timely manner, the other is that you provide a standard mode for users to release unmanaged resources. This is very important. When you implement the IDisposable interface on your type, you can avoid the loss of the structure. Your class has become a very good member in the. Net community.

However, some vulnerabilities still exist in the mechanism you created. How can a derived class clean up its own resources and make the base class clean up its resources? Because the base class's Dispose must be called when the base class has this method called. But as mentioned above, we only have one tag to identify whether the object has been processed. No matter which one is called first, there must be a method that cannot process the tag, which poses a risk) if the base class reloads the destructor, Or you add and implement the IDisposable interface, these methods must call the methods of the base class. Otherwise, the base class cannot release resources properly. Likewise, the Organization and processing share some of the same responsibilities: You can almost certainly copy the code between the method and the processing method. As you will learn in principle 26, the method of reloading interfaces does not work as expected. The third method in the standard Dispose mode uses a protected auxiliary virtual function to create common tasks and mount them to a derived class to release resources. The base class contains the core code of the interface. The Dispose () virtual function or destructor provided by the derived class is responsible for clearing resources.

Possible Dispose Problems

Dispose is an Object method. Any code can call it, and the subclass should call the Dispose of the base class. We can see that:

1. Dispose is an inherent method of. Net, and any code may call

2. Dispose is executed from top to bottom, and base class to subclass.

This indicates that Dispose is uncontrollable and other code may call this method.

MVVM light initially depends on Dispose to release resources. However, in the new version, the ICleanUp interface has been used to release resources because Dispose is too uncontrollable. However, to be compatible with earlier versions, Dispose is still valid.

Example of a problem caused by Dispose [ViewModelExport (typeof (ChapterViewModel), "Chapter")]

[PartCreationPolicy (CreationPolicy. NonShared)]

Public class ChapterViewModel: NavViewModel

{

ChapterService service = new ChapterService ();

Public C

[ViewModelExport (typeof (ChapterViewModel), "Chapter")]

[PartCreationPolicy (CreationPolicy. NonShared)]

Public class ChapterViewModel: NavViewModel

{

ChapterService service = new ChapterService ();

Public ChapterViewModel ()

{

Service. Loaded + = new EventHandler <AsyncEventArgs <object> (service_Loaded );

}

Void service_Loaded (object sender, AsyncEventArgs <object> arg)

{

}

Public void Dispose ()

{

Service. Loaded-= new EventHandler <AsyncEventArgs <object> (service_Loaded );

}

}

HapterViewModel ()

{

Service. Loaded + = new EventHandler <AsyncEventArgs <object> (service_Loaded );

}

Void service_Loaded (object sender, AsyncEventArgs <object> arg)

{

}

Public void Dispose ()

{

Service. Loaded-= new EventHandler <AsyncEventArgs <object> (service_Loaded );

}

}

As expected, Dispose will log out of the event to avoid Memory leakage. However, service_Loaded may not be executed during runtime because Dispose () is called by a third-party program and these calls may be concealed.

In this program, the following code calls Dispose and is not easy to detect.

Var viewModelFactory = viewModelMapping. CreateExport ();

ViewModel = viewModelFactory. Value as IViewModel;

ViewModelFactory. Dispose ();
Solution

You can use other methods to deregister an event, such as explicit interfaces, weak references, and anonymous methods. Several solutions are described in the article about memory leakage caused by the event.

Cleanup logout event in MVVM Light

Public override void Cleanup ()

{

Service. Loaded-= new EventHandler <AsyncEventArgs <object> (service_Loaded );

Messenger. Default. Unregister (this );

Base. Cleanup ();

}
MVVM Light problems

The above method should solve the problem, but service_Loaded may not be executed. Previously, Mvvm Light called Cleanup in the Dispose method to maintain compatibility with the previous version.

Overload Dispose

Protected override void Dispose (bool disposing)

{

// Override the base class
Disable cleanup

}
Conclusion

1. Try not to use Dispose to release managed resources and use your own interfaces.

2. Other methods should never be called in Dispose, such as calling cleanup in MVVM light, which may cause problems.

3. The complexity of code caused by third-party frameworks should be considered.