电脑内存泄漏是怎么回事
发布网友
共5个回答
懂视网
本文由ImportNew-黄索远翻译自captaindebug ImportNew注：如果你也对Java技术翻译分享感兴趣，欢迎加入我们的Java开发小组。参与方式请查看小组简介。 如果你看过这篇博客的第一部分，就会知道在展示的内存泄露示例代码使用生产者-消费者模型创建了一个模拟
本文由 ImportNew - 黄索远 翻译自 captaindebug
ImportNew注：如果你也对Java技术翻译分享感兴趣，欢迎加入我们的 Java开发 小组。参与方式请查看小组简介。
如果你看过这篇博客的第一部分，就会知道在展示的内存泄露示例代码使用生产者-消费者模型创建了一个模拟股票交易的应用，所有的交易命令都被存入一个虚拟的数据库中。示例代码故意留下了一个缺陷（OrderRecord线程处理一条命令后sleep一段时间），使得OrderRecord线程消费命令的速度跟不上OrderFeed线程生产命令的速度。这就意味着存储命令的队列会变得越来越长，直到最后内存溢出程序崩溃。问题是，如果只看我的代码，确实能够很轻松得看出哪里出了差错；但是如果出问题的代码你从未看过并且代码又长又复杂，加之没有监控线程来帮助你观察队列大小或者其他内部信息，这时该怎么办呢？
下面向大家介绍分析程序内存泄露问题的三个步骤：
提取发生内存泄露的服务器的转储文件。
用这个转储文件生成报告。
分析生成的报告。
有几个工具能帮你生成堆转储文件，分别是：
jconsole
Jvisualvm
Eclipse Memory Analyser Tool（MAT）
用jconsole提取堆转储文件
将jconsole关联你的应用：单击MBeans选项卡打开com.sun.management包，点击HotSpotDiagnostic，点击Operations选择dumpHeap。这时你将会看到dumpHeap操作：它接受两个参数p0和p1。在p0的编辑框内输入一个堆转储的文件名，然后按下DumpHeap命令。
用jvisualvm提取堆转储文件
连接示例代码，右键点击你的应用，在左侧的“application”窗格中选择“Heap Dump”。
注意：如果你在发生内存泄露的服务器上有一个远程连接，那么jvisualvm将会把转出文件保存在远程机器（假设这是一台unix机器）上的/tmp目录下。你不得不将这个文件通过FTP传送到你的机器上，然后再进行研究。
用MAT来提取堆转储文件
jconsole和jvisualvm本身就是JDK的一部分，而MAT或者称作“内存分析工具”，是一个基于eclipse的工具。你可以从eclipse.org下载。
最新版本的MAT需要你在电脑上安装JDk1.6。如果你用的是Java1.7版本也不用担心，因为它会自动为你安装1.6版本，并且不会和安装好了的1.7版本产生冲突。
使用MAT的时候，只需要点击“Aquire Heap Dump”，然后遵循指示就可以了。
远程连接
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
何时提取堆转存文件
这需要耗费一点心力和运气。如果太早提取了堆转储文件，那么你将不能发现问题。因为它们被合法，非泄露类的实例屏蔽了。不过也不能等待太久，因为提取堆转储文件需要占用内存，进行提取操作的时候可能会导致你的应用崩溃。
最好的办法是将jconsole连接到你的应用程序并监控堆的占用情况，知道它看起来像在崩溃的边缘。这样很容易就能监控到，因为没有发生内存泄露时，三个堆部分指标都是绿色的。
分析转储文件
现在轮到MAT发挥作用了，因为它本身就是被设计用来分析堆转储文件的。要打开和分析一个堆转储文件，选择File选项下的Heap Dump选项。选择了你要打开的文件后，你将会看到如下三个选项：
选择Leak Suspect Report选项。在MAT翻腾几秒后，会生成这样的一个页面：
如饼状图显示：在示例中，疑似有一处发生了内存泄露。也许你会想，这样的做法只有在代码受到控制的情况下才可取。毕竟这只是个例子，这又能说明什么呢？好吧，我承认在这个例子里，所有的问题都是可见的；线程a占用了98.7MB内存，其他线程用了1.5MB。在实际情况中，你得到的图表是这样的。
下一步要做的就是挖得更深一点……
如上图所示，报告的下一部分告诉我们，有一个LinkedBlockQueue占用了98.46%的内存。想要进一步的探究，点击Details>>。
可以看到，问题确实是出在我们的orderQueue上。这个队列里存储了所有生成的虚拟命令，并且可以被我们上篇博文里提到的三个线程OrderFeed、OrderRecord、OrderMonitor访问。
那么一切都清楚了，MAT告诉我们：示例代码中有一个LinkedBlockQueue，这个队列用尽了所有的内存，从而导致了严重的问题。不过我们不知道这个问题为什么会产生，也不能指望MAT告诉我们。这个问题，如阿加莎·克里斯蒂笔下的赫尔克里·波洛所说，得用“泽灰色小细胞”解决……
热心网友
cpu资源耗尽：估计是机器没有反应了，键盘，鼠标，以及网络等等。这个在windows上经常看见，特别是中了毒。
进程id耗尽：没法创建新的进程了，串口或者telnet都没法创建了。
硬盘耗尽： 机器要死了，交换内存没法用，日志也没法用了，死是很正常的。
内存泄漏或者内存耗尽：新的连接无法创建，free的内存比较少。发生内存泄漏的程序很多，但是要想产生一定的后果，就需要这个进程是无限循环的，是个服务进程。当然，内核也是无限循环的，所以，如果内核发生了内存泄漏，情况就更加不妙。内存泄漏是一种很难定位和跟踪的错误，目前还没看到有什么好用的工具（当然，用户空间有一些工具，有静态分析的，也会动态分析的，但是找内核的内存泄漏，没有好的开源工具）
内存泄漏和对象的引用计数有很大的关系，再加上c/c++都没有自动的垃圾回收机制，如果没有手动释放内存，问题就会出现。如果要避免这个问题，还是要从代码上入手，良好的编码习惯和规范，是避免错误的不二法门。
一般我们常说的内存泄漏是指堆内存的泄漏。
堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显示释放的内存。
应用程序一般使用malloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。
(附)部分内存泄漏检测工具
1.ccmalloc－Linux和Solaris下对C和C++程序的简单的使用内存泄漏和malloc调试库。
2.Dmalloc－Debug Malloc Library.
3.Electric Fence－Linux分发版中由Bruce Perens编写的malloc()调试库。
4.Leaky－Linux下检测内存泄漏的程序。
5.LeakTracer－Linux、Solaris和HP-UX下跟踪和分析C++程序中的内存泄漏。
6.MEMWATCH－由Johan Lindh编写，是一个开放源代码C语言内存错误检测工具，主要是通过gcc的precessor来进行。
7.Valgrind－Debugging and profiling Linux programs, aiming at programs written in C and C++.
8.KCachegrind－A visualization tool for the profiling data generated by Cachegrind and Calltree.
9.IBM Rational PurifyPlus－帮助开发人员查明C/C++、托管.NET、Java和VB6代码中的性能和可靠性错误。PurifyPlus 将内存错误和泄漏检测、应用程序性能描述、代码覆盖分析等功能组合在一个单一、完整的工具包中。
10.Parasoft Insure++－针对C/C++应用的运行时错误自动检测工具，它能够自动监测C/C++程序，发现其中存在着的内存破坏、内存泄漏、指针错误和I/O等错误。并通过使用一系列独特的技术（SCI技术和变异测试等），彻底的检查和测试我们的代码，精确定位错误的准确位置并给出详细的诊断信息。能作为Microsoft Visual C++的一个插件运行。
11.Compuware DevPartner for Visual C++ BoundsChecker Suite－为C++开发者设计的运行错误检测和调试工具软件。作为Microsoft Visual Studio和C++ 6.0的一个插件运行。
12.Electric Software GlowCode－包括内存泄漏检查，code profiler，函数调用跟踪等功能。给C++和.Net开发者提供完整的错误诊断，和运行时性能分析工具包。
13.Compuware DevPartner Java Edition－包含Java内存检测,代码覆盖率测试,代码性能测试,线程死锁,分布式应用等几大功能模块。
14.Quest JProbe－分析Java的内存泄漏。
15.ej-technologies JProfiler－一个全功能的Java剖析工具，专用于分析J2SE和J2EE应用程序。它把CPU、执行绪和内存的剖析组合在一个强大的应用中。
16.BEA JRockit－用来诊断Java内存泄漏并指出根本原因，专门针对Intel平台并得到优化，能在Intel硬件上获得最高的性能。
热心网友
所谓的内存泄漏可以理解为内存单元逐渐被无用的数据占用，在c c++里可以通过内存单元没有释放引起，java里可以通过未对作废数据内存单元的引用置null引起分配了内存而没有释放，逐渐耗尽内存资源，导致系统崩溃。
内存泄露是指程序中间动态分配了内存，但是在程序结束时没有释放这部分内存，从而造成那一部分内存不可用的情况，重起计算机可以解决，但是也有可能再次发生内存泄露，内存泄露和硬件没有关系，它是由软件设计缺陷引起的。
内存泄漏可以分为4类：
1. 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
2. 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
3. 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
4. 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。
热心网友
内存泄漏是由于申请的系统资源在用完后，没释放掉，
解决吗，一是及时释放资源，二优化算法，不过对编译
工具本身的泄漏好像*为力
热心网友
应用程序冲突 无所谓
没什么影响 最多就是有的应用程序不能继续工作~~
哈哈 应该是益处的
