如何避免TIF转WebP并行处理时的内存不足异常？

首先得说，你遇到的内存不足问题，核心原因有两个：未正确释放图片资源，以及并行线程过多导致内存占用瞬间飙升。先给你拆解下解决方案，再聊聊PrivateMemorySize64的作用。

1. 先修复最关键的资源泄漏问题 #

你当前的代码里，Image和Bitmap没有被正确释放！这些都是占用非托管内存的资源，常规循环里线程少，GC可能还来得及回收，但并行时大量未释放的图片实例会瞬间吃光内存。必须把它们放进using块里，确保资源及时释放：

var options = new ParallelOptions();
// 先别急着调并行度，先把资源释放做好
Parallel.ForEach(MyList, options, (row) => {
    byte[] rawWebP;
    // 用using包裹Image和Bitmap，确保使用后立即释放非托管内存
    using (Image image = Image.FromFile(row.linkToImage))
    using (Bitmap bmp = (Bitmap)image)
    using (WebP webp = new WebP())
    {
        rawWebP = webp.EncodeLossless(bmp, row.linkToImage);
        // 这里如果rawWebP需要写入文件或做其他操作，记得处理完后也尽量及时释放引用
    }
});

2. 限制并行度，避免内存过载 #

Parallel.ForEach默认会根据CPU核心数创建尽可能多的线程，但图片处理是内存密集型任务，不是CPU密集型——线程越多，同时加载的图片就越多，内存占用就越高。你可以通过ParallelOptions限制最大并行数，比如根据CPU核心数减半，或者测试一个合适的数值：

// 比如用CPU核心数的一半，避免占满所有资源
var options = new ParallelOptions 
{ 
    MaxDegreeOfParallelism = Math.Max(1, Environment.ProcessorCount / 2) 
};
Parallel.ForEach(MyList, options, (row) => {
    // 上面带using的转换代码
});

你可以根据实际测试调整这个数值，比如如果是8核CPU，先试试4个并行线程，看内存占用是否稳定。

3. 聊聊PrivateMemorySize64的作用 #

currentProcess.PrivateMemorySize64只是用来监控当前进程的私有内存占用量，它本身不能直接解决内存不足问题——它是一个“诊断工具”，不是“解决方案”。比如你可以用它做动态调整并行度的逻辑：定期检查内存，如果超过某个阈值就降低并行数，但这种实现比较复杂，还有额外的性能开销，远不如直接限制并行度+修复资源泄漏来得高效。所以它绝对不是最佳实践，只能作为辅助监控手段。

4. 进阶优化：分批处理（如果图片数量极大） #

如果你的图片列表特别长（比如上千张），可以把列表分成小批次处理，每处理完一批就给GC留出回收内存的时间：

int batchSize = 15; // 根据内存情况调整批次大小
var options = new ParallelOptions { MaxDegreeOfParallelism = 4 };

for (int i = 0; i < MyList.Count; i += batchSize)
{
    var currentBatch = MyList.Skip(i).Take(batchSize).ToList();
    Parallel.ForEach(currentBatch, options, (row) => {
        // 带using的转换代码
    });
    // 可选：强制触发一次GC，不过尽量让GC自动处理，除非内存压力确实很大
    // GC.Collect();
}

总结一下：优先修复资源泄漏（加using），然后限制并行度，这两个步骤就能解决大部分内存不足的问题。PrivateMemorySize64只适合用来做监控，不是核心解决方案。

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