调用内存后,C#内存不足

我有一个C#应用程序,它可以完成一些小部件,但它执行的主要任务是通过它调用的Delphi DLL完成的。

这个Delphi DLL是一个完整的内存管理器,为了提高速度,它需要在本地缓存大量的数据库信息。 我很高兴它不会泄漏,因为FastMM4在Delphi中运行代码时没有报告任何内存泄漏。

但是,当控件返回到C#时,我开始遇到问题。 C#代码尝试对Delphi应用程序的结果进行一些计算(所有结果都通过DB进行编组)。 这些计算通常涉及一百万左右,所以不会出现极端的内存使用情况,但是代码会让我退出内存异常。

我假设Delphi代码中的FastMM4仍然没有将释放的内存返回给Windows(因此可用于C#代码),因此该进程仍在使用它的最大32位内存分配,并且C#无法获得更多需要。

那么,如何让Delphi使用(和释放)的内存再次由C#代码使用? 我认为我们可能想要执行以下任一操作:

  • 强制从C#端卸载Delphi DLL(我的同事认为这不会起作用,因为他认为它只是卸载代码而不是堆上使用的内存) - 可能是LoadLibrary / FreeLibrary?
  • 在Delphi DLL的末尾调用以释放内存回Windows(我之前尝试过SetWorkingProcessSetSize,但似乎没有做任何事情,我应该使用不同的调用吗?)
  • 将Delphi DLL包装在一个C#DLL中,并在不同的AppDomain中调用它(我不喜欢这种风格的角度,因为我们只是为了容纳包装而创建包装。
  • 还有什么我错过了?

  • 强制从C#端卸载Delphi DLL(我的同事认为这不会起作用,因为他认为它只是卸载代码而不是堆上使用的内存) - 可能是LoadLibrary / FreeLibrary?

    这只会工作。 当DLL卸载时,FastMM将完成并返回它保留并提交的内存。


    我要做的一件事就是在调用库之前调用GC.Collect 。 当知道更多的托管内存被请求时,.NET知道该怎么做,而不是自动调用收集器,但是它不知道你在本机代码中做了什么,因此会有大量内存被不必要地分配。

    我也将从32位体系结构中移出。 这并不是说你的内存不足,而是你用尽了足够大的连续内存来满足你在Delphi中要做的任何事情。 一个更大的虚拟地址空间将为你解决这个问题,并且在过去的6年中没有一个处理器没有64位的能力。 现在是时候把这些害羞的步骤带到我们前面的美好未来。

    链接地址: http://www.djcxy.com/p/91033.html

    上一篇: C# out of memory after calling a memory

    下一篇: lock<std::mutex> prohibit dll unloading