内存泄漏和内存溢出的定义及其解决方案

内存泄漏和内存溢出确实是编程中令人头疼的问题，但它们各有特点。为了让你快速把握核心区别，我先用一个表格来对比它们：

特征	内存泄漏 (Memory Leak)	内存溢出 (Memory Overflow / Out of Memory, OOM)
​本质​	程序未能释放不再使用的内存，导致可用内存逐渐减少。	程序申请内存时，系统无法满足其需求，可用内存不足。
​关键原因​	代码逻辑缺陷，如忘记释放、意外持有引用等。	申请内存过大，或系统确实没有足够内存。
​发生速度​	通常是缓慢积累的过程，随时间推移症状逐渐明显。	可能突然发生​（如一次性申请过大），也可能由泄漏积累引发。
​主要影响​	长期运行后性能下降，响应变慢，最终可能因内存耗尽导致崩溃。	程序立即崩溃或异常终止，系统可能不稳定。
​类比​	水管有细微裂缝，水慢慢漏出，水池最终会空。	需要一大桶水，但水池本身容量就不够或已经快空了。

---

🧠 内存泄漏（Memory Leak）

内存泄漏是指程序中已动态分配的堆内存由于某种原因未能释放或无法释放，造成系统内存的浪费。

• ​常见原因​：

  • ​未释放动态分配的内存​：在 C/C++ 中，使用 malloc、new等分配内存后，未使用 free、delete释放。

  • ​意外持有多余引用​：

    • ​全局变量或静态变量无意中引用了对象，阻止了垃圾回收（在 Java 等语言中）。

    • ​闭包​（Closure）不当使用可能导致内存泄漏。

    • ​事件监听器未及时移除。

    • ​集合类中的对象不再需要后未及时清除。

  • ​其他资源未释放​：如文件句柄、数据库连接、网络套接字等未正确关闭。

• ​解决方案​：

  • ​良好编程习惯​：确保分配的内存和资源最终都被释放。遵循“谁分配，谁释放”的原则。

  • ​使用智能指针​（C++）：利用 std::unique_ptr、std::shared_ptr（注意避免循环引用，可配合 std::weak_ptr）等自动管理内存生命周期。

  • ​代码审查​：定期进行代码审查，重点关注内存和资源的分配与释放。

  • ​使用工具检测​：

    • ​Valgrind​（Linux）：强大的内存调试工具。

    • ​AddressSanitizer​（GCC, Clang）：编译时添加 -fsanitize=address。

    • ​Visual Studio Diagnostic Tools​（Windows）：集成开发环境中的内存分析工具。

    • ​浏览器开发者工具​（Web开发）：例如 Chrome DevTools 的 Memory 面板，可拍摄堆快照分析内存使用。

---

💥 内存溢出（Out of Memory, OOM）

内存溢出是指程序在申请内存时，​没有足够的内存空间供其使用。 内存泄漏的积累是导致内存溢出的常见原因之一。

• ​常见原因​：

  • ​内存泄漏积累​：内存泄漏导致可用内存不断减少。

  • ​一次性申请过大内存​：如尝试读取一个超大的文件到内存，或处理海量数据时未分段加载。

  • ​系统配置限制​：JVM 等运行环境初始分配的内存过小。

  • ​程序设计不当​：如数据结构选择不合理，算法空间复杂度高。

• ​解决方案​：

  • ​增加系统内存​：或调整程序运行环境的内存参数​（如 JVM 的 -Xmx参数）。

  • ​优化程序逻辑​：

    • 对于海量数据，采用分块处理、流式读取，避免一次性加载全部数据。

    • 使用更高效的数据结构和算法，减少内存开销。

    • 释放不再使用的缓存或其他可重建的大型对象。

  • ​使用内存池​：对频繁申请释放的小块内存，使用内存池技术减少碎片和提高效率。

  • ​修复内存泄漏​：这是解决因泄漏导致溢出的根本方法。

---

💎 总结与最佳实践

1. ​理解区别​：​泄漏是“只进不出”，溢出是“要太多却没有”​。泄漏是原因，溢出可能是结果。

2. ​重在预防​：

   • ​C/C++​​：优先使用 ​智能指针和 ​RAII​ 机制管理资源。

   • ​Java/Python/Go​：理解垃圾回收机制，注意避免循环引用​（特别是被全局变量或静态变量引用），必要时使用弱引用。

   • ​所有语言​：注意及时释放非内存资源​（文件、连接等）。

