内存泄漏java

⑴ 如何防止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中的内存泄漏

1、内存泄漏的现象：
常常地，程序内存泄漏的最初迹象发生在出错之后，在程序中得到一个OutOfMemoryError。这种典型的情况发生在产品环境中，而在那里，希望内存泄漏尽可能的少，调试的可能性也达到最小。也许测试环境和产品的系统环境不尽相同，导致泄露的只会在产品中暴露。这种情况下，需要一个低负荷的工具来监听和寻找内存泄漏。同时，还需要把这个工具同系统联系起来，而不需要重新启动他或者机械化代码。也许更重要的是，当做分析的时候，需要能够同工具分离而使得系统不会受到干扰。
一个OutOfMemoryError常常是内存泄漏的一个标志，有可能应用程序的确用了太多的内存；这个时候，既不能增加JVM的堆的数量，也不能改变程序而使得减少内存使用。但是，在大多数情况下，一个OutOfMemoryError是内存泄漏的标志。一个解决办法就是继续监听GC的活动，看看随时间的流逝，内存使用量是否会增加，如果有，程序中一定存在内存泄漏。
2. 发现内存泄漏
1. jstat -gc pid
可以显示gc的信息，查看gc的次数，及时间。
其中最后五项，分别是young gc的次数，young gc的时间，full gc的次数，full gc的时间，gc的总时间。
2.jstat -gccapacity pid
可以显示，VM内存中三代（young,old,perm）对象的使用和占用大小，
如：PGCMN显示的是最小perm的内存使用量，PGCMX显示的是perm的内存最大使用量，
PGC是当前新生成的perm内存占用量，PC是但前perm内存占用量。
其他的可以根据这个类推， OC是old内纯的占用量。
3.jstat -gcutil pid
统计gc信息统计。
4.jstat -gcnew pid
年轻代对象的信息。
5.jstat -gcnewcapacity pid
年轻代对象的信息及其占用量。
6.jstat -gcold pid
old代对象的信息。
7.stat -gcoldcapacity pid
old代对象的信息及其占用量。
8.jstat -gcpermcapacity pid
perm对象的信息及其占用量。
9.jstat -class pid
显示加载class的数量，及所占空间等信息。
10.jstat -compiler pid
显示VM实时编译的数量等信息。
11.stat -printcompilation pid
当前VM执行的信息。
一些术语的中文解释：
S0C：年轻代中第一个survivor（幸存区）的容量 (字节)
S1C：年轻代中第二个survivor（幸存区）的容量 (字节)
S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)
S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)
EC：年轻代中Eden（伊甸园）的容量 (字节)
EU：年轻代中Eden（伊甸园）目前已使用空间 (字节)
OC：Old代的容量 (字节)
OU：Old代目前已使用空间 (字节)
PC：Perm(持久代)的容量 (字节)
PU：Perm(持久代)目前已使用空间 (字节)
YGC：从应用程序启动到采样时年轻代中gc次数
YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)
FGC：从应用程序启动到采样时old代(全gc)gc次数
FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT：从应用程序启动到采样时gc用的总时间(s)
NGCMN：年轻代(young)中初始化(最小)的大小 (字节)
NGCMX：年轻代(young)的最大容量 (字节)
NGC：年轻代(young)中当前的容量 (字节)
OGCMN：old代中初始化(最小)的大小 (字节)
OGCMX：old代的最大容量 (字节)
OGC：old代当前新生成的容量 (字节)
PGCMN：perm代中初始化(最小)的大小 (字节)
PGCMX：perm代的最大容量 (字节)
PGC：perm代当前新生成的容量 (字节)
S0：年轻代中第一个survivor（幸存区）已使用的占当前容量百分比
S1：年轻代中第二个survivor（幸存区）已使用的占当前容量百分比
E：年轻代中Eden（伊甸园）已使用的占当前容量百分比
O：old代已使用的占当前容量百分比
P：perm代已使用的占当前容量百分比
S0CMX：年轻代中第一个survivor（幸存区）的最大容量 (字节)
S1CMX ：年轻代中第二个survivor（幸存区）的最大容量 (字节)
ECMX：年轻代中Eden（伊甸园）的最大容量 (字节)
DSS：当前需要survivor（幸存区）的容量 (字节)（Eden区已满）
TT：持有次数限制
MTT ：最大持有次数限制

⑶ 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<Person> set = new HashSet<Person>();
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 是否提供相应的操作去除引用。
6、单例模式
不正确使用单例模式是引起内存泄露的一个常见问题，单例对象在被初始化后将在JVM的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露，考虑下面的例子：
class A{
public A(){
B.getInstance().setA(this);
}
....
}
//B类采用单例模式
class B{
private A a;
private static B instance=new B();
public B(){}
public static B getInstance(){
return instance;
}
public void setA(A a){
this.a=a;
}
//getter...
}
显然B采用singleton模式，它持有一个A对象的引用，而这个A类的对象将不能被回收。想象下如果A是个比较复杂的对象或者集合类型会发生什么情况

⑷ java内存泄露是什么意思

