Tesseract.js内存泄漏问题分析与解决方案

问题背景

在使用Tesseract.js进行OCR识别时，开发者发现当重复创建和销毁Worker与Scheduler时，内存占用呈现持续增长趋势。典型场景表现为：

1. 初始化16个Worker的Scheduler
2. 处理约8000个识别任务后重置
3. 内存从初始30GB增长到50GB且无法回收

技术分析

预期行为

在理想情况下，Tesseract.js的资源管理应遵循：

• Worker创建时会加载语言模型和WASM运行环境
• Scheduler终止时应释放所有Worker占用的内存
• 垃圾回收机制(GC)会回收不再使用的内存

实际现象

通过内存监控发现：

• 每次重建Scheduler后内存基准线升高
• 大尺寸图片(4000x3000px)处理时内存增长更显著
• 即使调用terminate()和手动触发GC，内存仍无法完全释放

根本原因

经过深入排查，发现存在两个关键问题：

1. WASM内存限制问题 Tesseract.js底层依赖WebAssembly，而WASM对内存管理有特殊机制：

• 大尺寸图片处理时需要分配连续内存空间
• WASM内存页(64KB)分配后不会主动释放
• 多次处理大图会导致内存碎片化积累

2. Scheduler管理缺陷 原始代码存在竞态条件：

// 错误示例：多个异步调用可能同时创建Scheduler
module.exports.getScheduler = async () => {
    if (!state.scheduler) {
        state.scheduler = await create() // 可能被多次执行
    }
    return state.scheduler;
};

解决方案

最佳实践方案

1. 单例模式改造

let initPromise = null;
module.exports.getScheduler = async () => {
    if (!state.scheduler && !initPromise) {
        initPromise = create().then(s => {
            state.scheduler = s;
            return s;
        });
    }
    return initPromise || state.scheduler;
};

2. 图片预处理优化

• 使用sharp库将大图缩放至合理尺寸(建议不超过2000px长边)
• 转换为灰度图像减少内存占用

await sharp(input)
    .resize(2000)
    .grayscale()
    .toBuffer()

3. 内存监控策略

// 在Node.js中定期记录内存状态
setInterval(() => {
    const usage = process.memoryUsage();
    console.log(`RSS: ${Math.round(usage.rss/1024/1024)}MB`);
}, 5000);

经验总结

1. WASM应用需要特别注意内存管理，不同于常规JavaScript应用
2. 高并发场景下的资源初始化必须考虑竞态条件
3. 对于长期运行的服务，建议：
   • 保持Worker/Scheduler持久化
   • 采用工作队列替代频繁创建销毁
   • 实施内存水位监控和自动重启机制

通过以上优化，实际应用中内存可稳定控制在10GB以内，解决了原始的内存泄漏问题。这为其他Tesseract.js的高强度使用场景提供了有价值的参考方案。