如何排查Java内存泄露 JAVA 内存泄漏问题。

如何排查Java内存泄露

1.打开/tomcat_home/bin/catalina.bat文件
2.加上：set JAVA_OPTS=%JAVA_OPTS% -server -XX: HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:heapdump，这样当内存溢出是就会在对应路径下生成dump文件

运行程序打开jdk bin 文件夹下再带的 jvisualvm.exe

选择tomcat线程，打开实时监控页面可以看到对应的堆栈线程和装在类，内存的实时情况

运行程序打开jdk bin 文件夹下再带的 jconsole.exe，可以概览堆栈线程和装在类，内存的全部运行时间情况

下载安装mat，dump分析软件，安装后，点击file open 导入dump文件

打开后，灰色区域为可能发生内存溢出的区域，下带问题描述

选择Histogram，点击shallow列进行排序，找出实例最多的

右键实例最的选择list objects-with incoming references，可在根据正则表达式输入自己想查的类，搜索，后右键打开 path to gc root-exclude phantom/weak/soft etc. references 就可以查出 调用为回收的相关信息。

JAVA 内存泄漏问题。

Java中虽然使用了gc策略，但事实上还是会出现内存泄漏现象的，java因此还提出了弱引用等局部解决方案。

但楼主说的System.exit(0)是不会形成内存泄漏的。

其实这里都是两个范畴的内存了。楼上以及我开始说的Java中的内存是指虚拟机的内存，映射到宿主机可以有各种实现，虽然一般也是映射到内存。 而System.exit(0)会析构掉虚拟机，也就是把这个虚拟的机器都拆了，也就无从谈起虚拟机内存泄漏不泄漏的概念，正所谓皮之不存，毛将焉附。而问题是宿主机的内存是否泄漏了。从原理上说，虚拟机运行时，不管执行怎样的指令，映射到宿主机器资源，都回在机器被拆掉时释放。当然，从实现上说，如果宿主操作系统，或者JVM有bug，当然有可能造成内存泄漏，但和java程序员写的客户程序无关。（补充：包括在宿主机内杀java进程，其资源回收问题是操作系统和java平台的责任。我们在古老的操作系统经常会遇到文件没正常关闭之类的问题，但现在的操作系统这些问题应该不会很大，也就是宿主机其实也有一定的回收机制，包括内存回收，但着本身不是内存泄漏的范畴，内存泄漏是指程序运行时的客户程序造成的内存资源失控。当客户程序退出时的问题，就是操作系统设计的范畴了）

java中内存泄露有几种

一、Java内存回收机制
不论哪种语言的内存分配方式，都需要返回所分配内存的真实地址，也就是返回一个指针到内存块的首地址。Java中对象是采用new或者反射的方法创建的，这些对象的创建都是在堆（Heap）中分配的，所有对象的回收都是由Java虚拟机通过垃圾回收机制完成的。GC为了能够正确释放对象，会监控每个对象的运行状况，对他们的申请、引用、被引用、赋值等状况进行监控，Java会使用有向图的方法进行管理内存，实时监控对象是否可以达到，如果不可到达，则就将其回收，这样也可以消除引用循环的问题。在Java语言中，判断一个内存空间是否符合垃圾收集标准有两个：一个是给对象赋予了空值null，以下再没有调用过，另一个是给对象赋予了新值，这样重新分配了内存空间。
二、Java内存泄露引起原因
首先，什么是内存泄露？经常听人谈起内存泄露，但要问什么是内存泄露，没几个说得清楚。内存泄露是指无用对象（不再使用的对象）持续占有内存或无用对象的内存得不到及时释放，从而造成的内存空间的浪费称为内存泄露。内存泄露有时不严重且不易察觉，这样开发者就不知道存在内存泄露，但有时也会很严重，会提示你Out of memory。
那么，Java内存泄露根本原因是什么呢？长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是java中内存泄露的发生场景。具体主要有如下几大类：
1、静态集合类引起内存泄露：
像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。
例:
Static Vector v = new Vector(10)
for (int i = 1 i<100 i )
{
Object o = new Object()
v.add(o)
o = null
}//
在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身（o=null），那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。
2、当集合里面的对象属性被修改后，再调用remove（）方法时不起作用。
例：
public static void main(String[] args)
{
Set set = new HashSet()
Person p1 = new Person("唐僧","pwd1",25)
Person p2 = new Person("孙悟空","pwd2",26)
Person p3 = new Person("猪八戒","pwd3",27)
set.add(p1)
set.add(p2)
set.add(p3)
System.out.println("总共有:" set.size() " 个元素!") //结果：总共有:3 个元素!
p3.setAge(2) //修改p3的年龄,此时p3元素对应的hashcode值发生改变

set.remove(p3) //此时remove不掉，造成内存泄漏
set.add(p3) //重新添加，居然添加成功
System.out.println("总共有:" set.size() " 个元素!") //结果：总共有:4 个元素!
for (Person person : set)
{
System.out.println(person)
}
}
3、监听器
在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。
4、各种连接
比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。
5、内部类和外部模块等的引用
内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。此外程序员还要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如：
public void registerMsg(Object b)
这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。

