使用 CloseableReference 优雅的释放对象，来自

作者: 王晨彦 | 来源:发表于2021-11-10 20:19 被阅读0次

前言

说到 Fresco，想必各位都耳熟能详，出自 Facebook 的大名鼎鼎的图片加载框架，虽然最近几年被 Glide 凭借轻量和易用性而超越，但我们仍无法否认 Fresco 的强大和优秀的性能，这里不再展开。

今天要介绍的是 Fresco 基于 Bitmap 复用逻辑上抽象出的，通用的、安全的可自动释放的引用，官方文档也有专门的页面介绍「可关闭的引用」，但是发现大家真正使用的并不多，因此觉得有必要再介绍一下。

使用

这里引用官方文档的使用介绍

调用者拥有这个引用

我们创建一个引用，但我们传递给了一个调用者，调用者将持有这个引用。

CloseableReference<Val> foo() {
  Val val;
  return CloseableReference.of(val);
}

持有者在离开作用域之前，需要关闭引用

创建了一个引用，但是没有传递给其他调用者，在结束时，需要关闭：

void gee() {
  CloseableReference<Val> ref = foo();
  try {
    haa(ref);
  } finally {
    ref.close();
  }
}

finally 中最适合做此类事情了。

在赋值给变量前，先进行 clone

void haa(CloseableReference<?> ref) {
  final CloseableReference<?> refClone = ref.clone();
  try {
    // 交给下个作用域处理
    ohaa(refClone);
  } finally {
    // 当前函数域内可安全关闭，闭包内为已经clone过的引用。
    ref.close();
  }
}

使用可以说非常简单了

通过 CloseableReference.of 创建一个可关闭的引用
未关闭的引用通过 CloseableReference.get 获取引用的实例
通过 CloseableReference.close 关闭引用
通过 CloseableReference.clone 复制一个引用，交给下一个函数处理，当前域的引用即可安全关闭
当激活的引用为0时，即会销毁该实例

不知道大家有没有发现一个问题，上面并没有介绍实例是怎么销毁的，这里就需要配合源码一起看了。

CloseableReference.of 方法有两个重载，分别是

public static <T extends Closeable> CloseableReference<T> of(T t)

public static <T> CloseableReference<T> of(T t, ResourceReleaser<T> resourceReleaser)

这样就比较清晰了，官方示例中使用的是一个 Closeable 的实例，在销毁的时候会调用 Closeable.close 方法，Closeable 是 JDK 中的接口，在源码中非常常见，比如我们最熟悉的 InputStream 就实现了该接口，大家一定还记得在使用完 InputStream 之后要调用 close 方法，避免内存泄露。

那如果我的实例没有实现 Closeable 接口呢，这种情况就需要用到 CloseableReference.of 的另一个重载函数了，那么 ResourceReleaser 又是什么呢

public interface ResourceReleaser<T> {

  /**
   * Release the given value.
   *
   * <p>After calling this method, the caller is no longer responsible for managing lifetime of the
   * value.
   *
   * <p>This method is not permitted to throw an exception and is always required to succeed. It is
   * often called from contexts like catch blocks or finally blocks to cleanup resources. Throwing
   * an exception could result in swallowing the original exception.
   *
   * @param value
   */
  void release(T value);
}

其实就是一个对象释放器，这里配合 对象池 一起食用效果更佳。

源码分析

我们以最简单的使用方式分析一下主要流程。

引用构建

先从入口开始，即 CloseableReference.of，假设我们要关闭的是一个实现了 Closeable 接口的实例

public static <T extends Closeable> CloseableReference<T> of(@PropagatesNullable T t) {
  return of(t, (ResourceReleaser<T>) DEFAULT_CLOSEABLE_RELEASER);
}

如果是 Closeable 的子类，使用默认的 ResourceReleaser

private static final ResourceReleaser<Closeable> DEFAULT_CLOSEABLE_RELEASER = new ResourceReleaser<Closeable>() {
  @Override
  public void release(Closeable value) {
    try {
      Closeables.close(value, true);
    } catch (IOException ioe) {
    }
  }
};

处理非常简单，直接调用 close 方法。继续往下看

public static <T> CloseableReference<T> of(@PropagatesNullable T t, ResourceReleaser<T> resourceReleaser) {
  return of(t, resourceReleaser, DEFAULT_LEAK_HANDLER);
}

又调用了一个重载方法，传入了一个默认的 LeakHandler，LeakHandler 的作用主要是在 class 的 finalize() 方法中，判断引用是否关闭，如果未关闭则调用 LeakHandler.reportLeak 通知泄露。

@Override
protected void finalize() throws Throwable {
  if (mIsClosed) {
    return;
  }

  T ref = mSharedReference.get();
  mLeakHandler.reportLeak((SharedReference<Object>) mSharedReference, mStacktrace);
  close();
}

回到 CloseableReference 的构造流程，最终会调用到

public static <T> CloseableReference<T> of(T t, ResourceReleaser<T> resourceReleaser, LeakHandler leakHandler, Throwable stacktrace) {
  if (t == null) {
    return null;
  } else {
    if (t instanceof Bitmap || t instanceof HasBitmap) {
      switch (sBitmapCloseableRefType) {
        case REF_TYPE_FINALIZER:
          return new FinalizerCloseableReference<>(t, resourceReleaser, leakHandler, stacktrace);
        case REF_TYPE_REF_COUNT:
          return new RefCountCloseableReference<>(t, resourceReleaser, leakHandler, stacktrace);
        case REF_TYPE_NOOP:
          return new NoOpCloseableReference<>(t, resourceReleaser, leakHandler, stacktrace);
        case REF_TYPE_DEFAULT:
          // return default
      }
    }

    return new DefaultCloseableReference<>(t, resourceReleaser, leakHandler, stacktrace);
  }
}

