Java/Android引用类型及其使用分析

Java/Android中有四种引用类型,分别是:

Strong reference     - 强引用
Soft Reference        - 软引用
Weak Reference      - 弱引用
Phantom Reference - 虚引用

不同的引用类型有着不同的特性,同时也对应着不同的使用场景。

1.Strong reference - 强引用

实际编码中最常见的一种引用类型。常见形式如:A a = new A();等。强引用本身存储在栈内存中,其存储指向对内存中对象的地址。一般情况下,当对内存中的对象不再有任何强引用指向它时,垃圾回收机器开始考虑可能要对此内存进行的垃圾回收。如当进行编码:a = null,此时,刚刚在堆中分配地址并新建的a对象没有其他的任何引用,当系统进行垃圾回收时,堆内存将被垃圾回收。

SoftReference、WeakReference、PhantomReference都是类java.lang.ref.Reference的子类。Reference作为抽象基类,定义了其子类对象的基本操作。Reference子类都具有如下特点:
1.Reference子类不能无参化直接创建,必须至少以强引用对象为构造参数,创建各自的子类对象;
2.因为1中以强引用对象为构造参数创建对象,因此,使得原本强引用所指向的堆内存中的对象将不再只与强引用本身直接关联,与Reference的子类对象的引用也有一定联系。且此种联系将可能影响到对象的垃圾回收。

根据不同的子类对象对其指示对象(强引用所指向的堆内存中的对象)的垃圾回收不同的影响特点,分别形成了三个子类,即SoftReference、WeakReference和PhantomReference。

2.Soft Reference - 软引用

软引用的一般使用形式如下:
A a = new A();
SoftReference<A> srA = new SoftReference<A>(a);

通过对象的强引用为参数,创建了一个SoftReference对象,并使栈内存中的wrA指向此对象。

此时,进行如下编码:a = null,对于原本a所指向的A对象的垃圾回收有什么影响呢?

先直接看一下下面一段程序的输出结果:

 1 import java.lang.ref.SoftReference;
 2
 3 public class ReferenceTest {
 4
 5     public static void main(String[] args) {
 6
 7         A a = new A();
 8
 9         SoftReference<A> srA = new SoftReference<A>(a);
10
11         a = null;
12
13         if (srA.get() == null) {
14             System.out.println("a对象被回收");
15         } else {
16             System.out.println("a对象尚未被回收" + srA.get());
17         }
18
19         // 垃圾回收
20         System.gc();
21
22         if (srA.get() == null) {
23             System.out.println("a对象被回收");
24         } else {
25             System.out.println("a对象尚未被回收" + srA.get());
26         }
27
28     }
29 }
30
31 class A {
32
33 }

##输出结果为:

1 a对象尚未被回收[email protected]
2 a对象尚未被回收[email protected]

当 a = null后,堆内存中的A对象将不再有任何的强引用指向它,但此时尚存在srA引用的对象指向A对象。当第一次调用srA.get()方法返回此指示对象时,由于垃圾回收器很有可能尚未进行垃圾回收,此时get()是有结果的,这个很好理解。当程序执行System.gc();强制垃圾回收后,通过srA.get(),发现依然可以得到所指示的A对象,说明A对象并未被垃圾回收。那么,软引用所指示的对象什么时候才开始被垃圾回收呢?需要满足如下两个条件:

1.当其指示的对象没有任何强引用对象指向它;

2.当虚拟机内存不足时。

因此,SoftReference变相的延长了其指示对象占据堆内存的时间,直到虚拟机内存不足时垃圾回收器才回收此堆内存空间。

3.Weak Reference - 弱引用

同样的,软引用的一般使用形式如下:
A a = new A();
WeakReference<A> wrA = new WeakReference<A>(a);

当没有任何强引用指向此对象时, 其垃圾回收又具有什么特性呢?

 1 import java.lang.ref.WeakReference;
 2
 3 public class ReferenceTest {
 4
 5     public static void main(String[] args) {
 6
 7         A a = new A();
 8
 9         WeakReference<A> wrA = new WeakReference<A>(a);
10
11         a = null;
12
13         if (wrA.get() == null) {
14             System.out.println("a对象被回收");
15         } else {
16             System.out.println("a对象尚未被回收" + wrA.get());
17         }
18
19         // 垃圾回收
20         System.gc();
21
22         if (wrA.get() == null) {
23             System.out.println("a对象被回收");
24         } else {
25             System.out.println("a对象尚未被回收" + wrA.get());
26         }
27
28     }
29
30 }
31
32 class A {
33
34 }

