-
内存洩漏与内存溢出
-
两者的差别
-
内存洩漏 : 就是Memory Leak,是指程序在申请内存后,无法释放已申请的内存空间,也就是无用的对象持续佔有内存,得不到释放,从而造成内存空间的浪费
-
内存溢出 : 就是Out Of Memory,是指程序在申请内存时,没有足够的内存空间供其使用
-
-
其实内存洩漏和内存溢出之间没有多大的关係,就算你不内存洩漏,你仍有可能因为载入过大的档案到内存、或是
new
太大的对象,而导致内存溢出-
但是如果内存洩漏太多,会导致可用内存越来越小,间接容易引发内存溢出,一次内存存洩漏的危害可以忽略,但是内存洩漏堆积的后果会严重,无论多少内存,迟早会被佔光,因此确保程序不会内存洩漏是非常重要的
-
也就是说,内存洩漏 最终会导致 内存溢出,但是引起内存溢出的原因有很多种,内存洩漏只是其中的一种
-
-
-
Java中的内存洩漏
-
在C++中,程序员要自己使用
new
和delete
去申请和释放内存,因此C++中的内存洩漏,大部分都是由于程序员傻才导致的 -
而Java虽然是交由jvm去统一回收对象,但是Java仍然有可能发生内存洩漏的
-
再强调一遍,内存洩漏是指无用对象(不再使用的对象)持续佔有内存、或无用对象得不到即时释放,从而造成的内存空间的浪费
-
在Java中,当长生命週期的对象持有短生命週期对象的引用时,就会发生Java版的内存洩漏
-
也就是说,儘管短生命週期的对象已经不再需要了,但是因为长生命週期对象持有他的引用,因此导致这个短生命週期对象无法被回收,这样的状况,就是Java内存洩漏了
-
-
Java中的内存洩漏,其更明确的定义是 : objects are no longer being used by the application, but the Garbage Collector is unable to remove them from working memory
-
-
-
Java跟C++对内存洩漏的意义上的不同
-
C++是你把指针丢失了之后,才称为内存洩漏(因为你再也找不到这块内存的地址了,所以释放不了)
-
而Java是只要这个短生命週期的对象明明已经没用到了,但是一直被閒杂人等拿著,导致没被GC回收掉,这样就算是内存洩漏
-
-
-
常见的内存洩漏
-
全局集合
-
如果只是方法内的局部集合还好,因为局部变量会随著方法执行结束而销毁,但是如果是
static
的集合,那麽就很容易会产生内存洩漏-
以下代码假设list是一个全局的集合,当运行到
Object o = new Object()
时,o引用指向了某块内存地址 -
当运行到
list.add(o)
时,list引用也去指向o引用所指向的那块内存地址,因此此时有两个人同时在指向这个地址,分别是 o引用,和 list引用 -
当运行完
o = null
时,表示o引用不去指向这块内存地址了,改去指向null,但此时仍有 list引用还指向著这块地址 -
所以当一个引用被加入到集合类中时,除非这个集合类也被销毁了,或是说list主动
remove()
掉这个引用,否则就算把o设为null不想用他了,也还是会有这个集合类的引用在指向这个内存地址,造成内存洩漏
public class Main { public static void main(String[] args) { List<Object> list = new ArrayList<>(); Object o = new Object(); list.add(o); o = null; //此时o原本指向的那块内存地址的对象,仍然被list所引用著,发生内存洩漏 } }
-
-
-
Java 1.7以前的
substring()
方法-
在Java1.7以前,
substring()
方法会去共享同一个value[],也就是 s 和 sub 会共同指向同一个value[]数组,而这样就有可能会造成内存洩漏-
因为s对象已经不会被用到了,所以GC会想要回收他,但是却会发现value[]被sub给引用著,导致回收不了这个value[],发生内存洩漏
-
这也是一个长生命週期的对象持有短生命週期对象的引用的场景,value[]理论上早没用了(生命週期短),但是却老被sub(生命週期长)扣著不让走,才发生了内存洩漏
String s = ".....very long string..."; String sub = s.substring(2, 10);
-
-
-
ThreadLocal类
-
在Java裡,每个线程都有自己的ThreadLocalMap,裡面存著这个线程自己私有的ThreadLocal们,而ThreadLocalMap的key为ThreadLocal实例,value为私有对象T,即是透过
set()
设置的值public class Thread implements Runnable { //Thread类裡的threadlocals存放此线程的专有的ThreadLocalMap ThreadLocal.ThreadLocalMap threadLocals = null; }
public class ThreadLocal<T> { //根据线程,取得那个线程自己的ThreadLocalMap ThreadLocalMap getMap(Thread t) { return t.threadLocals; } static class ThreadLocalMap { //ThreadLocalMap的key是使用 "弱引用" 的ThreadLocal static class Entry extends WeakReference<ThreadLocal> { Object value; //ThreadLocalMap中的key就是ThreadLocal,value就是设置的值 Entry(ThreadLocal k, Object v) { super(k); value = v; } } } }
-
之所以ThreadLocal会发生内存洩漏,原因是因为只要线程活著,这个线程的ThreadLocalMap就会一直活著,而当初透过ThreadLocal
set()
的值,也就会在ThreadLocalMap中一直存在这个键值对不消失,所以该ThreadLocal和该value的内存地址始终都有这个ThreadLocalMap在引用著,导致GC无法回收他,所以才会发生内存洩漏-
为了解决这个问题,java做了一个小优化,也就是存放在ThreadLocalMap中的ThreadLocal,会使用 弱引用 来储存,也就是说,如果一个ThreadLocal内存地址没有外部强引用来引用他,只有这条ThreadLocalMap的弱引用来引用他时,那麽当系统GC时,这些ThreadLocal就会被回收(因为是弱引用),如此一来,ThreadLocalMap中就会出现key为null的Entry们
-
下图中,实线表示强引用,虚线表示弱引用
-
-
-
这个弱引用优化只能使得ThreadLocal被正确回收,但是这些key为null的Entry们仍然会存在在ThreadLocalMap裡,因此value仍然无法被回收
-
所以java又做了一个优化,就是在ThreadLocal执行
get()
、set()
、remove()
方法时,都会将该线程ThreadLocalMap裡所有key=null的value也设置为null,手动帮助GC
ThreadLocal k = e.get(); if (k == null) { e.value = null; // Help the GC }
-
-
-
但是根本上的解决办法,还是在当前线程使用完这个ThreadLocal时,就即时的
remove()
掉该value,也就是使得ThreadLocalMap中不要存在这个键值对,这样才能确保GC能正确回收
-
-