关于java内存泄漏
来源:互联网 发布:windows系统在哪下载 编辑:程序博客网 时间:2024/05/17 09:41
http://www.importnew.com/8935.html
http://www.cnblogs.com/kissazi2/p/4121852.html
http://blog.csdn.net/crabisacoolboy/article/details/45340659
Java应用程序中的内存泄漏及内存管理
Java平台的一个突出的特性是自动内存管理。很多人把这种特性误读为Java没有内存泄露。然而,在我印象中,现代Java框架以及基于Java的平台并非如此。特别是Android平台,能举出很多反例。为了让大家对Java平台的内存泄露有一个初步的认识,我们先来看一个Java实现的栈:
class
SimpleStack {
private
final
Object[] objectPool =
new
Object[
10
];
private
int
pointer = -
1
;
public
Object pop() {
if
(pointer <
0
) {
throw
new
IllegalStateException(
"no elements on stack"
);
}
return
objectPool[pointer--];
}
public
Object peek() {
if
(pointer <
0
) {
throw
new
IllegalStateException(
"no elements on stack"
);
}
return
objectPool[pointer];
}
public
void
push(Object object) {
if
(pointer >
8
) {
throw
new
IllegalStateException(
"stack overflow"
);
}
objectPool[++pointer] = object;
}
}
这个栈的实现基于一个对象数组,并维护了一个用于指向栈内当前可用单元的整型指针。上面的实现中,每次从栈顶弹出元素都会产生内存泄露。确切的说,即使不再使用栈顶元素,对象数组会继续持有栈顶元素的引用(除非栈顶元素再次入栈,栈顶元素的引用会被完全相同的引用覆盖)。因此,即便这个对象的其他引用都被释放,Java虚拟机也不能回收这个对象。由于这种栈实现并不允许外界直接访问其底层的对象池,因此除非有新元素入栈并被放置在栈内的同一个位置上,否则这个无法访问的引用将阻止垃圾回收器回收该对象。
幸运的是,这个内存泄露很容易修复:
public
Object pop() {
if
(pointer <
1
) {
throw
new
IllegalStateException(
"no elements on stack"
);
}
try
{
return
objectPool[pointer];
}
finally
{
objectPool[pointer--] =
null
;
}
}
当然,在日常的Java开发中一般不会去实现一个内存数据结构。因此,让我们来看一个更常见的Java内存泄漏的例子。在Java开发中经常用到的观察者模式就会引起内存泄露:
class
Observed {
public
interface
Observer {
void
update();
}
private
Collection<Observer> observers =
new
HashSet<Observer>();
void
addListener(Observer observer) {
observers.add(observer);
}
void
removeListener(Observer observer) {
observers.remove(observer);
}
}
这次提供了一个直接删除底层对象池引用的方法。基于这种实现,任何已注册的Observer
在使用后只要被正确注销,就不会存在内存泄漏的风险。然而,假设这样一个场景,框架的使用者在使用完Observer
之后并没有及时注销。同理Observer
将永远不会被回收,因为Observed
一直保留着它的引用。更糟的是,没有Observer
引用,是无法从Observed
对象池外部删除Observer
的,即无法回收未被及时注销的Observer
。
不过,有一种简单的方法能够修复这种潜在的内存泄露——弱引用。我个人认为这是Java程序员都应该知道的特性。简单地说,弱引用在功能上和普通的引用一样,但它不会妨碍垃圾回收。因此JVM执行垃圾回收时,如果没有发现强引用,那么你就会发现弱引用会被置为null
。要使用弱引用,我们可以将上面的代码改为:
private
Collection<Observer> observers = Collections.newSetFromMap(
new
WeakHashMap<Observer, Boolean>());
WeakHashMap是一个现成的弱引用Map,Map的键都是弱引用对象。使用WeakHashMap
后,被观察者将不会阻止JVM对Observer
进行垃圾回收。然而,你必须在代码注释中强调这一点。因为这个特性可能引起一些问题,比如使用者想要注册一个常驻内存的Observer
(例如日志库),但他们并没有打算维持一个Observer
引用。例如,Android平台上的OnSharedPreferencesChangeListener使用了弱引用,但文档中并没有声明这一特性。这给开发者带来了很多麻烦。
在本文的开头我提到了,现在的很多框架都需要使用者谨慎地管理内存。我想至少有两个例子可以印证这个观点。
Android平台
Android应用程序的核心类采用了基于生命周期的编程模型。这意味着你不能自行创建和管理这些类的实例,这些实例将由Android操作系统在需要的时候替你创建(比如应用程序需要显示某个特定的画面)。同理,Android操作系统将会决定应用何时不再需要某个特定实例(比如用户关闭了应用界面),并通过调用该实例特定的生命周期方法来通知该实例即将被删除。但是,如果你将这个实例的引用泄露到某个全局上下文,Android JVM将不能对这个实例进行回收。这与Android本身的设计理念相违背。由于Android手机通常没有限制应用程序的内存,即使在非常简单的应用中,也会频繁创建和销毁对象,所以在清理引用时必须格外小心。
不幸的是,应用程序核心类引用很容易被泄露到外部。你能看出下面的例子是如何泄露引用的吗?
class
ExampleActivity
extends
Activity {
@Override
public
void
onCreate(Bundle bundle) {
startService(
new
Intent(
this
, ExampleService.
class
).putExtra(
"mykey"
,
new
Serializable() {
public
String getInfo() {
return
"myinfo"
;
}
}));
}
}
如果你认为是传入Intent
构造函数的this指针泄露了当前实例的引用,你就错了。这个Intent
对象仅用于启动ExampleService
,它会在ExampleService
启动之后被销毁。然而,那个实现了Serializable
接口的匿名内部类会持有闭包类ExampleActivity
的引用。如果ExampleService
一直维持着这个匿名类实例引用,那么也会持有这个ExampleActivity
实例的引用。
出于这个原因,我建议Android开发者避免使用匿名类。
Web应用框架(特别是Wicket)
Web应用框架通常将半永久性的用户数据存放在Session
中。你在Session
中写入的任何数据都会在内存中滞留,而且滞留的时间无法确定。如果有一定数量的访问者在你的Session
中“乱扔垃圾”,运行Servlet
容器的JVM早晚会挂掉。因此,你谨慎管理引用的另一个极端案例就是Wicket框架:Wicket框架会将用户的所有访问序列化成历史版本。这种过分简单的设计意味着,如果某个访问者点击十次欢迎页面,Wicket框架会在硬盘默认路径下序列化十个对象。Wicket页面对象持有的所有对象引用都会和页面对象一起被序列化到硬盘上,所以在管理引用时必须格外小心。
让我们来看一个错误使用Wicket框架的示例:
class
ExampleWelcomePage
extends
WebPage {
private
final
List<People> peopleList;
public
ExampleWelcomePage (PageParameters pageParameters) {
peopleList =
new
Service().getWorldPhonebook();
}
}
用户点击十次欢迎页面,就会在服务器硬盘上存储十份WorldPhoneBook
拷贝。因此,在你使用Wicket开发应用时,务必要使用LoadableDetachableModels
管理引用。
在Java程序中追踪内存泄漏是一件非常麻烦的事情,因此我想推荐一款非常好用的(但很可惜不是免费的)调式工具:JProfiler。它能够提供Java程序运行时的堆快照(heap dumps),帮助你了解程序运行时内部的具体情况。如果你的程序存在内存泄露的问题,我推荐你试一试JProfiler。JProfiler提供免费试用许可证。
- 关于Java内存泄漏
- 关于Java内存泄漏
- 关于java内存泄漏
- 关于Java的内存泄漏
- 关于JAVA内存泄漏问题注意事项
- 关于java递归调用内存泄漏
- 关于 JAVA 的内存泄漏问题
- 关于JAVA内存泄漏问题注意事项
- 关于Java内存泄漏的介绍
- 关于java内存泄漏的一点学习心得
- 关于Java内存泄漏及如何检测
- 关于指针(内存)泄漏
- 关于查找内存泄漏
- 关于内存泄漏
- 关于内存泄漏问题
- 关于colorWithPatternImage内存泄漏
- 关于内存泄漏
- 关于内存泄漏
- android源码下载
- Android中的dispatchTouchEvent()、onInterceptTouchEvent()和onTouchEvent()
- 面向对象-封装、继承、多态
- VS2010 LNK1123: 转换到 COFF 期间失败: 文件无效或损坏 的解决方法
- 任意输入一个字符串,输出它的所有子串。Python练习(未考虑去重问题)
- 关于java内存泄漏
- ADODB.Connection、ADODB.RecordSet
- android 控件的焦点
- qemu-1.4.0编译错误处理
- HIVE分析窗口函数: GROUPING SETS,GROUPING__ID,CUBE,ROLLUP
- string.find() string.substr();
- 视频缩略图
- 8.2.1.2 How MySQL Optimizes WHERE Clauses 如何优化mySQL WHERE子句:
- 文件读取