我通过Pro * C获得了嵌入式SQL for Oracle的c代码。
每当我进行插入或更新时（下面给出更新示例），
update TBL1 set COL1 = :v, . . . where rowid = :v
为了管理批量插入和更新，我已经分配了几个内存块作为批量和提交一次插入。在必要时，还会有其他内存分配。如何更好地管理动态内存分配的内存（堆）？一种选择是在GNU链接时间内配置堆大小。我正在使用g ++版本2.95，我知道这是一个相当旧的版本，但必须将其用于遗留。由于可执行文件（在solaris 10上运行），obce内置，可以在具有不同资源的多个生产环境上运行，因此用于堆大小分配的单一大小适合可能不合适。作为替代方案，需要一些机制，其中堆可以在需要时弹性地生长。与Linux不同，我认为，Solaris没有过度分配内存的概念。因此，如果没有剩余空间，则内存分配可能会因ENOMEM而失败。什么可能是更好的策略，知道我们可以跨越危险级别，现在我们应该释放我们正在存储的块，以防这些是使用或传输内存块到oracle DB完成的情况下，如果这些仍然有待加载，最后解除分配。您可以建议的任何策略？
答案 0 :(得分：1)
\^([\w]+)\@([\w]+){5}\.([\w]+)$\
不是C，其中堆大小在启动时是固定的。
java已编译应用程序的堆和堆栈共享相同的虚拟内存空间并动态调整。
此空间的大小取决于您是编译32位还是64位二进制文件，以及您的内核是32位还是64位（在SPARC硬件上，它总是64位） ）。
如果你没有足够的RAM并且希望Solaris无论如何都接受大容量内存预留，就像Linux提交内存一样，你可以添加足够的交换量来保留实际存储。
如果出于某种原因，您对Solaris libc内存分配器不满意，则可以评估捆绑的备用代理，例如libumem，mtmalloc或第三方hoard。有关详细信息，请参阅http://www.oracle.com/technetwork/articles/servers-storage-dev/mem-alloc-1557798.html。
答案 1 :(得分：0)
一种解决方案是在代码中使用软限制以用于各种目的，例如：一次只处理100个事务，其他事务必须等到前一个事务被释放。这保证了可预测的行为，因为没有代码部分可以占用比允许的内存更多的内存。
问题是： 你真的在你的应用程序中耗尽了内存，或者你是否破坏了内存并且无法获得足够大的连续内存块？处理每个案件的策略是不同的。