如何避免JavaScript的内存泄露

使用 Chrome 发现内存泄露
实质上有两种类型的泄露：周期性的内存增长导致的泄露，以及偶现的内存泄露。显而易见，周期性的内存泄露很容易发现；偶现的泄露比较棘手，一般容易被忽视，偶尔发生一次可能被认为是优化问题，周期性发生的则被认为是必须解决的 bug。

以 Chrome 文档中的代码为例：
var x = [] function createSomeNodes() { var div, i = 100, frag = document.createDocumentFragment() for (i > 0 i--) { div = document.createElement("div") div.appendChild(document.createTextNode(i " - " new Date().toTimeString())) frag.appendChild(div) } document.getElementById("nodes").appendChild(frag) } function grow() { x.push(new Array(1000000).join(x)) createSomeNodes() setTimeout(grow,1000) }

当 grow 执行的时候，开始创建 div 节点并插入到 DOM 中，并且给全局变量分配一个巨大的数组。通过以上提到的工具可以检测到内存稳定上升。

找出周期性增长的内存

timeline 标签擅长做这些。在 Chrome 中打开例子，打开 Dev Tools ，切换到 timeline，勾选 memory 并点击记录按钮，然后点击页面上的 The Button 按钮。过一阵停止记录看结果：

两种迹象显示出现了内存泄露，图中的 Nodes（绿线）和 JS heap（蓝线）。Nodes 稳定增长，并未下降，这是个显著的信号。

JS heap 的内存占用也是稳定增长。由于垃圾收集器的影响，并不那么容易发现。图中显示内存占用忽涨忽跌，实际上每一次下跌之后，JS heap 的大小都比原先大了。换言之，尽管垃圾收集器不断的收集内存，内存还是周期性的泄露了。

确定存在内存泄露之后，我们找找根源所在。

保存两个快照

切换到 Chrome Dev Tools 的 profiles 标签，刷新页面，等页面刷新完成之后，点击 Take Heap Snapshot 保存快照作为基准。而后再次点击 The Button 按钮，等数秒以后，保存第二个快照。

筛选菜单选择 Summary，右侧选择 Objects allocated between Snapshot 1 and Snapshot 2，或者筛选菜单选择 Comparison ，然后可以看到一个对比列表。

此例很容易找到内存泄露，看下 (string) 的 Size Delta Constructor，8MB，58个新对象。新对象被分配，但是没有释放，占用了8MB。

如果展开 (string) Constructor，会看到许多单独的内存分配。选择某一个单独的分配，下面的 retainers 会吸引我们的注意。

我们已选择的分配是数组的一部分，数组关联到 window 对象的 x 变量。这里展示了从巨大对象到无法回收的 root（window）的完整路径。我们已经找到了潜在的泄露以及它的出处。

我们的例子还算简单，只泄露了少量的 DOM 节点，利用以上提到的快照很容易发现。对于更大型的网站，Chrome 还提供了 Record Heap Allocations 功能。

Record heap allocations 找内存泄露

回到 Chrome Dev Tools 的 profiles 标签，点击 Record Heap Allocations。工具运行的时候，注意顶部的蓝条，代表了内存分配，每一秒有大量的内存分配。运行几秒以后停止。

上图中可以看到工具的杀手锏：选择某一条时间线，可以看到这个时间段的内存分配情况。尽可能选择接近峰值的时间线，下面的列表仅显示了三种 constructor：其一是泄露最严重的（string），下一个是关联的 DOM 分配，最后一个是 Text constructor（DOM 叶子节点包含的文本）。

从列表中选择一个 HTMLDivElement constructor，然后选择 Allocation stack。

现在知道元素被分配到哪里了吧（grow -> createSomeNodes），仔细观察一下图中的时间线，发现 HTMLDivElement constructor 调用了许多次，意味着内存一直被占用，无法被 GC 回收，我们知道了这些对象被分配的确切位置（createSomeNodes）。回到代码本身，探讨下如何修复内存泄露吧。

另一个有用的特性

在 heap allocations 的结果区域，选择 Allocation。

这个视图呈现了内存分配相关的功能列表，我们立刻看到了 grow 和 createSomeNodes。当选择 grow 时，看看相关的 object constructor，清楚地看到 (string), HTMLDivElement 和 Text 泄露了。

结合以上提到的工具，可以轻松找到内存泄露。

android 系统中 gc 什么情况下会出现内存泄露

出现情况: 1. 数据库的cursor没有关闭 2.构造adapter时,没有使用缓存contentview 衍生listview的优化问题-----减少创建view的对象,充分使用contentview,可以使用一静态类来优化处理getview的过程/ 3.Bitmap对象不使用时采用recycle()释放内存 4.activity中的对象的生命周期大于activity 调试方法: DDMS==> HEAPSZIE==>dataobject==>[Total Size]