In am not going to explain all the different lifestyles Windsor has as you could read up on them on the Castle Wiki but for the sake of completeness I will list the most important ones and explain them in my own words
- Service Locator
- Release Policy
- Lifecycle concerns
- But why and exactly when does the memory leak happen?
- What happens if we resolve a transient
- What happens if we resolve a transient component that is dependent on another transient component with a decommission concern?
- Always release after you are done
- Why does Windsor track components with a decommission concern?
- Singleton: This is actually the default lifestyle, means there will be only 1 instance of that class in your container (think static)
- PerThread: There will only 1 instance per thread (think threadstatic)
- PerWebRequest: There will only be 1 instance per web request
- Pooled: There will be multiple instances of the same object but in a pool with a minimum pool size and a maximum pool size
- Transient: Each time an instance is requested windsor will initialize a new one
If you are using Castle Windsor combined with service location you can get a lot of memory issues basically because the contract has no method for releasing your services/components. When you are using Windsor you should always try to avoid getting an instance from the container yourself and when you have to, remember to always release the component after using it!
But why is that? Why do we need to release our components that we ask for explicitly?
Again this is explained very detailed on the Castle Wiki but i will list the important ones.
- LifecycledComponentsReleasePolicy (default)
By default Windsor will use LifecycledComponentsReleasePolicy which keeps track of all components that were created, and upon releasing them, invokes all their decommission lifecycle steps.
In other words your garbage collector will not be able to cleanup if your container still tracks your component. Which will result into memory leaks. Now i’ve seen many posts and questions on the web about this where people are advising to use the NoTrackingReleasePolicy, don’t because the default release policy is actually a good thing!
See Castle Wiki for a detailed description.
- Creation - commission concerns : everything happening within ‘container.Resolve’ or similar method
- Destruction - decommission concerns : everything happening within and/or after ‘container.ReleaseComponent’.
A good example of a decommission concern is when your component implements IDisposable, the container will automatically recognize this as a decommission concern.
But why and exactly when does the memory leak happen?
If you look back on the lifestyles you will see that there are lifestyles, where the begin and end of the lifetime of the component is clear:
- Singleton : the life of the component start at commission (resolve) and ends when the container is disposed
- PerThread : the life of the component ends when the thread ends
- PerWebRequest : …
But what about Transient and Pooled ? Especially with these you gotta watch out!
What happens if we resolve a transient
So this actually means that Windsor is not tracking the component, which means the garbage collector will be able to clean up this instance.
What happens if we resolve a transient with a decommission concern for instance IDisposable
So if we don’t release the component after using it, the garbage collector will not be able to pick it up as Windsor is still referencing it and your dispose method will never get invoked!
What happens if we resolve a transient component that is dependent on another transient component with a decommission concern?
The tracking will propagate onto the parent service so again if we don’t release the service after using it, we will get a memory leak!
Always release after you are done
Why does Windsor track components with a decommission concern?
At the end of the lifetime of the component, either trough a implicit (Component or Component dependent on ends life) or explicit release (trough a container.Release), Windsor will execute all decommission steps. For instance when your component implements IDisposable, Windsor will call the Dispose method.
The LifecycledComponentsReleasePolicy is great because it will track your components that have no real end of life defined and will cleanup after you. But especially be aware if you have a singleton component taking in a transient dependency with a decommission concern, because even if you release your singleton component after using it, it will not release the transient dependency immediatly, it will have to wait until your singleton’s life ends!
Because the real releasing (think disposing) of your transient dependency will happen at the end the life of the singleton component, most of the time when your application stops, only then will the container release the reference to the transient dependency and eventually call the dispose method. And even then this is just 1 instance of that transient component, so that will not cause a memory issue.
But in a real world scenario where you follow the advice of if you have to resolve yourself, you release after using the component. You will have no memory leaks!