方法内线程安全计数器：非MRI多线程服务器重试代码安全性探讨

这个问题得先看你的重试代码里计数器的作用域——是方法内的局部变量，还是多个线程共享的实例/类变量？不同情况在非MRI（比如JRuby、TruffleRuby这类真多线程环境）下的线程安全性完全不一样，我给你拆解清楚：

情况1：计数器是方法内的局部变量 #

如果你的代码是类似这样的：

def call_service
  retry_count = 0
  begin
    # 实际调用服务的逻辑
    external_service.invoke
  rescue ServiceUnavailableError => e
    retry_count += 1
    retry if retry_count < 3
    raise "Failed after 3 retries: #{e.message}"
  end
end

那完全不需要担心线程安全，也根本不需要用Mutex加锁。

原因很简单：局部变量是绑定在当前方法的调用栈上的，每个线程发起的方法调用都会创建独立的retry_count变量，线程之间完全不会互相干扰。哪怕是在非MRI的真多线程环境里，每个请求/线程的局部变量都是各自私有，不存在竞态条件。

情况2：计数器是共享的实例变量或类变量 #

如果你的计数器是多个线程共享的（比如单例客户端里的实例变量，或者全局的类变量），比如这种写法：

class GlobalServiceClient
  @@total_retry_count = 0
  MAX_RETRIES = 3

  def self.call_service
    begin
      external_service.invoke
    rescue ServiceUnavailableError => e
      @@total_retry_count += 1
      retry if @@total_retry_count % MAX_RETRIES != 0 # 举个共享计数的例子
      raise "Too many retries"
    end
  end
end

那在非MRI环境下必须用Mutex加锁，否则会出现线程安全问题。

为什么非MRI下会出问题？ #

MRI（标准Ruby解释器）有GIL（全局解释器锁），同一时间只有一个线程能执行Ruby代码，所以哪怕是@@total_retry_count +=1这种非原子操作（本质是「读取旧值→加1→写入新值」三步），看起来也不会出问题——但这是GIL带来的“伪安全”，不是真的线程安全。

而JRuby、TruffleRuby这类非MRI实现没有GIL，多个线程会真的并行执行Ruby代码。这时候如果两个线程同时读取到@@total_retry_count = 0，各自加1后写入，最终结果会是1而不是2，出现计数错误的竞态条件。

正确的加锁写法 #

用Mutex的synchronize方法包裹共享变量的修改操作，保证同一时间只有一个线程能执行这段代码：

class ThreadSafeServiceClient
  @@total_retry_count = 0
  MAX_RETRIES = 3
  @@mutex = Mutex.new

  def self.call_service
    begin
      external_service.invoke
    rescue ServiceUnavailableError => e
      @@mutex.synchronize do
        @@total_retry_count += 1
        current_retry = @@total_retry_count
      end
      retry if current_retry % MAX_RETRIES != 0
      raise "Too many retries"
    end
  end
end

总结 #

• 如果计数器是方法内的局部变量：非MRI环境下完全线程安全，不需要Mutex。
• 如果计数器是多线程共享的实例/类变量：非MRI环境下必须用Mutex加锁，避免竞态条件导致计数错误。

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