标签：Cleaner 对象 虚拟机 Bitmap 源码 内存 NativeAllocationRegistry native
目录
1.Android为什么要将Finalize机制替换成Cleaner机制？
1.Android为什么要将Finalize机制替换成Cleaner机制？
思考问题
1.Android为什么要将Finalize机制替换成Cleaner机制？
2.Cleaner机制回收Native堆内存的原理是什么？
3.Cleaner机制源码是如何实现的？
一、版本
基于Andrroid 11(R)二、类图
三、流程
1.Bitmap对象注册Native堆内存资源
Bitmap的构造函数是通过called from JNI回调的，所以我们能在构造函数中拿到native堆内存的对象指针
/**
* Private constructor that must received an already allocated native bitmap
* int (pointer).
*/
// called from JNI
Bitmap(long nativeBitmap, int width, int height, int density,
boolean isMutable, boolean requestPremultiplied,
byte[] ninePatchChunk, NinePatch.InsetStruct ninePatchInsets) {
//nativeBitmap 回传的native对象地址
if (nativeBitmap == 0) {
throw new RuntimeException("internal error: native bitmap is 0");
}
mWidth = width;
mHeight = height;
mIsMutable = isMutable;
mRequestPremultiplied = requestPremultiplied;
mNinePatchChunk = ninePatchChunk;
mNinePatchInsets = ninePatchInsets;
if (density >= 0) {
mDensity = density;
}
mNativePtr = nativeBitmap;
//native堆内存大小
long nativeSize = NATIVE_ALLOCATION_SIZE + getAllocationByteCount();
NativeAllocationRegistry registry = new NativeAllocationRegistry(
Bitmap.class.getClassLoader(), nativeGetNativeFinalizer(), nativeSize);
//关联本地内存对象
registry.registerNativeAllocation(this, nativeBitmap);
if (ResourcesImpl.TRACE_FOR_DETAILED_PRELOAD) {
sPreloadTracingNumInstantiatedBitmaps++;
sPreloadTracingTotalBitmapsSize += nativeSize;
}
}
// NativeAllocationRegistry.java
public class NativeAllocationRegistry {
// 加载 freeFunction 函数的类加载器
private final ClassLoader classLoader;
// 回收 native 内存的 native 函数直接地址
private final long freeFunction;
// 分配的 native 内存大小（字节）
private final long size;
public NativeAllocationRegistry(ClassLoader classLoader, long freeFunction, long size) {
if (size < 0) {
throw new IllegalArgumentException("Invalid native allocation size: " + size);
}
this.classLoader = classLoader;
//分析1
this.freeFunction = freeFunction;
this.size = size;
}
}
分析一
natviceGetNativeFinalizer() 方法主要是传递native对象的释放资源的析构函数的位置
// Bitmap.java
// 【分析点 2：回收函数 nativeGetNativeFinalizer()】
NativeAllocationRegistry registry = new NativeAllocationRegistry(
Bitmap.class.getClassLoader(), nativeGetNativeFinalizer(), nativeSize);
private static native long nativeGetNativeFinalizer();
// Java 层
// ----------------------------------------------------------------------
// native 层
// Bitmap.cpp
static jlong Bitmap_getNativeFinalizer(JNIEnv*, jobject) {
// 转为long Bitmap_destruct是回收native层的
return static_cast<jlong>(reinterpret_cast<uintptr_t>(&Bitmap_destruct));
}
static void Bitmap_destruct(BitmapWrapper* bitmap) {
delete bitmap;
}
// Bitmap.java
// 注册 Java 层对象引用与 native 层对象的地址
registry.registerNativeAllocation(this, nativeBitmap);
// NativeAllocationRegistry.java
public Runnable registerNativeAllocation(Object referent, long nativePtr) {
if (referent == null) {
throw new IllegalArgumentException("referent is null");
}
if (nativePtr == 0) {
throw new IllegalArgumentException("nativePtr is null");
}
CleanerThunk thunk;
CleanerRunner result;
try {
//thunk对象实现Runnable接口
thunk = new CleanerThunk();
//创建Cleaner对象并传递该引用对象和thunk任务对象
Cleaner cleaner = Cleaner.create(referent, thunk);
result = new CleanerRunner(cleaner);
//给ART虚拟机注册本地内存的大小，GC内存大小统一在java层
registerNativeAllocation(this.size);
} catch (VirtualMachineError vme /* probably OutOfMemoryError */) {
applyFreeFunction(freeFunction, nativePtr);
throw vme;
// Other exceptions are impossible.
// Enable the cleaner only after we can no longer throw anything, including OOME.
//thunk设置本地指针
thunk.setNativePtr(nativePtr);
return result;
}
2.达到内存阈值时，触发GC流程
2.1Mark阶段
art/runtime/gc/collector/concurrent_copying.cc
2205 inline void ConcurrentCopying::ProcessMarkStackRef(mirror::Object* to_ref) {
...
2292 if (perform_scan) {
2293 if (use_generational_cc_ && young_gen_) {
//扫码年轻代里面的引用
2294 Scan<true>(to_ref);
2295 } else {
2296 Scan<false>(to_ref);
2297 }
2298 }
art/runtime/gc/reference_processor.cc
232 // Process the "referent" field in a java.lang.ref.Reference. If the referent has not yet been
233 // marked, put it on the appropriate list in the heap for later processing.
234 void ReferenceProcessor::DelayReferenceReferent(ObjPtr<mirror::Class> klass,
...
243 if (!collector->IsNullOrMarkedHeapReference(referent, /*do_atomic_update=*/true)) { <==== 如果referent未被标记，则表明其将被回收
...
257 if (klass->IsSoftReferenceClass()) {
258 soft_reference_queue_.AtomicEnqueueIfNotEnqueued(self, ref);
259 } else if (klass->IsWeakReferenceClass()) {
260 weak_reference_queue_.AtomicEnqueueIfNotEnqueued(self, ref);
261 } else if (klass->IsFinalizerReferenceClass()) {
262 finalizer_reference_queue_.AtomicEnqueueIfNotEnqueued(self, ref);
263 } else if (klass->IsPhantomReferenceClass()) { <============== 【关键】如果当前reference为PhantomReference，则将其加入到native的phantom_reference_queue_中
264 phantom_reference_queue_.AtomicEnqueueIfNotEnqueued(self, ref);
265 } else {
266 LOG(FATAL) << "Invalid reference type " << klass->PrettyClass() << " " << std::hex
267 << klass->GetAccessFlags();
268 }
269 }
270 }
2.2 后GC阶段
art/runtime/gc/reference_processor.cc
281 void Run(Thread* thread) override {
282 ScopedObjectAccess soa(thread);
283 jvalue args[1];
284 args[0].l = cleared_references_;
285 InvokeWithJValues(soa, nullptr, WellKnownClasses::java_lang_ref_ReferenceQueue_add, args); <===== 调用Java方法
286 soa.Env()->DeleteGlobalRef(cleared_references_);
287 }
libcore/ojluni/src/main/java/java/lang/ref/ReferenceQueue.java
static void add(Reference<?> list) {
262 synchronized (ReferenceQueue.class) {
263 if (unenqueued == null) {
264 unenqueued = list;
265 } else {
266 // Find the last element in unenqueued.
267 Reference<?> last = unenqueued;
268 while (last.pendingNext != unenqueued) {
269 last = last.pendingNext;
270 }
271 // Add our list to the end. Update the pendingNext to point back to enqueued.
272 last.pendingNext = list;
273 last = list;
274 while (last.pendingNext != list) {
275 last = last.pendingNext;
276 }
277 last.pendingNext = unenqueued;
278 }
279 ReferenceQueue.class.notifyAll(); //当cleared_references_中所有元素都添加进Java的全局ReferenceQueue中后，调用notifyAll唤醒ReferenceQueueDaemon线程
280 }
281 }
后续流程参考：
https://juejin.cn/post/6891918738846105614
四、问题
1.Android为什么要将Finalize机制替换成Cleaner机制？
【】因为Finalize机制存在上述说的3个缺陷，会引用native回收在并发访问时出错，所以在Java 9替换成了Cleaner机制
2.Cleaner机制回收Native堆内存的原理是什么？
【】通过Cleaner类继承PhantomReference对象，所以就用了PhantomReference引用的特性-》在GC回收时，当对象只关联PhantomReference对象时，
会加入到PhantomReferenceQueue中去，进而进行自定义的Native内存资源释放
3.Cleaner机制源码是如何实现的？
【】参考上面的流程
五、总结
| Finalized机制 | Cleaner机制 | NativeAllocationRegistry | |
| 原理 | 利用GC回收内存时，Object会调用finalize()方法，
在Object被回收时，重写finalize()方法里面去释放本地资源 参考：Bitmap （Android 7.0之前的实现）
| Cleaner类继承PhantomReference类，利用虚引用特性，当referent对象引用不可达时，会把该referent对象关联的PhantomReference放入到特定的ReferenceQueue中。 然后在ReferenceQueue中去执行Cleaner中的clean()方法，去执行native内存的释放操作 | 与Cleaner机制一致 |
| 优点 | 1.实现简单 | 1.在虚引用的全局Daemons守护线程中对虚引用队列操作，不会出现FInalized机制的并发问题 | Android N开始引入NativeAllocationRegistry类，一方面简化Cleaner的使用，另一方面将native资源的大小计入GC触发的策略中 |
| 缺点 | 1. 如果两个对象同时变成unreachable，他们的finalize方法执行顺序是任意的。因此在一个对象的finalize方法中使用另一个对象持有的native指针，将有可能访问一个已经释放的C++对象，从而导致native heap corruption。 | ||
| 2. 如果Java对象很小，而持有的native对象很大，则需要显示调用 | 2. 如果Java对象很小，而持有的native对象很大，则需要显示调用 |
六、学习到了什么
| 设计 | 1.PhantomReference虚引用特性 ——》对象加入到PhantomReferenceQueue之后，使用queue.get()方法是获取不到该虚引用的 |
| 2.使用PhantoReference虚引用特性——》当GC回收资源时，在PhantomReference引用队列会在自己自定义的线程执行 | |
| 3.NativeAllocationRegistry类是Android N(7.0) 引入，主要是Java实例对象在Native堆内存管理和释放的类 |
七、参考
https://juejin.cn/post/6891918738846105614
https://www.jianshu.com/p/6f042f9e47a8
标签：Cleaner,对象,虚拟机,Bitmap,源码,内存,NativeAllocationRegistry,native 来源： https://blog.csdn.net/zqs62761130/article/details/116905317
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。