避免修改全局共享的对象

非必要的情况下尽量避免修改全局共享的对象，包括 $ 开头的全局变量、单实例对象、AST、类变量/方法等。

下面的写法是线程安全的，因为它没有修改全局的状态：

class RainyCloudFactory
  def self.generate
    cloud = Cloud.new
    cloud.rain!

    cloud
  end
end

下面的写法不是线程安全的，因为它修改了全局的状态：

class RainyCloudFactory
  def self.generate
    cloud = Cloud.new
    @@clouds << cloud

    cloud
  end
end

但是，如果非用全局共享的对象不可，也不是不能用，只要保证线程安全即可，例如：

require 'thread'

class Counter
  def initialize
    @counter = 0
    @mutex = Mutex.new
  end

  def increment
    @mutex.synchronize do
      @counter += 1
    end
  end
end

$counter = Counter.new

AST

上面提到的 AST 指的是程序的抽象语法树里的指令，Ruby 作为一门动态语言，是允许在运行时修改它的。所有的线程共享一份 AST, 因此在多线程环境下，同样存在线程安全的问题——虽然很罕见。kaminari 这个 Gem 曾经就出过这样的一个问题：https://github.com/kaminari/kaminari/issues/214

代码里动态地定义了一个方法，然后用 alias_method 为其创建别名，接着又删除了初始定义的那个方法。在多线程环境下，就会出现这样的情况：线程 A 定义了一个方法，并且为其创建了别名。接着线程 B 也定义了这个方法，覆盖了线程 A 定义的方法。然后线程 A 删除了该方法。线程 B 再为它创建别名时，就抛出了 NoMethodError 异常。

所以，为了线程安全，应该避免在运行时修改 AST. 这里的“运行时”，指的是应用程序运行的过程中。或者换句话说，AST 的修改应该在程序的启动过程中完成。

创建更多的对象，而不要共享同一个

有时候我们免不了还是需要使用全局对象，例如数据库连接。这时候有两种办法解决线程安全问题。

Thread-locals

Thread-locals 的方案，是让对象仅在当前线程里全局可见。下面是个例子：

# 把这样的代码：
$redis = Redis.new
# 用这种方式替代：
Thread.current[:redis] = Redis.new

Thread-locals 的方案会为每个线程创建一个对应实例。但是当线程数很大的时候，资源池可能是一个更好的方案。

资源池

假设有 N 个线程需要连接 Redis, 连接池里有 M 个连接可供使用，M < N. 这种情况下资源池仍然能够保证线程安全。

一个资源池通常维护着一定数量的资源供多个线程使用。当一个线程需要使用该资源（比如 Redis 连接）时，资源池会取出一个资源供其使用，并在使用完毕后将该资源放回池中以待下一个线程使用。这样保证了线程安全。

避免延迟加载

在 3.0 版本之前，Ruby on Rails 中的一个习惯用法是在运行时加载常量，用的是类似 Ruby 的 autoload 的方法。但这不是个好的做法，因为 MRI Ruby 的 autoload 并不是线程安全的。虽然在现在的 JRuby 里，autoload 是线程安全的，但最好的做法还是在派生 worker 线程之前预先加载需要的常量。

优先使用（线程安全的）数据结构而不是 Mutex

Mutex 不容易正确地使用。在使用 Mutex 的时候你要考虑许多问题：

• 这个 Mutex 的粒度应该有多大？
• 这里会不会发生死锁？
• 我应该为每个对象创建一个 Mutex 还是使用全局的 Mutex 对象？

以上问题只是需要考虑的其中一部分。当然对于熟练掌握 Mutex 用法的程序员来说，这些问题不难回答。

但使用数据结构（例如 Queue）可以免掉这些考量。与其担心这些问题，还不如干脆不用 Mutex.

另外，这里还有一些来自 JRuby wiki 的关于编写并发代码的“安全路径”：

• 不要编写并发代码，除非无法避免；
• 如果你非得编写并发代码不可，不要在线程间共享数据；
• 如果非得在线程间共享数据不可，不要共享可变数据；
• 如果非共享可变数据不可，在访问这些数据时做同步处理。