##输出结果为:

a对象尚未被回收[email protected]
a对象被回收

输出的第一条结果解释同上。当进行垃圾回收后,wrA.get()将返回null,表明其指示对象进入到了垃圾回收过程中。因此,对弱引用特点总结为:

WeakReference不改变原有强引用对象的垃圾回收时机,一旦其指示对象没有任何强引用对象时,此对象即进入正常的垃圾回收流程。

那么,依据此特点,很可能有疑问:WeakReference存在又有什么意义呢?

其主要使用场景见于:当前已有强引用指向强引用对象,此时由于业务需要,需要增加对此对象的引用,同时又不希望改变此引用的垃圾回收时机,此时WeakReference正好符合需求,常见于一些与生命周期的场景中。

下面给出一个Android中关于WeakReference使用的场景 —— 结合静态内部类和WeakReference来解决Activity中可能存在的Handler内存泄露问题。

Activity中我们需要新建一个线程获取数据,使用handler - sendMessage方式。下面是这一过程的一般性代码:

 1 public class MainActivity extends Activity {
 2
 3     //...
 4     private int page;
 5     private Handler handler = new Handler() {
 6
 7         @Override
 8         public void handleMessage(Message msg) {
 9             if (msg.what == 1) {
10
11                 //...
12
13                 page++;
14             } else {
15
16                 //...
17
18             }
19
20         };
21     };
22
23     @Override
24     protected void onCreate(Bundle savedInstanceState) {
25         super.onCreate(savedInstanceState);
26         setContentView(R.layout.activity_main);
27
28         //...
29
30         new Thread(new Runnable() {
31             @Override
32             public void run() {
33                 //..
34                 Message msg = Message.obtain();
35                 msg.what = 1;
36                 //msg.obj = xx;
37                 handler.sendMessage(msg);
38             }
39         }).start();
40
41         //...
42
43     }
44
45 }

在Eclispe中Run Link,将会看到警示信息:This Handler class should be static or leaks might occur ...点击查看此信息,其详情中对问题进行了说明并给出了建议性的解决方案。

Issue: Ensures that Handler classes do not hold on to a reference to an outer class
Id: HandlerLeak

Since this Handler is declared as an inner class, it may prevent the outer class from being garbage collected. If the Handler is using a Looper or MessageQueue for a thread other than the main thread, then there is no issue. If the Handler is using the Looper or MessageQueue of the main thread, you need to fix your Handler declaration, as follows: Declare the Handler as a static class;In the outer class, instantiate a WeakReference to the outer class and pass this object to your Handler when you instantiate the Handler; Make all references to members of the outer class using the WeakReference object.

大致的意思是建议将Handler定义成内部静态类,并在此静态内部类中定义一个WeakReference的引用,由于指示外部的Activity对象。

问题分析:

Activity具有自身的生命周期,Activity中新开启的线程运行过程中,可能此时用户按下了Back键,或系统内存不足等希望回收此Activity,由于Activity中新起的线程并不会遵循Activity本身的什么周期,也就是说,当Activity执行了onDestroy,由于线程以及Handler 的HandleMessage的存在,使得系统本希望进行此Activity内存回收不能实现,因为非静态内部类中隐性的持有对外部类的引用,导致可能存在的内存泄露问题。

因此,在Activity中使用Handler时,一方面需要将其定义为静态内部类形式,这样可以使其与外部类(Activity)解耦,不再持有外部类的引用,同时由于Handler中的handlerMessage一般都会多少需要访问或修改Activity的属性,此时,需要在Handler内部定义指向此Activity的WeakReference,使其不会影响到Activity的内存回收同时,可以在正常情况下访问到Activity的属性。

未完待续...

时间: 2024-12-22 16:13:27

Java/Android引用类型及其使用分析的相关文章

【Java&amp;amp;Android开源库代码分析】のandroid-async-http の开盘

