java内存泄漏代码 java 内存泄漏排查工具

如何编写一个java内存泄露程序？

自己改一下下面的代码，把堆栈中的元素改成mp3类型的或更大点的东西

4.Java中参数都是传值的。

对于基本类型，大家基本上没有异议，但是对于引用类型我们也不能有异议。

Java内存泄露情况

JVM回收算法 是很复杂的，我也不知道他们怎么实现的，但是我只知道他们要实现的就是：对于没有被引用的对象是可以回收的。所以你要造成内存泄露就要做到：

持有对无用对象的引用!

不要以为这个很轻易做到，既然无用，你怎么还会持有它的引用? 既然你还持有它，它怎么会是无用的呢?

以下以堆栈更经典这个经典的例子来剖析。

Java代码

public class Stack {

private Object[] elements=new Object[10];

private int size = 0;

public void push(Object e){

ensureCapacity();

elements[size++] = e;

}

public Object pop(){

if( size == 0)

throw new EmptyStackException();

return elements[--size];

}

private void ensureCapacity(){

if(elements.length == size){

Object[] oldElements = elements;

elements = new Object[2 * elements.length+1];

System.arraycopy(oldElements,0, elements, 0, size);

}

}

}

上面的原理应该很简单，假如堆栈加了10个元素，然后全部弹出来，虽然堆栈是空的，没有我们要的东西，但是这是个对象是无法回收的，这个才符合了内存泄露的两个条件：无用，无法回收。

但是就是存在这样的东西也不一定会导致什么样的后果，假如这个堆栈用的比较少，也就浪费了几个K内存而已，反正我们的内存都上G了，哪里会有什么影响，再说这个东西很快就会被回收的，有什么关系。下面看两个例子。

例子1

Java代码

public class Bad{

public static Stack s=Stack();

static{

s.push(new Object());

s.pop(); //这里有一个对象发生内存泄露

s.push(new Object()); //上面的对象可以被回收了，等于是自愈了

}

}

因为是static，就一直存在到程序退出，但是我们也可以看到它有自愈功能 ，就是说假如你的Stack最多有100个对象，那么最多也就只有100个对象无法被回收其实这个应该很轻易理解，Stack内部持有100个引用，最坏的情况就是他们都是无用的，因为我们一旦放新的进取，以前的引用自然消失！

例子2

Java代码

public class NotTooBad{

public void doSomething(){

Stack s=new Stack();

s.push(new Object());

//other code

s.pop();//这里同样导致对象无法回收,内存泄露.

}//退出方法,s自动无效,s可以被回收,Stack内部的引用自然没了,所以

//这里也可以自愈,而且可以说这个方法不存在内存泄露问题,不过是晚一点

//交给GC而已,因为它是封闭的,对外不开放,可以说上面的代码99.9999%的

//情况是不会造成任何影响的,当然你写这样的代码不会有什么坏的影响,但是

//绝对可以说是垃圾代码!没有矛盾吧,我在里面加一个空的for循环也不会有

//什么太大的影响吧,你会这么做吗?

}

相关问答

Q1: java内存泄露是什么意思？

