在Delphi中是否需对Boolean属性做多线程保护？结合EventBus源码分析

这得分两种核心场景来讨论，结合你提到的EventBus源码场景，我来拆解说明：

1. 仅对Boolean字段做直接读写时 #

在x86/x64架构的Delphi环境中，Boolean是1字节大小的类型。CPU对单字节内存的读写操作本身是原子性的——不会出现“写了一半被打断”或者“读到半完成值”的情况。但这里有个容易被忽略的细节：内存可见性。

如果你的多线程场景里，一个线程修改Boolean值后，其他线程需要立刻获取到最新值，那仅靠普通读写就不够了。因为CPU缓存机制可能会让修改后的值暂时停留在核心缓存中，没有同步到主内存，导致其他线程读到旧值。这种情况下，推荐用TInterlocked类的方法来确保可见性，比如：

procedure TSubscription.SetActive(const Value: Boolean);
begin
  TInterlocked.Exchange(FActive, Value);
end;

function TSubscription.GetActive: Boolean;
begin
  Result := TInterlocked.Read(FActive);
end;

当然，多数普通场景下，如果线程对这个Boolean的访问频率不高、对时效性要求没那么极端，普通读写可能也能正常工作，但从多线程编程的严谨性来说，用TInterlocked是更稳妥的选择。

2. 属性读写包含附加业务逻辑时 #

像你看到的EventBus里的TSubscription.Active属性，它的SetActive和GetActive绝对不会是单纯的赋值/取值——比如设置Active为True时，大概率要把当前订阅项加入到事件总线的订阅列表；设置为False时要从列表中移除。这种情况下，必须做完整的多线程保护，因为集合的添加/移除操作本身是线程不安全的，多个线程同时操作会直接导致数据结构损坏。

这类场景下，通常会用临界区（TCriticalSection）来包裹整个逻辑，示例如下：

type
  TSubscription = class(TObject)
  private
    FActive: Boolean;
    FCriticalSection: TCriticalSection;
    procedure SetActive(const Value: Boolean);
    function GetActive: Boolean;
  public
    constructor Create;
    destructor Destroy; override;
    property Active: Boolean read GetActive write SetActive;
  end;

constructor TSubscription.Create;
begin
  inherited;
  FCriticalSection := TCriticalSection.Create;
end;

destructor TSubscription.Destroy;
begin
  FCriticalSection.Free;
  inherited;
end;

procedure TSubscription.SetActive(const Value: Boolean);
begin
  FCriticalSection.Enter;
  try
    if FActive <> Value then
    begin
      FActive := Value;
      // 这里执行订阅/取消订阅的核心逻辑
      if Value then
        EventBus.Subscribe(Self)
      else
        EventBus.Unsubscribe(Self);
    end;
  finally
    FCriticalSection.Leave;
  end;
end;

function TSubscription.GetActive: Boolean;
begin
  FCriticalSection.Enter;
  try
    Result := FActive;
  finally
    FCriticalSection.Leave;
  end;
end;

这种情况下，我们保护的不只是Boolean字段本身，而是整个关联的业务流程，避免多线程下的竞态条件。

总结 #

• 单纯Boolean字段读写：优先用TInterlocked保证原子性和内存可见性；
• 属性读写伴随其他线程不安全操作（如集合修改、资源调度）：必须用临界区或其他同步机制包裹完整逻辑。

内容的提问来源于stack exchange，提问作者DDGG