Java内存泄露
一般来说内存泄漏有两种情况。一种情况如在C/C++语言中的，在堆中的分配的内存，在没有将其释放掉的时候，就将所有能访问这块内存的方式都删掉（如指针重新赋值）；另一种情况则是在内存对象明明已经不需要的时候，还仍然保留着这块内存和它的访问方式（引用）。第一种情况，在Java中已经由于垃圾回收机制的引入，得到了很好的解决。所以，Java中的内存泄漏，主要指的是第二种情况。
可能光说概念太抽象了，大家可以看一下这样的例子：
1 Vector v=new Vector(10);
2 for (int i=1;i<100; i++){
3 Object o=new Object();
4 v.add(o);
5 o=null;
6 }
在这个例子中，代码栈中存在Vector对象的引用v和Object对象的引用o。在For循环中，不断的生成新的对象，然后将其添加到Vector对象中，之后将o引用置空。问题是当o引用被置空后，如果发生GC，创建的Object对象是否能够被GC回收呢？答案是否定的。因为，GC在跟踪代码栈中的引用时，会发现v引用，而继续往下跟踪，就会发现v引用指向的内存空间中又存在指向Object对象的引用。也就是说尽管o引用已经被置空，但是Object对象仍然存在其他的引用，是可以被访问到的，所以GC无法将其释放掉。如果在此循环之后，Object对象对程序已经没有任何作用，那么就认为此Java程序发生了内存泄漏。
尽管对于C/C++中的内存泄露情况来说，Java内存泄露导致的破坏性小，除了少数情况会出现程序崩溃的情况外，大多数情况下程序仍然能正常运行。但是，在移动设备对于内存和CPU都有较严格的限制的情况下，Java的内存溢出会导致程序效率低下、占用大量不需要的内存等问题。这将导致整个机器性能变差，严重的也会引起抛出OutOfMemoryError，导致程序崩溃。
一般情况下内存泄漏的避免
在不涉及复杂数据结构的一般情况下，Java的内存泄露表现为一个内存对象的生命周期超出了程序需要它的时间长度。有时也将其称为“对象游离”。
例如：
1 public class FileSearch{
2
3 private byte[] content;
4 private File mFile;
5
6 public FileSearch(File file){
7 mFile = file;
8 }
9
10 public boolean hasString(String str){
11 int size = getFileSize(mFile);
12 content = new byte[size];
13 loadFile(mFile, content);
14
15 String s = new String(content);
16 return s.contains(str);
17 }
18 }
在这段代码中，FileSearch类中有一个函数hasString，用来判断文档中是否含有指定的字符串。流程是先将mFile加载到内存中，然后进行判断。但是，这里的问题是，将content声明为了实例变量，而不是本地变量。于是，在此函数返回之后，内存中仍然存在整个文件的数据。而很明显，这些数据后续是不再需要的，这就造成了内存的无故浪费。
要避免这种情况下的内存泄露，要求以C/C++的内存管理思维来管理自己分配的内存。第一，是在声明对象引用之前，明确内存对象的有效作用域。在一个函数内有效的内存对象，应该声明为local变量，与类实例生命周期相同的要声明为实例变量……以此类推。第二，在内存对象不再需要时，记得手动将其引用置空。
复杂数据结构中的内存泄露问题
在实际的项目中，经常用到一些较为复杂的数据结构用于缓存程序运行过程中需要的数据信息。有时，由于数据结构过于复杂，或者存在一些特殊的需求（例如，在内存允许的情况下，尽可能多的缓存信息来提高程序的运行速度等情况），很难对数据结构中数据的生命周期作出明确的界定。这个时候，可以使用Java中一种特殊的机制来达到防止内存泄露的目的。
之前介绍过，Java的GC机制是建立在跟踪内存的引用机制上的。而在此之前，所使用的引用都只是定义一个“Object o;”这样形式的。事实上，这只是Java引用机制中的一种默认情况，除此之外，还有其他的一些引用方式。通过使用这些特殊的引用机制，配合GC机制，就可以达到一些需要的效果。

⑸ java常见内存泄漏原因

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

⑹ java在什么情况下会出现内存泄露

内存泄露就是指一个不再被程序使用的对象或变量一直被占据在内存中。java中的内存泄露的情况：
1.长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，例如，缓存系统，我们加载了一个对象放在缓存中(例如放在一个全局map对象中)，然后一直不再使用它，这个对象一直被缓存引用，但却不再被使用。
2.集合类，而如果集合类是全局性的变量（比如类中的静态属性，全局性的map等即有静态引用或final一直指向它），那么没有相应的删除机制，很可能导致集合所占用的内存只增不减，因此提供这样的删除机制或者定期清除策略非常必要。
3.单例模式。不正确使用单例模式是引起内存泄露的一个常见问题，单例对象在被初始化后将在JVM的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露

⑺ java的内存泄露是错误还是异常

java中内存泄漏有两种情况。

一是在堆中的分配的内存，在没有将其释放掉的时候，就将所有能访问这块内存的方式都删掉；另一种情况则是在内存对象明明已经不需要的时候，还仍然保留着这块内存和它的访问方式（引用）。在Java中已经由于垃圾回收机制的引入，第一种情况得到了很好的解决。所以，Java中的内存泄漏，主要指的是第二种情况。

Java的内存泄漏会导致程序效率低下、占用大量不需要的内存等问题。这将导致整个机器性能变差，内存泄露不是错误也不是异常，但是严重的话也会引起抛出OutOfMemoryError，导致程序崩溃。