在<[Java&Android开源库代码剖析]のandroid-smart-image-view>一文中我们提到了android-async-http这个开源库,本文正式开篇来具体介绍这个库的实现,同一时候结合源代码探讨怎样设计一个优雅的Android网络请求框架.做过一段时间Android开发的同学应该对这个库不陌生,由于它对Apache的HttpClient API的封装使得开发人员能够简洁优雅的实现网络请求和响应,而且同一时候支持同步和异步请求. 网络请求框架一般至少须要具备例如

Android加壳原理分析

0x00 阅读本文前,建议读者首先阅读Android加壳原理,参考文章Android中的Apk的加固(加壳)原理解析和实现.如果没有看过这篇文章,本文理解起来比较困难. 0x01 下面我们来分析脱壳代码为什么要这样写,核心脱壳代码在ProxyApplication类里面,首先执行成员方法attachBaseContext,然后执行成员方法onCreate. 那么attachBaseContext是什么时候被执行的呢,为什么先于onCreate执行呢?那就需要看Android的源码了,我们选用的是

java/android 设计模式学习笔记(7)---装饰者模式

这篇将会介绍装饰者模式(Decorator Pattern),装饰者模式也称为包装模式(Wrapper Pattern),结构型模式之一,其使用一种对客户端透明的方式来动态的扩展对象的功能,同时它也是继承关系的一种替代方案之一,但比继承更加灵活.在现实生活中也可以看到很多装饰者模式的例子,或者可以大胆的说装饰者模式无处不在,就拿一件东西来说,可以给它披上无数层不一样的外壳,但是这件东西还是这件东西,外壳不过是用来扩展这个东西的功能而已,这就是装饰者模式,装饰者的这个角色也许各不相同但是被装饰的对

[Android]Fragment源码分析(一) 构造

Fragment是Android3.0之后提供的api,被大家广泛所熟知的主要原因还是因为随即附带的ViewPager控件.虽然我并不喜欢用它,但是它确实是一个相对不错的控件.还是我的一贯作风,我将从源码上向大家展示什么是Fragment.我们先写一个简单的代码对Fragment有个直观的认识:(为了保证我们方便调试,我们可以直接使用V4提供的源码包) FragmentTransaction t = getSupportFragmentManager().beginTransaction();

android:clipToPadding属性的分析——以ListView的&quot;别样&quot;padding为例

MainActivity如下: package cn.com.bravesoft.testlistviewloadmore; import java.util.ArrayList; import java.util.HashMap; import android.app.Activity; import android.os.Bundle; import android.widget.ListView; import android.widget.SimpleAdapter; /** * Dem

Android &lt;uses-sdk&gt; 和 target 分析

Android中<uses-sdk>属性和target属性分析 1. 概要 <uses-sdk> 用来描述该应用程序可以运行的最小和最大API级别,以及应用程序开发者设计期望运行的平台版本.通过在manifest清单文件中添加该属性,我们可以更好的控制应用在不同android 系统版本上的安装和兼容性体验问题.                                                                                    (图

android添加账户流程分析涉及漏洞修复

android修复了添加账户代码中的2处bug,retme取了很酷炫的名字launchAnyWhere.broadAnywhere(参考资料1.2).本文顺着前辈的思路学习bug的原理和利用思路. 我们先看下源码里setting中添加账户的代码,来理解bug产生的原理. /packages/apps/Settings/src/com/android/settings/accounts/AddAccountSettings.java下oncreate: public void onCreate(B

[Android]Fragment源码分析(三) 事务

Fragment管理中,不得不谈到的就是它的事务管理,它的事务管理写的非常的出彩.我们先引入一个简单常用的Fragment事务管理代码片段: FragmentTransaction ft = this.getSupportFragmentManager().beginTransaction(); ft.add(R.id.fragmentContainer, fragment, "tag"); ft.addToBackStack("<span style="fo

[Android]Volley源码分析(二)Cache

Cache作为Volley最为核心的一部分,Volley花了重彩来实现它.本章我们顺着Volley的源码思路往下,来看下Volley对Cache的处理逻辑. 我们回想一下昨天的简单代码,我们的入口是从构造一个Request队列开始的,而我们并不直接调用new来构造,而是将控制权反转给Volley这个静态工厂来构造. com.android.volley.toolbox.Volley: public static RequestQueue newRequestQueue(Context conte