现代Rails对“线程+fork”反模式的韧性及代码实操注意事项

"线程+fork"是个常见的反模式，既可能单独出现（比如异步ActiveJob本地任务），也可能源自控制器（这时候得结合服务器策略来考量）。下面针对在线程内执行fork操作（比如在ActiveJob任务里）、甚至后续再次线程化的场景，整理代码层面的关键注意事项：

数据库连接处理 #

• 关于fork后断开重建数据库连接：Rails 6及以上的ActiveRecord已经自动处理这个问题。当检测到fork事件时，ActiveRecord会自动断开子进程继承的旧连接，需要时再新建连接，不用手动处理。但如果是Rails 6以下的版本，还是得手动执行断开和重建操作：

  ActiveRecord::Base.connection.disconnect!
  ActiveRecord::Base.establish_connection
  

共享Logger的潜在风险 #

• 虽然实际用起来共享Logger好像没问题，但暗藏风险：fork后的子进程会继承父进程的Logger文件句柄，多进程同时写日志可能导致内容错乱、句柄泄漏，甚至数据丢失。建议在fork后的子进程里重新初始化Logger，别复用父进程的实例。

Concurrent Ruby的资源清理 #

• 当前版本的Concurrent Ruby已经修复了fork相关的问题，能自动检测fork事件并终止父进程的线程。但fork进程结束时，还是得主动清理所有活跃的Concurrent任务池：
  • 如果是ActiveJob场景，执行下面的代码关闭队列适配器：

    ActiveJob::Base.queue_adapter.shutdown
    

  • 要是项目里用了Concurrent::Future这类全局执行器（比如Puma控制器里的场景），还得额外清理全局IO执行器：

    Concurrent::global_io_executor.shutdown
    Concurrent::global_io_executor.wait_for_termination
    

  别忘了：自定义的Concurrent执行器也得妥善关闭，别漏掉未完成的任务。

资源限制与优化 #

• PostgreSQL连接池：fork会复制父进程的连接池，很容易触发PostgreSQL的连接数上限（默认上限不高）。建议fork前主动缩小连接池大小：

  ActiveRecord::Base.connection_pool.disconnect!
  ActiveRecord::Base.configurations[Rails.env]['pool'] = 1
  ActiveRecord::Base.establish_connection
  

• 开发环境资源问题：用inotify watcher类的gem（比如spring、listen）时，开发环境下fork会耗尽watcher资源，要么避免这种场景，要么临时禁用相关gem；生产环境一般没这个问题。

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