Java内存泄露\x0d\x0a一般来说内存泄漏有两种情况。一种情况如在C/C++语言中java内存泄漏代码的java内存泄漏代码，在堆中java内存泄漏代码的分配的内存，在没有将其释放掉的时候，就将所有能访问这块内存的方式都删掉（如指针重新赋值）java内存泄漏代码；另一种情况则是在内存对象明明已经不需要的时候，还仍然保留着这块内存和它的访问方式（引用）。第一种情况，在Java中已经由于垃圾回收机制的引入，得到java内存泄漏代码了很好的解决。所以，Java中的内存泄漏，主要指的是第二种情况。\x0d\x0a可能光说概念太抽象了，大家可以看一下这样的例子：\x0d\x0a1Vectorv=newVector(10);\x0d\x0a2for(inti=1;i

回答于 2022-12-14

Q2: java内存泄露: java.lang.OutOfMemoryError: Java heap space is erro

出现这个问题，说明java内存泄漏代码你java内存泄漏代码的程序中创建的对象太多，占用了太多的堆空间。

这种问题从出现异常的代码处很难找到原因，因为很有可能是程序的其java内存泄漏代码他部分导致的。

为了解决这个问题，你可能需要借助到一些工具查找原因，看看什么对象分配得太多。

例如java内存泄漏代码：

Q3: 如何用Java编写一段代码引发内存泄露

1、首先得搞清楚什么叫内存泄露java内存泄漏代码，简单来说就是一个东西放在内存里的时间太长了java内存泄漏代码，当java内存泄漏代码你的程序都跑完了，它还存在那里。这时它是白白的占用了你的内存，累积起来占用的内存越来越多……最后就会导致JVM报错：out of memory。

2、一般情况下，别人如果能指出你的系统（程序）内存溢出，这个人应该还是挺厉害的。通常对于新人来说，喜欢把变量直接定义在class下（此时称之为实例变量，或者成员变量），那么在方法里调用后，这个实例变量是不会被释放的，大量的这样使用就可能会引发内存泄露。

3、把变量定义在方法里，当这个方法执行完毕后内存就得到释放了，这是个好习惯。

4、如果想要看到内存溢出，可以按这样的思路去尝试一下：定义一个静态的实例变量（list或其它集合），然后在一个方法里循环往这个静态变量塞东西，直到这个实例变量撑爆你的jvm内存。很快你就能看到out of memory……

import java.util.ArrayList;

import java.util.List;

public class MemoryTest {

private static List list = new ArrayList();

private static int count = 0;

public static void main(String[] args) throws InterruptedException {

System.out.println("申请前的可用内存 = "+getFreeMemory());

while(true){

list.add(new byte[1024*1024]);//用实例变量申请1M内存，当方法执行完毕时，这个static的变量是不会被释放

count++;

if (count % 100 == 0) {

System.out.println("当前list.size()="+list.size()+",可用内存 = "+getFreeMemory());

Thread.sleep(500);

}

}

}

public static long getFreeMemory() {

return Runtime.getRuntime().freeMemory() / (1024 * 1024);

}

}

Q4: 如何排查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 就可以查出 调用为回收的相关信息。

Q5: 如何防止java中的内存泄漏

尽管java虚

拟机和垃圾回收机制治理着大部分的内存事务，但是在java软件中还是可能存在内存泄漏的情况。的确，在大型工程中，内存泄漏是一个普遍问题。避免内存泄

漏的第一步，就是要了解他们发生的原因。这篇文章就是要介绍一些常见的缺陷，然后提供一些非常好的实践例子来指导你写出没有内存泄漏的代码。一旦你的程序

存在内存泄漏，要查明代码中引起泄漏的原因是很困难的。同时这篇文章也要介绍一个新的工具来查找内存泄漏，然后指明发生的根本原因。这个工具轻易上手，可

以让你找到产品级系统中的内存泄漏。

垃圾回收（GC）的角色

虽然垃圾回收关心着大部分的

问题，包括内存治理，使得程序员的任务显得更加轻松，但是程序员还是可能犯些错误导致内存泄漏问题。GC(垃圾回收)通过递归对所有从“根”对象(堆栈中

的对象，静态数据成员，JNI句柄等等)继续下来的引用进行工作，然后标记所有可以访问的活动着的对象。而这些对象变成了程序唯一能够操纵的对象，其他的

对象都被释放了。因为GC使得程序不能够访问那些被释放的对象，所以这样做是安全的。

内存治理可以说是自动的，但是这并没有让程

序员脱离内存治理问题。比方说，对于内存的分配（还有释放）总是存在一定的开销，尽管这些开销对程序员来说是隐含的。一个程序假如创建了很多对象，那么它

就要比完成相同任务而创建了较少对象的程序执行的速度慢（假如其他的条件都相同）。

文章更多想说的，导致内存泄漏主要的原因是，

先前申请了内存空间而忘记了释放。假如程序中存在对无用对象的引用，那么这些对象就会驻留内存，消耗内存，因为无法让垃圾回收器验证这些对象是否不再需

要。正如我们前面看到的，假如存在对象的引用，这个对象就被定义为“活动的”，同时不会被释放。要确定对象所占内存将被回收，程序员就要务必确认该对象不

再会被使用。典型的做法就是把对象数据成员设为null或者从集合中移除该对象。注重，当局部变量不需要时，不需明显的设为null，因为一个方法执行完

毕时，这些引用会自动被清理。

从更高一个层次看，这就是所有存在内存管的语言对内存泄漏所考虑的事情，剩余的对象引用将不再会被使用。

典型的泄漏

既然我们知道了在java中确实会存在内存泄漏，那么就让我们看一些典型的泄漏，并找出他们发生的原因。

全局集合

在大型应用程序中存在各种各样的全局数据仓库是很普遍的，比如一个JNDI-tree或者一个session table。在这些情况下，注重力就被放在了治理数据仓库的大小上。当然是有一些适当的机制可以将仓库中的无用数据移除。

可以有很多不同的解决形式，其中最常用的是一种周期运行的清除作业。这个作业会验证仓库中的数据然后清除一切不需要的数据。

另一个办法是计算引用的数量。集合负责跟踪集合中每个元素的引用者数量。这要求引用者通知集合什么时候已经对元素处理完毕。当引用者的数目为零时，就可以移除集合中的相关元素。

高速缓存

高速缓存是一种用来快速查找已经执行过的操作结果的数据结构。因此，假如一个操作执行很慢的话，你可以先把普通输入的数据放入高速缓存，然后过些时间再调用高速缓存中的数据。

高速缓存多少还有一点动态实现的意思，当数据操作完毕，又被送入高速缓存。一个典型的算法如下所示：

1． 检查结果是否在高速缓存中，存在则返回结果；

2． 假如结果不在，那么计算结果；

3． 将结果放入高速缓存，以备将来的操作调用。

这个算法的问题（或者说潜在的内存泄漏）在最后一步。假如操作是分别多次输入，那么存入高速缓存的内容将会非常大。很明显这个方法不可取。

为了避免这种潜在的致命错误设计，程序就必须确定高速缓存在他所使用的内存中有一个上界。因此，更好的算法是：

1． 检查结果是否在高速缓存中，存在则返回结果；

2． 假如结果不在，那么计算结果；

3． 假如高速缓存所占空间过大，移除缓存中旧的结果；

4． 将结果放入高速缓存，以备将来的操作调用。

通过不断的从缓存中移除旧的结果，我们可以假设，将来，最新输入的数据可能被重用的几率要远远大于旧的结果。这通常是一个不错的设想。

这个新的算法会确保高速缓存的容量在预先确定的范围内。精确的范围是很难计算的，因为缓存中的对象存在引用时将继续有效。正确的划分高速缓存的大小是一个复杂的任务，你必须权衡可使用内存大小和数据快速存取之间的矛盾。

另一个解决这个问题的途径是使用java.lang.ref.SoftReference类来将对象放入高速缓存。这个方法可以保证当虚拟机用完内存或者需要更多堆的时候，可以释放这些对象的引用。

类装载器

　

　Java类装载器创建就存在很多导致内存泄漏的漏洞。由于类装载器的复杂结构，使得很难得到内存泄漏的透视图。这些困难不仅仅是由于类装载器只与“普通

的”对象引用有关，同时也和对象内部的引用有关，比如数据变量，方法和各种类。这意味着只要存在对数据变量，方法，各种类和对象的类装载器，那么类装载器

将驻留在JVM中。既然类装载器可以同很多的类关联，同时也可以和静态数据变量关联，那么相当多的内存就可能发生泄漏。

定位内存泄漏

　

　经常地，程序内存泄漏的最初迹象发生在出错之后，在你的程序中得到一个OutOfMemoryError。这种典型的情况发生在产品环境中，而在那里，

你希望内存泄漏尽可能的少，调试的可能性也达到最小。也许你的测试环境和产品的系统环境不尽相同，导致泄露的只会在产品中暴露。这种情况下，你需要一个低

负荷的工具来监听和寻找内存泄漏。同时，你还需要把这个工具同你的系统联系起来，而不需要重新启动他或者机械化你的代码。也许更重要的是，当你做分析的时

候，你需要能够同工具分离而使得系统不会受到干扰。

一个OutOfMemoryError经常是内存泄漏的一个标志，有可能应用

程序的确用了太多的内存；这个时候，你既不能增加JVM的堆的数量，也不能改变你的程序而使得他减少内存使用。但是，在大多数情况下，一个

OutOfMemoryError是内存泄漏的标志。一个解决办法就是继续监听GC的活动，看看随时间的流逝，内存使用量是否会增加，假如有，程序中一定

存在内存泄漏。

具体输出

有很多办法来监听垃圾回收器的活动。也许运用最广泛的就是以：-Xverbose:gc选项运行JVM，然后观察输出结果一段时间。

[memory] 10.109-10.235: GC 65536K-16788K (65536K), 126.000 ms

箭头后的值（在这个例子中 16788K）是垃圾回收后堆的使用量。

控制台

观察这些无尽的GC具体统计输出是一件非常单调乏味的事情。好在有一些工具来代替我们做这些事情。The JRockit Management Console可以用图形的方式输出堆的使用量。通过观察图像，我们可以很方便的观察堆的使用量是否伴随时间增长。

　

Figure 1. The JRockit Management Console

治理控制台甚至可以配置成在堆使用量出现问题（或者其他的事件发生）时向你发送邮件。这个显然使得监控内存泄漏更加轻易。

内存泄漏探测工具

　

　有很多专门的内存泄漏探测工具。其中The JRockit Memory Leak

Detector可以供来观察内存泄漏也可以针对性地找到泄漏的原因。这个强大的工具被紧密地集成在JRockit

JVM中，可以提供最低可能的内存事务也可以轻松的访问虚拟机的堆。

专门工具的优势

一旦

你知道程序中存在内存泄漏，你需要更专业的工具来查明为什么这里会有泄漏。而JVM是不可能告诉你的。现在有很多工具可以利用了。这些工具本质上主要通过

两种方法来得到JVM的存储系统信息的：JVMTI和字节码仪器。Java虚拟机工具接口（JVMTI）和他的原有形式JVMPI（压型接口，PRofiling Interface）都是标准接口，作为外部工具同JVM进行通信，搜集JVM的信息。字节码仪器则是引用通过探针获得工具所需的字节信息的预处理技术。

　

　通过这些技术来侦测内存泄漏存在两个缺点，而这使得他们在产品级环境中的运用不够理想。首先，根据两者对内存的使用量和内存事务性能的降级是不可以忽略

的。从JVM获得的堆的使用量信息需要在工具中导出，收集和处理。这意味着要分配内存。按照JVM的性能导出信息是需要开销的，垃圾回收器在搜集信息的时

候是运行的非常缓慢的。另一个缺点就是，这些工具所需要的信息是关系到JVM的。让工具在JVM开始运行的时候和它关联，而在分析的时候，分离工具而保持

JVM运行，这显然是不可能的。

既然JRockit Memory Leak

Detector是被集成到JVM中的，那么以上两种缺点就不再存在。首先，大部分的处理和分析都是在JVM中完成的，所以就不再需要传送或重建任何数

据。处理也可以建立在垃圾回收器的基础上，即提高速度。再有，内存泄漏侦测器可以同一个运行的JVM关联和分离，只要JVM在开始的时候伴随着

–Xmanagement选项（通过远程JMX接口答应监听和治理JVM）。当工具分离以后，工具不会遗留任何东西在JVM中；JVM就可以全速运行代码

就似乎工具关联之前一样。

关于java内存泄漏代码和java 内存泄漏排查工具的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。