退出程序时我应该担心“仍然可以访问”内存吗？

Question

我正在继续我的作业，涉及 C++ 中的哈希表。我昨天在这里问了一个关于释放内存的“正确方法”的question，因为我遇到了一些问题，而 valgrind 显示我泄漏了 17.000.000 字节的内存。

我今天一整天都在处理代码，我想我已经修复了它，并且在再次运行这个命令之后

valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --num-callers=20 --log-file=valgrind.log ./main

Valgrind

显示仍然有一些块可以到达。在对

Valgrind

FAQ 页面和 this 做了一些研究后，我发现

possibly lost

部分并没有那么重要，它仅指仅符合“内存泄漏”的第一个定义的分配。这些块没有被释放，但它们本可以被释放（如果程序员愿意的话），因为程序仍在跟踪指向这些内存块的指针。

这让我想到了三件事。

首先，在阅读了常见问题解答和之前的 SO 问题后，我假设现实生活中的程序员“不会关心”。我听说过军用导弹系统泄漏内存link，但他们从未修复它。

其次，此作业是针对我的 DataStructures 类的，该类“有点”侧重于内存管理（BST、LL 的指针……）。教授是一个非常严格的评分者，但我不确定他是否对每份提交的作业都进行了

valgrind

。我之所以这么说是因为看在上帝的份上，我无法在我的代码中找到“仍然可以访问”的块。如果我能简单地避免这种情况，那将为我节省很多时间和麻烦。

第三，很多编程语言我都不熟悉，但是听说过垃圾收集器（Java、JS、C#）。这是他们本质上所做的吗？ （释放未使用的内存）C++ 中没有垃圾收集器的特性是好事还是坏事？

我想我的最后一个问题是：如果我理解正确的话，我应该在多大程度上（从 1 到 10）关心仍然可以到达的块，从技术上讲，这不是内存泄漏，它只是内存管理不善。

谢谢

Valgrind报告（比这个大很多，我只是贴了“重要部分”）：

==350555== LEAK SUMMARY:
==350555==    definitely lost: 0 bytes in 0 blocks
==350555==    indirectly lost: 0 bytes in 0 blocks
==350555==      possibly lost: 0 bytes in 0 blocks
==350555==    still reachable: 20,919 bytes in 292 blocks
==350555==         suppressed: 0 bytes in 0 blocks
==350555== 
==350555== For lists of detected and suppressed errors, rerun with: -s
==350555== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)