Memory leaks 通知程序的潜在内存泄漏

运行桌面执行跟踪工具包时，我注意到一些奇怪的行为

跟踪内存分配指出了一些奇怪的行为，在我看来，这似乎是一个漏洞

此处跟踪和测试vi的图片=>

---

在获得通知程序时，内存被分配（一次或两次，取决于具体情况）和释放（要么根本不分配，要么一次释放），这意味着获得的每个通知程序都是一个已分配且未释放的内存块。这可能是我们的代码中使用大量或获取并发布的通知程序运行了很长一段时间的错误的原因。这是已知的行为，分配的内存在跟踪范围外自动释放，还是真正的低影响内存泄漏？

根据提供的示例，很难判断是否确实存在泄漏，因为看不到使用的按钮顺序（创建和销毁）。你有没有在这两者之间发送数据？你一直都是在创建之后发布的吗？你能发布你测试的VI并描述一下你到底是如何测试它的吗

如果通知程序只创建了一次，然后就被释放了，那么没有内存分配发生，请查看下图

因此，在您的情况下，会发生一些额外的事件，这些事件会导致内存分配。而且，将代码实现为FGV（或动作引擎）有助于消除这样的问题，因为您将确保引用只打开一次，然后再重新使用。当引用打开多次，但关闭次数较少时，将发生内存泄漏。 另一点——在LabVIEW中动态分配缓冲区是很常见的事情，可能会因为不同的原因而发生。但LabVIEW编译器足够聪明，可以处理这样的缓冲区，所以通常不用担心这一点。缓冲区被分配，然后刷新，等等。只需确保引用总是关闭的——因为LabVIEW内存问题的主要原因是没有释放引用。

---

作为评论：您应该将其重构为动作引擎/功能性全局类型设计。使用严格的typedef枚举确定要执行的操作。我自己总是更喜欢排队——他们似乎不太受这类问题的困扰。我要说的是，refnums是LabVIEW中最大的内存泄漏问题之一。这个VI只是一个复制该问题的测试，所以是的，但不是…）那很有趣。如果我运行你使用的VI，我会得到不同的跟踪。每个获得分配的两个内存块，只释放一个。很像我提供的跟踪的前半部分。您运行的是哪个LabVIEW版本？使用一些更好的内存分析器，我发现实际上没有泄漏。这似乎是一个陷阱。