Service Fabric 参与者中的静态对象

Posted 2023-03-27

【中文标题】Service Fabric 参与者中的静态对象

【英文标题】：Static objects in Service Fabric actors

【发布时间】：2019-05-20 13:44:44

【问题描述】：

有一个具有以下定义的服务结构参与者通过实现IRemindable 接口进行注册和注销。这个演员也有一个静态字典。

[StatePersistence(StatePersistence.None)]
[ActorService(Name = "ProcessorActorService")]
public class ProcessorActor : BaseActor, IRemindable

 private static Dictionary<object,object> _myDictionary;

我的理解是，如果每个参与者的 guid 在实例化时不同，则服务结构会创建同一个参与者的多个实例。当每个演员实例被创建时，提醒的动作将一个对象添加到字典中以供以后处理。

我的期望/理解是字典的范围在同一个实例化的actor中，但是当下一个actor的实例出现时，我意识到_myDictionary具有添加到另一个actor中的节点！所以，它给人的印象是字典在所有相同actor类型的实时实例之间共享！这是正确的理解还是再次调用同一个已经实例化的actor？！

由于参与者实现了IRemindable，我希望 GC 在取消注册后将参与者从集群中删除，但它似乎没有发生。静态字典是否可能导致演员的实例停留？

【参考方案1】：

我认为这更像是 .Net 问题，而不是 Service Fabric 问题。据我所知，静态实例仅在收集 AppDomain 后才会收集（通常是在进程终止时）。

查看Fundamentals of Garbage Collection，了解收集实例的方式和时间。

关于如何维护状态，我建议你看看Introduction to Service Fabric Reliable Actors，它可能会帮助你实现你想要的。

更新

另外，看看Reliable Actors state management。

希望对你有帮助！

【讨论】：

谢谢。好吧，我想我应该重新表述一下我的问题。我知道维护服务结构和参与者中的状态，具体来说，我不希望在同一参与者的多个实例之间共享该静态字典。那么，如果参与者假设使用 abcdef123 的 Guid 被激活，它是否会与另一个具有 cde543 的 guid 的参与者共享该静态字典？这是我不想发生的事情。

那么不要使用静态字典，使用 Service Fabric 的内置状态机制（即可靠参与者）。有关状态管理的链接，请参阅更新。

你认为那个静态字典是否会导致演员的实例徘徊？它对演员的一生有影响吗？

别这么认为，actor是一个常规实例而不是静态实例，只有静态的“部分”被保留在周围

如果使用 Service Locator 反模式，直接从容器的静态根请求实例而不是使用构造函数注入，这是有道理的。

【参考方案2】：

我的理解是，如果每个参与者的 guid 在实例化时不同，则服务结构会创建同一个参与者的多个实例。

这是正确的。每个新 ID 都会生成一个新的 Actor 实例。

---

来自docs：

使用 static 修饰符声明一个静态成员，该成员属于类型本身而不是特定对象。

当您将privatestaticDictionary<object,object> _myDictionary; 声明为 static 时，您是在告诉 CLR 该字段不属于该对象的实例，而是属于类型定义，在这种情况下，它会生成一个属于 Actor 类型而不是运行时创建和销毁的对象的单个实例。

保存actor状态的正确方法是使用状态管理器，像这样：

[StatePersistence(StatePersistence.Persisted)]
class MyActor : Actor, IMyActor

  public MyActor(ActorService actorService, ActorId actorId)
    : base(actorService, actorId)
  
  

  public Task<int> GetCountAsync()
  
    return this.StateManager.GetStateAsync<int>("MyState");
  
 

documentation 更详细地解释了它。

【讨论】：

谢谢。请参阅我向 Itay 提出的问题。 @迭戈