- 浏览: 414937 次
- 性别:
- 来自: 深圳
文章分类
最新评论
-
Glogo:
楼主您好,我在试验您的代码的时候发现新开的三个子线程并没有一直 ...
java 高并发 ReentrantLock -- 可重入的锁 -
univasity:
最近发觉也被限速了,投诉一下就好一会~~ 看来明天又要和电信M ...
ADSL上网速度慢 都是帐号限速惹的祸 -
liuyuanhui0301:
java 高并发 ReentrantLock -- 可重入的锁 -
dang_java:
呵.很好的说明文档.
JXTA技术与应用发展 -
helloqidi:
谢谢,学习了
SQL中exists和in的区别
The first act of this blog-series Java OutOfMemoryError – A tragedy in seven acts described the architecture of JVM memory and discussed where a java.lang.OutOfMemoryError could occur.
So let’s have a detailed look on how this error can actually happen in a Java application.
In the previous post, we saw multiple possible types of the OutOfMemoryError. But the one happening most of the time is this one:
Exception in thread "main": java.lang.OutOfMemoryError: Java heap space
The error indicates that there has not been enough free heap to fulfill an allocation request for a new object. In other words: there is no room for the object on the heap. Since, according to the JVM specification, every heap has to have a garbage collector, this also means that no memory was freeable by it. So the whole memory is filled with “live” objects.
To understand how this can happen, it is important to understand what a “live” object actually is.
In Java objects get generated on the heap and live on as long as they are referenced. The garbage collector checks during it GC-phases if the object is still referenced – and does mark it as “garbage” and clean it up later when this is no longer the case (the actual behaviour differs for different gc-algorithms, like the Copying Collectors or Garbage-First, but is not of importance for understanding liveness). But not every reference is important for surviving, but only so called GC root references. Especially when understanding Memory Leaks, GC roots are a central concept to identify the important references to an object. Garbage Collector Roots are special objects which do not have incoming references and are responsible for keeping referenced objects alive. When an object cannot be reached directly or indirectly from a GC root, it will be marked as “unreachable” and made eligible for garbage collection. Simply speaking, there are three kinds of GC roots:
• Temporary variables on the stack of a thread
• Static members of a loaded class
• Special native references from JNI
Here an example which shows where GC Roots play a role for a class:
public class MyFrame extends javax.swing.JFrame { // reachable via Classloader as soon class is loaded public static final ArrayList STATIC = new ArrayList(); // as long as the JFrame is not dispose()'d, // it is reachable via a native window private final ArrayList jni = new ArrayList() // while this method is executing parameter is kept reachable, // even if it is not used private void myMethod(ArrayList parameter) { // while this method is running, this list is reachable from the stack ArrayList local = new ArrayList(); } }
Usually there are tree types of issues with Java OutOfMemoryError problems in heap memory:
- Objects, which can be reached via a GC root reference, but are actually no longer used by application code. Those are called Java Memory Leaks.
- Too many or too large objects. So there is not enough heap available for the application to execute. Usually happens when there are large objects kept in cache like structures.
- Too many temporary objects. So there is just for a short time not enough memory. Usually happens in load scenarios where many temporary objects are used.
Java Memory Leaks
So Java Memory Leaks occur when objects still have a GC root reference, but are not actually used anymore. Those “Loitering Objects” stay around for the whole life of the JVM. If the application is creating those “dead objects” on and on, the memory will be filled up and eventually result in a java.lang.OutOfMemoryError. Typical causes are static collections, which are used as a kind of cache. Usually objects are added, but never removed (Let’s face it: How often have you used add() and put() and how often used remove() methods?). Because the objects are referenced by the static collection, they cannot be freed up anymore, as the collection has a GC root reference via the classloader.
When discussing Memory Leaks one comes usually across the terms dominator or dominator tree. The dominator concept comes from graph theory and defines a node as dominator of another node when this node can only be reached via it. Applying this to memory management, object A is dominator for object B when there is no object C which holds a reference to B. A dominator tree is a partial tree in which this condition holds true for all nodes from the root node. When the root reference is freed, the whole dominator tree is freed as well. Large dominator trees are great candidates when looking for memory leaks.
Depending on the creation frequency and the object size, as well as the size of the Java heap, the OutOfMemoryError occurs sooner or later. Especially those “creeping memory leaks” can be found in many applications, but are usually “ignored” by:
- Using large heaps to delay the error. Happens frequently nowadays, as the old 32bit memory limit has vanished through the usage of 64 bit JVMs.
- Restarting the application server during the night. This “resets” the memory usage. If the memory leak takes longer than 24 hours to become severe, this will help.
But both variants are dangerous, as they have negative impact on the system performance and are heavily influenced by the system usage. A change in usage or more “traffic” can produce the error faster than expected. Garbage collection times also have a negative effect on the application performance, as the increasing “tenured generation” causes longer “Mark”-Phases during garbage collection, resulting in longer pause times, which can be observed as system hangs. Act 3 and 4 will describe analysis of those leaks in details and give advice on how to avoid them.
Too much memory
Besides Java memory leaks, there are is another reason for OutOfMemoryError: The application is just consuming too much memory. Either there is not enough heap configured and it has to be increased (also see part 3 of the series) or the consumption has to be throtteled, e.g. by shrinking cache sizes.
Especially critical is high temporary memory usage in enterprise applications, which can have a high number of concurrent users. Because it can happen out of the blue, this OutOfMemoryError is especially troublesome, as it cannot be countered with a nightly reboot. The following code illustrates the problem:
byte[] image = getTheByteImage(); response.setContentType("image/jpeg"); ServletOutputStream out = response.getOutputStream(); out.write(image); out.flush(); out.close();
While it is not that obvious, the code consumes memory on heap for each image before sending it to the browser. A much better variant would be to stream the image like this:
InputStream image = getTheImageAsStream(); response.setContentType("image/jpeg"); ServletOutputStream out = response.getOutputStream(); IOUtils.copy(image, out); out.flush(); out.close();
(Of course BufferedStreams and IOUtils use byte[] internally as well, but this is much smaller)
Having covered only the java.lang.OutOfMemoryError problems in heap, I might dedicate another post to other areas, like the permanent generation as mentioned in the previous episode.
The next episode will be “Confguring and Monitoring the Java Virtual Machine”, which will show how to configure and optimize the Sun JVM and how to monitor it with the bundled tools.
“Creating and understanding Java Heapdumps“ will then be the fourth episode and describe how to handle Heapdumps. We will find out how to discover the causes of the Memory Leaks described here.
Also those two are going to be more practical oriented, so you can expect some screencasts.
发表评论
-
JVM 深入笔记
2012-04-12 20:36 910JVM 深入笔记(1)内存区域是如何划分的? 一个超短的前言 ... -
JVM启动参数
2011-06-10 16:27 935java [jvmargs] class [arguments ... -
JVM指令集 和 一个异常例子
2011-05-19 16:14 983指令码 助记符 说明 0x00 nop ... -
The Top Java Memory Problems – Part 1
2011-05-18 11:01 867转载:http://blog.dynatrace.com/20 ... -
BTrace使用简介
2011-04-19 13:51 753该文转载自:http://rdc.taobao.com/tea ... -
大方法的执行性能与调优过程小记
2011-04-18 16:20 764该文章转载自:http://rdc.taobao.com/te ... -
十个最好的Java性能故障排除工具
2011-04-18 16:02 888推荐十个最好的Java性能 ... -
两个OOM Cases排查过程的分享
2011-04-18 15:39 897分享一下两个OOM Cases的查找过程,一个应用是Nativ ... -
Monitoring Java garbage collection with jstat
2011-04-18 15:28 832The original article is at : ht ... -
理解Heap Profling名词-Shallow和Retained Sizes
2011-04-18 14:58 941所有包含Heap Profling功能的工具(MAT, You ... -
Java深度历险(四)——Java垃圾回收机制与引用类型
2011-04-01 08:18 928Java语言的一个重要特性 ... -
Thread Dump 和Java应用诊断
2011-03-30 08:08 1099Thread Dump 和Java应用诊断 ... -
Memory Analysis Part 1 – Obtaining a Java Heapdump
2011-03-14 16:06 1088For troubleshooting Java memory ... -
Erlang memory architecture vs Java memory architecture
2011-03-14 15:36 881I read a really, really interes ... -
The Java Memory Architecture (1. Act)
2011-03-14 15:15 1387One of the biggest strength of ... -
Permanent generation
2011-03-14 14:53 1200版权声明:转载时请以 ... -
JVM内存模型以及垃圾回收
2011-03-13 09:38 912内存由 Perm 和 Heap 组成. 其中 Heap ... -
Java虚拟机垃圾回收机制
2011-03-13 09:31 770一、相关概念 基本 ... -
JVM结构
2011-03-10 14:43 862类文件格式 JVM使用一 ... -
OOM与JVM(转)
2009-03-24 15:49 897OOM与JVM(转) 2008年08月08日 星期五 15: ...
相关推荐
Java memory leaks Java memory leaks Java memory leaks
此文档描述了Detected memory leaks内存泄漏的简单检测方法,通过调用系统函数,在debug模式下运行,可以很快定位出内存泄漏之处;注:此方法并不能适用所有Detected memory leaks情况
一个测试Java内存泄漏的工具,党万春,钱巨,虽然Java语言有自带的垃圾回收机制,Java程序仍然存在由无效引用带来的内存泄漏。而内存泄漏会导致内存耗尽、程序崩溃等严重问题。�
The Eclipse Memory Analyzer is a fast and feature-rich Java heap analyzer that helps you find memory leaks and reduce memory consumption. Use the Memory Analyzer to analyze productive heap dumps with ...
The Eclipse Memory Analyzer is a fast and feature-rich Java heap analyzer that helps you find memory leaks and reduce memory consumption. Use the Memory Analyzer to analyze productive heap dumps with...
详细的深度学习成员推断攻击代码,有环境的可以直接运行。详细的成员推断攻击代码,有环境的可以直接运行。
平常我们都会用 Instrument 的 Leaks / Allocations 或其他一些开源库进行内存泄露的排查,但是检查过程非常繁琐,而且不清晰,最主要的是Abandoned memory不会被检测出来。 Leaks 从苹果的开发者文档里可以看到,一...
4.3.3 Detecting Memory Leaks . . . . . . . 38 4.4 Example 2: Broken Calls to Memory Allocation/Deallocation . . 38 4.5 Combining Memory and Source Code Debuggers . . . . . . 40 4.6 Cutting Down the ...
Finding memory leaks发现内存的泄漏(6KB)
How catch memory leaks with very little effort (7KB)
Finding memory leaks发现内存的泄漏(6KB)
1.4 Processors Read and Interpret Instructions Stored in Memory . . . . . . . . . . . . . . . . . 5 1.4.1 HardwareOrganization of aSystem . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4.2 ...
该资料介绍了如何检测,避免symbian编程中的内存泄漏的方法
使用__wrap_malloc查找malloc导致内存泄漏问题 memory leak 内存泄漏
Module for detecing heap (memory) leaks.
You will begin with a basic understanding of memory management, and why memory leaks occur in an application, moving on to autorelease pools and object creation/storage to get an idea of how memory ...
It's a very effective way to quickly diagnose, and fix, memory leaks in C/C++ applications. The main difference between the CRT Debug Library and VLD, is that Visual Leak Detector shows you the ...
8)....Added: Showing call stacks for 2 new types of fatal memory errors 9)....Added: EMemLeaks._ReserveOutOfMemory to control reserve size of out of memory errors (default is 50 Mb) 10)..Added: ...
文章描述了Android4.2之前存在的安全漏洞ContentProvider,并且利用该漏洞进行的一系列研究