Java中那些内存泄漏的场景!
虽然Java程序员不用像C/C++程序员那样时刻关注内存的使用情况,JVM会帮我们处理好这些,但并不是说有了GC就可以高枕无忧,内存泄露相关的问题一般在测试的时候很难发现,一旦上线流量起来可能马上就是一个诡异的线上故障。
内存泄露定义
如果GC无法回收内存中不再使用的对象,则定义为内存有泄露。
1. 未关闭的资源类
当我们在程序中打开一个新的流或者是新建一个网络连接的时候,JVM都会为这些资源类分配内存做缓存,常见的资源类有网络连接,数据库连接以及IO流。值得注意的是,如果在业务处理中异常,则有可能导致程序不能执行关闭资源类的代码,因此最好按照下面的做法处理资源类
public void handleResource() {try {// open connection// handle business} catch (Throwable t) {// log stack} finally {// close connection}
}
2. 未正确实现equals()
和hashCode()
假如有下面的这个类
public class Person {public String name;public Person(String name) {this.name = name;}
}
并且如果在程序中有下面的操作
@Test
public void givenMapWhenEqualsAndHashCodeNotOverriddenThenMemoryLeak() {Map<Person, Integer> map = new HashMap<>();for(int i=0; i<100; i++) {map.put(new Person("jon"), 1);}Assert.assertFalse(map.size() == 1);
}
可以预见,这个单元测试并不能通过,原因是Person
类没有实现equals
方法,因此使用Object
的equals
方法,直接比较实体对象的地址,所以map.size() == 100
如果我们改写Person
类的代码如下所示:
public class Person {public String name;public Person(String name) {this.name = name;}@Overridepublic boolean equals(Object o) {if (o == this) return true;if (!(o instanceof Person)) {return false;}Person person = (Person) o;return person.name.equals(name);}@Overridepublic int hashCode() {int result = 17;result = 31 * result + name.hashCode();return result;}
}
则上文中的单元测试就可以顺利通过了,需要注意的是这个场景比较隐蔽,一定要在平时的代码中注意。
3. 非静态内部类
要知道,所有的非静态类别类都持有外部类的引用,因此某些情况如果引用内部类可能延长外部类的生命周期,甚至持续到进程结束都不能回收外部类的空间,这类内存溢出一般在Android程序中比较多,只要MyAsyncTask
处于运行状态MainActivity
的内存就释放不了,很多时候安卓开发者这样做只是为了在内部类中拿到外部类的属性,殊不知,此时内存已经泄露了。
public class MainActivity extends Activity {@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.main);new MyAsyncTask().execute();}private class MyAsyncTask extends AsyncTask {@Overrideprotected Object doInBackground(Object[] params) {return doSomeStuff();}private Object doSomeStuff() {//do something to get resultreturn new MyObject();}}
}
4. 重写了finalize()
的类
如果运行下面的这个例子,则最终程序会因为OOM的原因崩溃
public class Finalizer {@Overrideprotected void finalize() throws Throwable {while (true) {Thread.yield();}}public static void main(String str[]) {while (true) {for (int i = 0; i < 100000; i++) {Finalizer force = new Finalizer();}}}
}
JVM对重写了finalize()
的类的处理稍微不同,首先会针对这个类创建一个java.lang.ref.Finalizer
类,并让java.lang.ref.Finalizer
持有这个类的引用,在上文中的例子中,因为Finalizer
类的引用被java.lang.ref.Finalizer
持有,所以他的实例并不能被Young GC清理,反而会转入到老年代。在老年代中,JVM GC的时候会发现Finalizer
类只被java.lang.ref.Finalizer
引用,因此将其标记为可GC状态,并放入到java.lang.ref.Finalizer.ReferenceQueue
这个队列中。等到所有的Finalizer类都加到队列之后,JVM会起一个后台线程去清理java.lang.ref.Finalizer.ReferenceQueue
中的对象,之后这个后台线程就专门负责清理java.lang.ref.Finalizer.ReferenceQueue
中的对象了。这个设计看起来是没什么问题的,但其实有个坑,那就是负责清理java.lang.ref.Finalizer.ReferenceQueue
的后台线程优先级是比较低的,并且系统没有提供可以调节这个线程优先级的接口或者配置。因此当我们在使用使用重写finalize()
方法的对象时,千万不要瞬间产生大量的对象,要时刻谨记,JVM对此类对象的处理有特殊逻辑。
5. 针对长字符串调用String.intern()
如果提前在src/test/resources/large.txt
中写入大量字符串,并且在Java 1.6及以下的版本运行下面程序,也将得到一个OOM
@Test
public void givenLengthString_whenIntern_thenOutOfMemory()throws IOException, InterruptedException {String str = new Scanner(new File("src/test/resources/large.txt"), "UTF-8").useDelimiter("\\A").next();str.intern();System.gc(); Thread.sleep(15000);
}
原因是在Java 1.6及以下,字符串常量池是处于JVM的PermGen
区的,并且在程序运行期间不会GC,因此产生了OOM。在Java 1.7以及之后字符串常量池转移到了HeapSpace
此类问题也就无需再关注了
6. ThreadLocal
的误用
ThreadLocal一定要列在Java内存泄露的榜首,总能在不知不觉中将内存泄露掉,一个常见的例子是:
@Test
public void testThreadLocalMemoryLeaks() {ThreadLocal<List<Integer>> localCache = new ThreadLocal<>();List<Integer> cacheInstance = new ArrayList<>(10000);localCache.set(cacheInstance);localCache = new ThreadLocal<>();
}
当localCache
的值被重置之后cacheInstance
被ThreadLocalMap
中的value
引用,无法被GC,但是其key
对ThreadLocal
实例的引用是一个弱引用,本来ThreadLocal
的实例被localCache
和ThreadLocalMap
的key
同时引用,但是当localCache
的引用被重置之后,则ThreadLocal
的实例只有ThreadLocalMap
的key
这样一个弱引用了,此时这个实例在GC的时候能够被清理。
其实看过ThreadLocal
源码的同学会知道,ThreadLocal
本身对于key
为null
的Entity
有自清理的过程,但是这个过程是依赖于后续对ThreadLocal
的继续使用,假如上面的这段代码是处于一个秒杀场景下,会有一个瞬间的流量峰值,这个流量峰值也会将集群的内存打到高位(或者运气不好的话直接将集群内存打满导致故障),后面由于峰值流量已过,对ThreadLocal
的调用也下降,会使得ThreadLocal
的自清理能力下降,造成内存泄露。ThreadLocal
的自清理实现是锦上添花,千万不要指望它雪中送碳。
7. 类的静态变量
Tomcat对在网络容器中使用ThreadLocal引起的内存泄露做了一个总结,详见:https://cwiki.apache.org/confluence/display/tomcat/MemoryLeakProtection,这里我们列举其中的一个例子。
熟悉Tomcat
的同学知道,Tomcat中的web应用由webapp classloader
这个类加载器的,并且webapp classloader
是破坏双亲委派机制实现的,即所有的web应用先由webapp classloader
加载,这样的好处就是可以让同一个容器中的web应用以及依赖隔离。
下面我们看具体的内存泄露的例子:
public class MyCounter {private int count = 0;public void increment() {count++;}public int getCount() {return count;}
}public class MyThreadLocal extends ThreadLocal<MyCounter> {
}public class LeakingServlet extends HttpServlet {private static MyThreadLocal myThreadLocal = new MyThreadLocal();protected void doGet(HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException {MyCounter counter = myThreadLocal.get();if (counter == null) {counter = new MyCounter();myThreadLocal.set(counter);}response.getWriter().println("The current thread served this servlet " + counter.getCount()+ " times");counter.increment();}
}
需要注意这个例子中的两个非常关键的点:
MyCounter
以及MyThreadLocal
必须放到web应用的路径中,保被webapp classloader
加载ThreadLocal类一定得是ThreadLocal的继承类,比如例子中的MyThreadLocal,因为ThreadLocal本来被
common classloader
加载,其生命周期与tomcat容器一致。ThreadLocal的继承类包括比较常见的NamedThreadLocal
,注意不要踩坑。
假如LeakingServlet
所在的web应用启动,MyThreadLocal
类也会被webapp classloader
加载,如果此时web应用下线,而线程的生命周期未结束(比如为LeakingServlet
提供服务的线程是一个线程池中的线程),那会导致myThreadLocal
的实例仍然被这个线程引用,而不能被GC,期初看来这个带来的问题也不大,因为myThreadLocal
所引用的对象占用的内存空间不太多,问题在于myThreadLocal
间接持有加载web应用的webapp classloader
的引用(通过myThreadLocal.getClass().getClassLoader()
可以引用到),而加载web应用的webapp classloader
有持有它加载的所有类的引用,这就引起了classloader
泄露,它泄露的内存就非常可观了。
参考文献:
https://www.baeldung.com/java-memory-leaks
https://cwiki.apache.org/confluence/display/tomcat/MemoryLeakProtection
-END-
ThreadLocal不好用?那是你没用对!
额!Java中用户线程和守护线程区别这么大?
Semaphore自白:限流器用我就对了!
Java中那些内存泄漏的场景!相关推荐
- Java中关于内存泄漏分析和解决方案,都在这里了!
作者:李序锴 www.jianshu.com/p/54b5da7c6816 最近正在熟悉Java内存泄漏的相关知识,上网查阅了一些资料,在此做个整理算是对收获的一些总结,希望能对各位有所帮助,有问题可 ...
- Java中关于内存泄漏出现的原因以及如何避免内存泄漏
转账自:http://blog.csdn.net/wtt945482445/article/details/52483944 Java 内存分配策略 Java 程序运行时的内存分配策略有三种,分别是静 ...
- (转载)Java中关于内存泄漏出现的原因以及如何避免内存泄漏
原文链接 Android 内存泄漏总结 内存管理的目的就是让我们在开发中怎么有效的避免我们的应用出现内存泄漏的问题.内存泄漏大家都不陌生了,简单粗俗的讲,就是该被释放的对象没有释放,一直被某个或某些实 ...
- 深入理解Java中的内存泄漏
理解Java中的内存泄漏,我们首先要清楚Java中的内存区域分配问题和内存回收的问题本文将分为三大部分介绍这些内容. Java中的内存分配 Java中的内存区域主要分为线程共享的和线程私有的两大区域: ...
- 介绍Java中的内存泄漏
转载自 介绍Java中的内存泄漏 Java语言的一个关键的优势就是它的内存管理机制.你只管创建对象,Java的垃圾回收器帮你分配以及回收内存.然而,实际的情况并没有那么简单,因为内存泄漏在Java应 ...
- 了解Java中的内存泄漏
来源:SpringForAll社区 1. 简介 Java的核心优势之一是在内置垃圾收集器(简称GC)的帮助下实现自动内存管理.GC隐含地负责分配和释放内存,因此能够处理大多数内存泄漏问题. 虽然GC有 ...
- java中的内存泄漏
● 请问java中内存泄漏是什么意思?什么场景下会出现内存泄漏的情况? 考察点:内存泄漏 参考回答: Java中的内存泄露,广义并通俗的说,就是:不再会被使用的对象的内存不能被回收,就是内存泄露.如果 ...
- 翻译 | 理解Java中的内存泄漏
猪年第一篇译文,大家多多支持! 原文自工程师baeldung博客,传送门 1. 介绍 Java 的其中一个核心特点是经由内置的垃圾回收机制(GC)下的自动化内存管理.GC 默默地处理着内存分配和释放工 ...
- Java 中发生内存泄漏 5 个场景以及解决方法
前言 说到垃圾回收(Garbage Collection,GC),很多人就会自然而然地把它和 Java 联系起来.在 Java 中,程序员不需要去关心内存动态分配和垃圾回收的问题,这一切都交给了JVM ...
最新文章
- 关于一次性能调优的反思
- Android 应用 之路 百度地图API使用(3)
- 深入理解linux系统下proc文件系统内容
- LeetCode 1521. 找到最接近目标值的函数值(位运算)
- Smack 4.3.2 发布,XMPP(jabber) 的 Java 客户端类库
- MySQL错误:The user specified as a definer (XXX@XXX) does not exist
- primefaces_Primefaces主题
- 客户端中转request请求乱码
- 美国专家声讨物联网安全 面对攻击如纸糊
- python 列表转字典的一些方法
- (1)、win10 本地 安装 rabbitmq
- 技术杂谈-再谈软硬SDN(1)
- 群接龙小程序定制开发
- JUC基础(一): 什么是JUC(JUC概述)
- python画图软件是哪个_Python实现画图软件功能方法详解
- 一条命令导出电脑中所有wifi账号密码
- 钱包的下一站:无私钥、不用再抄助记词
- 覆盖率选项,覆盖率分析
- 中国大学MOOC第五章测试题答案
- Google Guava Cache高效本地缓存
热门文章
- linux java jar打包_【Java】Java程序打包成jar包在Linux上运行
- androidstudio build tools安装_Android Studio4.0 安装及配置
- Redis 核心技术与实战
- nginx proxy_cache缓存详解
- JDK源码解析之 Java.lang.StringBuilder
- DIY 主机 所有AMD IntelCPU及主板
- 洛谷P2622 关灯问题II【状压dp+bfs】
- 【Spark】开发Spark选择Java还是Scala?
- 【分享】linux下u盘使用
- 日记 2014-5-18