java四种引用及在LeakCanery中应用
java四种引用及在LeakCanery中应用
java 四种引用
Java4种引用的级别由高到低依次为:
StrongReference > SoftReference > WeakReference > PhantomReference
- StrongReference
String tag = new String("T");
此处的 tag 引用就称之为强引用。而强引用有以下特征:
- 强引用可以直接访问目标对象。
- 强引用所指向的对象在任何时候都不会被系统回收。
- 强引用可能导致内存泄漏。
我们要讨论的其它三种Reference较之于强引用而言都属于“弱引用”,也就是他们所引用的对象只要没有强引用,就会根据条件被JVM的垃圾回收器所回收,它们被回收的时机以及用法各不相同。下面分别来进行讨论。 - SoftReference
软引用有以下特征: - 软引用使用 get() 方法取得对象的强引用从而访问目标对象。
- 软引用所指向的对象按照 JVM 的使用情况(Heap 内存是否临近阈值)来决定是否回收。
- 软引用可以避免 Heap 内存不足所导致的异常。
当垃圾回收器决定对其回收时,会先清空它的 SoftReference,也就是说 SoftReference 的 get() 方法将会返回 null,然后再调用对象的 finalize() 方法,并在下一轮 GC 中对其真正进行回收。 - WeakReference
WeakReference 是弱于 SoftReference 的引用类型。弱引用的特性和基本与软引用相似,区别就在于弱引用所指向的对象只要进行系统垃圾回收,不管内存使用情况如何,永远对其进行回收(get() 方法返回 null)。
弱引用有以下特征:
- 弱引用使用 get() 方法取得对象的强引用从而访问目标对象。
- 一旦系统内存回收,无论内存是否紧张,弱引用指向的对象都会被回收。
- 弱引用也可以避免 Heap 内存不足所导致的异常。
- PhantomReference(虚引用)
PhantomReference 是所有“弱引用”中最弱的引用类型。不同于软引用和弱引用,虚引用无法通过get()方法来取得目标对象的强引用从而使用目标对象,观察源码可以发现 get() 被重写为永远返回 null。
虚引用有以下特征:
虚引用永远无法使用 get() 方法取得对象的强引用从而访问目标对象。
虚引用所指向的对象在被系统内存回收前,虚引用自身会被放入 ReferenceQueue 对象中从而跟踪对象垃圾回收。
虚引用不会根据内存情况自动回收目标对象。
虚引用必须和引用队列(ReferenceQueue)联合使用
Reference与ReferenceQueue 使用demo
定义一个对象Brain
public class Brain {
public int mIndex; // 占用较多内存,当系统内存不足时,会自动进行回收 private byte []mem; public Brain(int index) { mIndex = index; mem = new byte[1024 * 1024]; } @Override protected void finalize() throws Throwable { super.finalize(); LogUtils.e("Brain", "finalize + index=" + mIndex); }
}
创建Reference并添加到RefrenceQueue中
// 定义几个成员变量
ReferenceQueue mWeakQueue = new ReferenceQueue<>();
ReferenceQueue mPhQueue = new ReferenceQueue<>();
List> mWeakList = new ArrayList<>();
List> mPhList = new ArrayList<>();
// 开启守护线程用于检测ReferenceQue中是否有对象被添加
private void startDemoThread() {
Thread threadWeak = new Thread(() -> { try { int cnt = 0; WeakReference<Brain> k; // remove 方法为阻塞式的, 而poll方法不是 while((k = (WeakReference) mWeakQueue.remove()) != null) { LogUtils.e(TAG, "回收了WeakReference指向对象, : cnt=" + (cnt++) + " wf=" + k); } } catch(InterruptedException e) { //结束循环 } }, "MainActivityWeak"); threadWeak.setDaemon(true); threadWeak.start(); Thread threadPh = new Thread(() -> { try { int cnt = 0; PhantomReference<Brain> k; while((k = (PhantomReference) mPhQueue.remove()) != null) { LogUtils.e(TAG, "回收了PhantomReference指向对象, cnt=" + (cnt++) + " pr=" + k); } } catch(InterruptedException e) { //结束循环 } }, "MainActivityPhantom"); threadPh.setDaemon(true); threadPh.start();
}
// 注意创建的Reference对象需要暂存起来(实测中,如果Reference被回收是不会被添加到ReferenceQueue中的)
private void test() {
for (int i=0; i<1000; i++) { Brain src1 = new Brain(i); Brain src2 = new Brain(100000 + i); // 将Reference注册到RefrenceQueue中 WeakReference<Brain> weakReference = new WeakReference<Brain>(src1, mWeakQueue); mWeakList.add(weakReference); //将Reference注册到RefrenceQueue中 PhantomReference<Brain> phantomReference = new PhantomReference<>(src2, mPhQueue); mPhList.add(phantomReference);
try { Thread.sleep(10); } catch (InterruptedException e) { e.printStackTrace(); } }
}
结果打印:
2019-01-29 19:22:27.499 9283-9308/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了WeakReference: cnt=0 wf=java.lang.ref.WeakReference@e1f904c
2019-01-29 19:22:27.499 9283-9308/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了WeakReference: cnt=1 wf=java.lang.ref.WeakReference@82fc895
2019-01-29 19:22:27.500 9283-9308/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了WeakReference: cnt=2 wf=java.lang.ref.WeakReference@3b3fdaa
2019-01-29 19:22:27.500 9283-9308/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了WeakReference: cnt=3 wf=java.lang.ref.WeakReference@668fd9b
2019-01-29 19:22:27.501 9283-9292/com.selftest.test.testapp3 E/IFLY_SDK_Brain: finalize + index=0
2019-01-29 19:22:27.501 9283-9292/com.selftest.test.testapp3 E/IFLY_SDK_Brain: finalize + index=100000
2019-01-29 19:22:27.502 9283-9308/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了WeakReference: cnt=4 wf=java.lang.ref.WeakReference@8db6538
2019-01-29 19:22:27.502 9283-9308/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了WeakReference: cnt=5 wf=java.lang.ref.WeakReference@f915911
2019-01-29 19:22:27.503 9283-9292/com.selftest.test.testapp3 E/IFLY_SDK_Brain: finalize + index=1
2019-01-29 19:22:27.503 9283-9292/com.selftest.test.testapp3 E/IFLY_SDK_Brain: finalize + index=100001
2019-01-29 19:22:27.504 9283-9292/com.selftest.test.testapp3 E/IFLY_SDK_Brain: finalize + index=2
2019-01-29 19:22:27.505 9283-9292/com.selftest.test.testapp3 E/IFLY_SDK_Brain: finalize + index=100002
2019-01-29 19:22:27.507 9283-9292/com.selftest.test.testapp3 E/IFLY_SDK_Brain: finalize + index=3
2019-01-29 19:22:27.507 9283-9292/com.selftest.test.testapp3 E/IFLY_SDK_Brain: finalize + index=100003
2019-01-29 19:22:27.507 9283-9292/com.selftest.test.testapp3 E/IFLY_SDK_Brain: finalize + index=4
2019-01-29 19:22:27.508 9283-9292/com.selftest.test.testapp3 E/IFLY_SDK_Brain: finalize + index=100004
2019-01-29 19:22:27.508 9283-9292/com.selftest.test.testapp3 E/IFLY_SDK_Brain: finalize + index=5
2019-01-29 19:22:27.509 9283-9292/com.selftest.test.testapp3 E/IFLY_SDK_Brain: finalize + index=100005
2019-01-29 19:22:27.629 9283-9309/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了PhantomReference: cnt=0 pr=null
2019-01-29 19:22:27.629 9283-9309/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了PhantomReference: cnt=1 pr=null
2019-01-29 19:22:27.629 9283-9308/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了WeakReference: cnt=6 wf=java.lang.ref.WeakReference@e2c4a76
2019-01-29 19:22:27.630 9283-9309/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了PhantomReference: cnt=2 pr=null
2019-01-29 19:22:27.630 9283-9308/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了WeakReference: cnt=7 wf=java.lang.ref.WeakReference@4cfd877
2019-01-29 19:22:27.630 9283-9309/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了PhantomReference: cnt=3 pr=null
2019-01-29 19:22:27.630 9283-9309/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了PhantomReference: cnt=4 pr=null
2019-01-29 19:22:27.630 9283-9308/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了WeakReference: cnt=8 wf=java.lang.ref.WeakReference@37d9ce4
2019-01-29 19:22:27.630 9283-9309/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了PhantomReference: cnt=5 pr=null
2019-01-29 19:22:27.630 9283-9308/com.selftest.test.testapp3 E/IFLY_SDK_MainActivity: 回收了WeakReference: cnt=9 wf=java.lang.ref.WeakReference@ea1754d
结果分析:
当对象被回收后,持有他的引用WeakReference/PhantomReference会被放入ReferenceQueue中
WeakReference在原始对象回收之前被放入ReferenceQueue中,而PhantomReference是在回收之后放入ReferenceQueue中
WeakReference在Leakcanery中的应用
LeakCanery是Android检测内存泄漏的工具,可以检测到Activity/Fragment存在的内存泄漏。
检测原理:
在Application中注册监听所有Activity生命周期的listener,registerActivityLifecycleCallbacks。
//ActivityRefWatcher 中的代码
public void watchActivities() {
// Make sure you don't get installed twice. stopWatchingActivities(); application.registerActivityLifecycleCallbacks(lifecycleCallbacks);
}
public void stopWatchingActivities() {
application.unregisterActivityLifecycleCallbacks(lifecycleCallbacks);
}
当Activity的onDestroy被调用时,生成一个uuid,标记这个Activity的WeakReference。
创建一个弱引用,并与一个跟踪所有activit回收的ReferenceQueue相关联。(放入一个map中,key : uuid, value:weakReference)
private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
new ActivityLifecycleCallbacksAdapter() { @Override public void onActivityDestroyed(Activity activity) { refWatcher.watch(activity); } };
具体的watch执行如下:
public void watch(Object watchedReference, String referenceName) {
if (this == DISABLED) { return; } checkNotNull(watchedReference, "watchedReference"); checkNotNull(referenceName, "referenceName"); final long watchStartNanoTime = System.nanoTime(); String key = UUID.randomUUID().toString(); retainedKeys.add(key); final KeyedWeakReference reference = new KeyedWeakReference(watchedReference, key, referenceName, queue); ensureGoneAsync(watchStartNanoTime, reference);
}
ensureGoneAsync执行如下:
// watchExecutor 在一定时间后检查被注册的WeakReference有没有被添加到ReferenceQueue中
private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) {
watchExecutor.execute(new Retryable() { @Override public Retryable.Result run() { return ensureGone(reference, watchStartNanoTime); } });
}
在onDestry被调用后若干秒执行如下操作:到ReferenceQueue中去取这个Activity,如果能够取到说明这个Activity被正常回收了。如果无法回收,触发GC,再去RerenceQueue中取如果还是无法取到,说明Activity没有被系统回收,可能存在内存泄漏。
真正核心的代码如下:
long gcStartNanoTime = System.nanoTime();
long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime); // 如果ReferenceQue中有activity的弱引用,则将retainedKeys中的uuid移除 removeWeaklyReachableReferences(); if (debuggerControl.isDebuggerAttached()) { // The debugger can create false leaks. return RETRY; } // 如果activity对应的uuid已经被移除,说明activity已经被回收,无内存泄漏 if (gone(reference)) { return DONE; } // 触发gc,进行垃圾回收 gcTrigger.runGc(); removeWeaklyReachableReferences(); // 如果uuid还没有被移除,说明activiy存在内存泄漏,需要dump内存,进行分析 if (!gone(reference)) { long startDumpHeap = System.nanoTime(); long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime); File heapDumpFile = heapDumper.dumpHeap(); if (heapDumpFile == RETRY_LATER) { // Could not dump the heap. return RETRY; } long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap); HeapDump heapDump = heapDumpBuilder.heapDumpFile(heapDumpFile).referenceKey(reference.key) .referenceName(reference.name) .watchDurationMs(watchDurationMs) .gcDurationMs(gcDurationMs) .heapDumpDurationMs(heapDumpDurationMs) .build(); heapdumpListener.analyze(heapDump); } return DONE;
}
HeapDump dump内存和分析的过程这里就不细说。
梦想不是浮躁,而是沉淀和积累
原文地址https://www.cnblogs.com/NeilZhang/p/11441402.html
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
C++ 并发编程之互斥锁和条件变量的性能比较
C++ 并发编程之互斥锁和条件变量的性能比较介绍本文以最简单生产者消费者模型,通过运行程序,观察该进程的cpu使用率,来对比使用互斥锁 和 互斥锁+条件变量的性能比较。 本例子的生产者消费者模型,1个生产者,5个消费者。生产者线程往队列里放入数据,5个消费者线程从队列取数据,取数据前需要判断一下队列中是否有数据,这个队列是全局队列,是线程间共享的数据,所以需要使用互斥锁进行保护。即生产者在往队列里放入数据时,其余消费者不能取,反之亦然。 互斥锁实现的代码 include // std::cout include // std::deque include // std::thread include // std::chrono include // std::mutex // 全局队列std::deque g_deque; // 全局锁std::mutex g_mutex; // 生产者运行标记bool producer_is_running = true; // 生产者线程函数void Producer(){ // 库存个数 int count = 8; do { // 智能锁,初...
- 下一篇
python多进程通信实例分析
python多进程通信实例分析操作系统会为每一个创建的进程分配一个独立的地址空间,不同进程的地址空间是完全隔离的,因此如果不加其他的措施,他们完全感觉不到彼此的存在。那么进程之间怎么进行通信?他们之间的关联是怎样的?实现原理是什么?本文就来借助Python简单的聊一下进程之间的通信?还是那句话,原理是相同的,希望能透过具体的例子来体会一下本质的东西。 下面尽量以简单的方式介绍一下每一类通信方式,具体的细节可以参照文档使用; 管道先来看一下最简单、古老的一种IPC:管道。通常指的是无名管道,本质上可以看做一种文件,只存在于内存当中,不会存盘。不同进程通过系统提供的接口来向管道中读取或者写入数据。 也就是说我们通过这样一个中间介质为进程提供交流的方式。无名管道的局限在于一般只用于有直接关联关系的父子进程。下面通过一个简单的例子来看一下其用法。 复制代码from multiprocessing import Process, Pipe def pstart(pname, conn): conn.send("Data@subprocess") print(conn.recv()) # Data...
相关文章
文章评论
共有0条评论来说两句吧...