There is a service fabric actor with the following definition which is registered and then unregistered by implementing IRemindable interface. This actor has a static dictionary too.
[StatePersistence(StatePersistence.None)]
[ActorService(Name = "ProcessorActorService")]
public class ProcessorActor : BaseActor, IRemindable
{
private static Dictionary<object,object> _myDictionary;
}
My understanding is that service fabric creates multiple instances of the same actor if each actor's guid is different at instantiation time. When each actor instance is created the reminder's action adds an object to the dictionary for processing later on.
My expectation/understanding has been such that the dictionary's scope is within the same instantiated actor, but when the next actor's instance comes to life, I realize that the _myDictionary has the nodes that were added in another actor! So, it kind of gives the impression that the dictionary is shared among all live instances of the same actor type! Is that a correct understanding or the same already-instantiated actor is called again?!
Since the actor implements IRemindable I expect the GC to remove the actor from the cluster after unregistering it but it does not seem to be happening. Is it possible that the static dictionary causes the actor's instance to stick around?
I think it's more of a .Net issue than a Service Fabric issue. As far as I remember, static instances are only collected once the AppDomain is collected (usually when the process terminates).
Take a look at Fundamentals of Garbage Collection on how and when instances get collected.
Regarding how to maintain state, I suggest you take a look at Introduction to Service Fabric Reliable Actors, it might help you achieve what you want.
Update
Also, take a look at Reliable Actors state management.
Hope it helps!