StringBuilder对象池性能基准测试异常：池化比直接实例化更慢

1. 测试代码的核心错误 #

你的WithPool方法存在关键问题：每次Benchmark运行时都重新创建DefaultObjectPoolProvider和StringBuilder池。创建对象池本身包含初始化开销（比如内部队列、同步机制的构建），这部分额外成本完全抵消了池化的收益，甚至超过直接实例化的开销。正确做法是将池实例提升为类字段，仅初始化一次：

[MemoryDiagnoser]    
public class StringBuilderPoolPerformance
{
    private readonly StringBuilderPool _stringBuilderPool;

    public StringBuilderPoolPerformance()
    {
        _stringBuilderPool = new DefaultObjectPoolProvider().CreateStringBuilderPool();
    }

    [Benchmark]
    public void WithoutPool()
    {
        for (int i = 0; i < 10000; i++)
        {
            var stringBuilder = new StringBuilder();
            stringBuilder.Append("Hello World" + i);
        }
    }

    [Benchmark]
    public void WithPool()
    {
        for (var i = 0; i < 10000; i++)
        {
            var stringBuilder = _stringBuilderPool.Get();
            stringBuilder.Append("Hello World" + i);
            _stringBuilderPool.Return(stringBuilder);
        }
    }
}

2. 场景不匹配池化的优势 #

当前测试场景过于简单：每个StringBuilder仅Append一个短字符串，实例化和回收的成本极低。而DefaultObjectPool是线程安全实现，内部包含同步锁开销，在这种小对象、低开销的场景下，池化的管理成本（Get/Return的锁、状态检查）反而比直接分配+GC回收更高。

只有当你需要频繁创建大容量StringBuilder，或者StringBuilder的初始化/扩容成本很高时，池化才能体现性能优势——此时避免重复分配大内存块、减少GC压力的收益会超过池的管理开销。

3. .NET对StringBuilder的原生优化 #

.NET 7+对小容量StringBuilder做了大量优化：比如小容量实例可能使用栈分配内存，GC对这类小对象的回收效率极高（Gen0回收速度极快），进一步缩小了池化的收益空间。

不需要额外特殊配置，但要保证测试的正确性：

• 把昂贵的对象（比如对象池）移到类字段，在构造函数中初始化，避免每次Benchmark调用都重复创建。
• 可以显式指定测试的运行时，确保对比环境一致：

  [SimpleJob(RuntimeMoniker.Net70)]
  [SimpleJob(RuntimeMoniker.Net80)]
  [MemoryDiagnoser]    
  public class StringBuilderPoolPerformance { ... }
  

• 必须在Release模式下运行基准测试，Debug模式的性能数据没有参考价值，BenchmarkDotNet默认会强制使用Release编译，但手动运行时要注意。

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