3. ​善用工具​：在开发测试阶段积极使用内存检测工具来发现潜在问题。

4. ​监控与 profiling​：对长期运行的系统，进行持续的内存使用监控，以便及时发现内存使用量的异常增长趋势。

希望这些信息能帮助你更好地理解和处理内存问题。

怎么查看内存泄漏

C/C++

1. Valgrind: Debugging and profiling Linux programs, aiming at programs written in C and C++
2. ccmalloc: Linux和Solaris下对C和C++程序的简单的使用内存泄漏和malloc调试库
3. LeakTracer: Linux、Solaris和HP-UX下跟踪和分析C++程序中的内存泄漏
4. Electric Fence: Linux分发版中由Bruce Perens编写的malloc()调试库
5. Leaky: Linux下检测内存泄漏的程序
6. Dmalloc: Debug Malloc Library
7. MEMWATCH: 由Johan Lindh编写，是一个开放源代码C语言内存错误检测工具，主要是通过gcc的precessor来进行
8. KCachegrind: A visualization tool for the profiling data generated by Cachegrind and Calltree

内存泄漏的解决方案

第一：良好的编码习惯，尽量在涉及内存的程序段，检测出内存泄露。当程式稳定之后，在来检测内存泄露时，无疑增加了排除的困难和复杂度。使用了内存分配的函数，一旦使用完毕,要记得要使用其相应的函数释放掉。

第二：将分配的内存的指针以链表的形式自行管理，使用完毕之后从链表中删除，程序结束时可检查改链表。防止出现野指针。

第三：Boost 中的三种智能指针。

内存溢出，内存泄漏的原因？

    内存溢出是指程序在申请内存时，没有足够的内存空间供其使用。原因可能如下：

 内存中加载的数据量过于庞大，如一次从数据库取出过多数据

 代码中存在死循环或循环产生过多重复的对象实体

 递归调用太深，导致堆栈溢出等

 内存泄漏最终导致内存溢出

    内存泄漏是指向系统申请分配内存进行使用（new），但是用完后不归还（delete），导致占用有效内存。常见的几种情况：

   （1）在类的构造函数和析构函数中没有匹配的调用new和delete函数

        两种情况下会出现这种内存泄露：一是在堆里创建了对象占用了内存，但是没有显示地释放对象占用的内存；二是在类的构造函数中动态的分配了内存，但是在析构 函数中没有释放内存或者没有正确的释放内存

   （2）在释放对象数组时在delete中没有使用方括号

      方括号是告诉编译器这个指针指向的是一个对象数组，同时也告诉编译器正确的对象地址值病调用对象的析构函数，如果没有方括号，那么这个指针就被默认为只指向一个对象，对象数组中的其他对象的析构函数就不会被调用，结果造成了内存泄露。

    （3）没有将基类的析构函数定义为虚函数

       当基类指针指向子类对象时，如果基类的析构函数不是virtual，那么子类的析构函数将不会被调用，子类的资源没有正确是释放，因此造成内存泄露

     参考链接： https://blog.csdn.net/hyqwmxsh/article/details/52813307    

     缓冲区溢出（栈溢出）

     程序为了临时存取数据的需要，一般会分配一些内存空间称为缓冲区。如果向缓冲区中写入缓冲区无法容纳的数据，机会造成缓冲区以外的存储单元被改写，称为缓冲区溢出。而栈溢出是缓冲区溢出的一种，原理也是相同的。分为上溢出和下溢出。其中，上溢出是指栈满而又向其增加新的数据，导致数据溢出；下溢出是指空栈而又进行删除操作等，导致空间溢出。

什么是内存溢出

内存溢出是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于虚拟机能提供的最大内存。 引起内存溢出的原因有很多种，常见的有以下几种：
1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
3.代码中存在死循环或循环产生过多重复的对象实体；
4.使用的第三方软件中的BUG；
5.启动参数内存值设定的过小；

内存溢出的解决方案

第一步，修改JVM启动参数，直接增加内存。(-Xms，-Xmx参数一定不要忘记加。)
第二步，检查错误日志，查看“OutOfMemory”错误前是否有其它异常或错误。
第三步，对代码进行走查和分析，找出可能发生内存溢出的位置。重点排查以下几点：
1.检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
2.检查代码中是否有死循环或递归调用。 　　
3.检查是否有大循环重复产生新对象实体。 　　
4.检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中 数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。 　　
5.检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。