嘿，你的这个测试思路确实有点绕，读写文件+解析的开销太大了，完全没必要靠文件来触发OOM，给你几个更高效的方案，分分钟就能达到测试目的：

• 直接在内存中分配超大对象：跳过文件IO的所有开销，直接创建远超可用内存的对象。比如在.NET里可以直接声明超大数组：

  // 尝试创建一个超出内存上限的字节数组
  byte[] massiveArray = new byte[int.MaxValue];
  

  或者如果是字符串场景，直接拼接出巨量字符串（不过字符串是不可变类型，会产生大量中间对象，也能快速耗尽内存）。这种方式没有磁盘IO和解析开销，CPU占用低，触发OOM的速度极快。

• 持续创建小对象并持有引用：如果要模拟更贴近真实场景的内存耗尽（比如内存泄漏导致的OOM），可以用一个长生命周期的容器（比如静态集合）不断存储小对象，不让GC回收：

  // 静态集合会一直持有引用，GC无法回收这些对象
  private static List<object> _memoryHog = new List<object>();
  
  public static void TriggerOOM()
  {
      while (true)
      {
          // 每次添加1KB的字节数组，持续占用内存
          _memoryHog.Add(new byte[1024]);
      }
  }
  

  这种方式内存会平稳增长，你还可以控制增长速度，方便观察内存变化，CPU开销也很小。

• 模拟内存泄漏场景：如果你的测试目标是验证程序在内存泄漏时的表现，可以构造真实的泄漏场景。比如让长生命周期对象持有大量短生命周期对象的引用：

  // 全局静态字典，持有临时请求对象的引用
  private static Dictionary<string, object> _leakyCache = new Dictionary<string, object>();
  
  public void ProcessRequest(string requestId)
  {
      // 临时对象，本该在请求结束后被回收
      var tempData = new byte[1024 * 1024]; // 1MB数据
      // 错误地将临时对象存入全局字典，导致无法回收
      _leakyCache.Add(requestId, tempData);
  }
  

  多次调用这个方法后，内存会逐渐耗尽，这种场景更贴近实际生产中出现OOM的原因。

• 限制程序可用内存：如果你想更快触发OOM，而不是等内存涨到系统上限，可以直接限制程序的内存配额。比如在.NET Core/.NET 5+中，启动程序时可以通过参数设置内存限制：

  dotnet run --memory-limit 100MB
  

  这样程序可用内存被限制在100MB，不管你用哪种方式分配内存，都会很快触发OOM。

原来的方案依赖文件读写和解析，不仅慢，还会占用大量CPU和磁盘资源，完全是绕远路——毕竟OOM本质是内存耗尽，直接在内存层面操作才是最直接高效的方式。

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