为后台任务保留Tempfile，调用ObjectSpace.undefine_finalizer有何风险？

你提到的ObjectSpace.undefine_finalizer(tempfile)方案确实能绕过GC自动删除临时文件的机制，避免大文件复制的资源浪费，但这么做存在几个明确的风险：

• 磁盘与内存泄漏风险：如果后台任务异常终止、或者你忘记手动删除文件并释放tempfile引用，这个对象会一直驻留在内存中，对应的几GB大文件也会持续占用磁盘空间。日积月累下来，很容易把磁盘占满，甚至拖垮服务器。
• 文件句柄泄漏：如果没手动调用tempfile.close关闭文件句柄，即使取消了finalizer，操作系统的文件句柄也会被持续占用。当进程可用句柄数耗尽时，后续所有涉及文件操作的功能都会直接失败。
• 进程异常导致文件残留：如果Ruby进程在你手动删除文件之前重启、崩溃，这些临时文件会永久留在磁盘上——因为原本的finalizer已经被取消，没有任何自动清理机制能处理它们，只能靠手动清理或额外的定时脚本兜底。
• 线程/任务冲突问题：如果多个后台任务同时操作这类取消了finalizer的临时文件，没做好同步控制的话，可能出现文件被重复删除、读取时文件已不存在等异常情况。

安全实践建议 #

• 无论后台任务成功还是失败，必须在任务结束的所有分支里手动调用tempfile.close!（关闭并删除文件）或者File.unlink(tempfile.path)来清理文件，同时主动释放tempfile引用（比如赋值为nil）。
• 额外加一个定时清理脚本，扫描Rails的临时文件目录（默认是tmp/uploads），删除超过一定时间阈值（比如24小时）的残留文件，防止进程崩溃或任务异常导致的文件堆积。
• 在后台任务里做好完整的错误捕获，哪怕任务抛出异常，也要确保文件清理逻辑能执行。
• 如果用Sidekiq这类队列工具，重试任务时要注意：要么确保每次重试都能正确识别文件状态，要么在第一次失败时就清理文件，避免重复操作无效资源。

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