这里做了 Bitmap 类型的判断，根据不同的回收策略，返回对应的 Reference，这里也不深入研究，感兴趣的同学可以去钻研下源码，我们继续分析默认的 DefaultCloseableReference 的构造函数

DefaultCloseableReference(T t, ResourceReleaser<T> resourceReleaser, LeakHandler leakHandler, Throwable stacktrace) {
  super(t, resourceReleaser, leakHandler, stacktrace);
}

直接调用了父类 CloseableReference 的构造方法

protected CloseableReference(T t, ResourceReleaser<T> resourceReleaser, LeakHandler leakHandler, Throwable stacktrace) {
  mSharedReference = new SharedReference<T>(t, resourceReleaser);
  mLeakHandler = leakHandler;
  mStacktrace = stacktrace;
}

这里主要是构造了一个 SharedReference 共享引用，保存了 leakHandler 和 stacktrace。

重点来了，对象自动回收的逻辑几乎都在 SharedReference 中，下面我们来一探究竟

public SharedReference(T value, ResourceReleaser<T> resourceReleaser) {
  mValue = Preconditions.checkNotNull(value);
  mResourceReleaser = Preconditions.checkNotNull(resourceReleaser);
  mRefCount = 1;
  addLiveReference(value);
}

构造方法中保存了实例和 ResourceReleaser 的引用，然后 mRefCount 引用计数 +1，看到这里大家是不是觉得很熟悉，没错，这不就是我们每次面试前都要看的「引用计数法」么，这其实就是 CloseableReference 的核心。

虽然我们基本了解了原理，但还是继续分析下完整流程，继续看 addLiveReference 方法做了什么

private static void addLiveReference(Object value) {
  Integer count = sLiveObjects.get(value);
  if (count == null) {
    sLiveObjects.put(value, 1);
  } else {
    sLiveObjects.put(value, count + 1);
  }
}

一看 s 开头的就知道是静态变量，这里再次把引用计数 +1，咦，前面不是已经 +1 了吗，这里为什么又有一个计数器，而且 key 是实例本身，那这个实例不是被静态变量持有了？

没错，作者的意图应该是防止实例被回收，所以用了一个全局的静态变量报错所有实例的计数。

到这里，引用构建的流程基本分析完了，下面来看一下克隆。

引用克隆

CloseableReference 的 clone 是一个抽象方法，看一下 DefaultCloseableReference 的实现

@Override
public CloseableReference<T> clone() {
  return new DefaultCloseableReference<T>(
      mSharedReference, mLeakHandler, mStacktrace != null ? new Throwable(mStacktrace) : null);
}

最终调用了父类的构造方法

protected CloseableReference(
    SharedReference<T> sharedReference, LeakHandler leakHandler, @Nullable Throwable stacktrace) {
  mSharedReference = Preconditions.checkNotNull(sharedReference);
  sharedReference.addReference();
  mLeakHandler = leakHandler;
  mStacktrace = stacktrace;
}

非常简单，相当于拷贝了一份对象，复用了计数器，并且将计数 +1。

引用关闭

直接看代码

@Override
public void close() {
  synchronized (this) {
    if (mIsClosed) {
      return;
    }
    mIsClosed = true;
  }

  mSharedReference.deleteReference();
}

首先将关闭的标记置为 TRUE，然后调用了 SharedReference 的 deleteReference，继续看

public void deleteReference() {
  if (decreaseRefCount() == 0) {
    T deleted;
    synchronized (this) {
      deleted = mValue;
      mValue = null;
    }
    if (deleted != null) {
      mResourceReleaser.release(deleted);
      removeLiveReference(deleted);
    }
  }
}

首先计数器 -1，如果计数变为 0，则调用 ResourceReleaser.release 释放实例，这里即是自动释放的触发点。

然后调用 removeLiveReference 更新静态计数器

private static void removeLiveReference(Object value) {
  synchronized (sLiveObjects) {
    Integer count = sLiveObjects.get(value);
    if (count == null) {
      // Uh oh.
    } else if (count == 1) {
      sLiveObjects.remove(value);
    } else {
      sLiveObjects.put(value, count - 1);
    }
  }
}

静态计数器 -1，如果计数变为 0，则移除实例的引用。

至此，整个实例的释放流程结束。

这里其实有一个问题，如果一个实例被多个 SharedReference 持有会怎么样？

如果一个 SharedReference 触发了回收操作，那么该实例就会被回收，其他引用对该实例的操作将不可控。

所以一定要注意，一个实例只能被一个引用持有，如果需要多个引用，用 clone 方法来构造，避免出现不可预知的错误！

总结

今天给大家分享了一个 Fresco 中的小彩蛋 —— 可关闭的引用，通过引用计数法，自动释放对象，避免出现无法确定对象释放时机的窘境。

另外，这里的可关闭引用只是为了方便我们安全的回收对象，如果想要复用对象，还需要配合 对象池 一起使用。

如果大家的项目没有依赖 Fresco 也没有关系，这里代码并不多，大概就3个类，而且没有强耦合，可以直接 copy 到项目中使用。

最后，感谢大家观看，如果觉得有用，欢迎点赞支持！

使用 CloseableReference 优雅的释放对象，来自

前言

使用

源码分析

引用构建

引用克隆

引用关闭

总结

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读