背景

在看square Leakcanary源码时,发现这样一段话:

GcTrigger DEFAULT = new GcTrigger() {
    @Override public void runGc() {
      // Code taken from AOSP FinalizationTest:
      // https://android.googlesource.com/platform/libcore/+/master/support/src/test/java/libcore/
      // java/lang/ref/FinalizationTester.java
      // System.gc() does not garbage collect every time. Runtime.gc() is
      // more likely to perfom a gc.
      Runtime.getRuntime().gc();
      enqueueReferences();
      System.runFinalization(); 
}

跟进

到底有什么不一样呢? 
我看了手头的4.2.2以及openjdk的源码:

public static void gc() {
        Runtime.getRuntime().gc();
}

System.gc()的实现就是调用Runtime.getRuntime().gc(),所以两者是等价的。所以这里是否是作者多虑了呢?我又看了一下5.0的源码,果然不一样了:

/**
 * Whether or not we need to do a GC before running the finalizers.
 */
  private static boolean runGC;


  /**
   * If we just ran finalization, we might want to do a GC to free the finalized objects.
   * This lets us do gc/runFinlization/gc sequences but prevents back to back System.gc().
   */
  private static boolean justRanFinalization;




/**
    * Provides a hint to the VM that it would be useful to attempt
    * to perform any outstanding object finalization.
    */
    public static void runFinalization() {
        boolean shouldRunGC;
        synchronized(lock) {
            shouldRunGC = runGC;
            runGC = false;
        }
        if (shouldRunGC) {
            Runtime.getRuntime().gc();
        }
        Runtime.getRuntime().runFinalization();
        synchronized(lock) {
            justRanFinalization = true;
        }
    }




 /**
   * Indicates to the VM that it would be a good time to run the
   * garbage collector. Note that this is a hint only. There is no guarantee
   * that the garbage collector will actually be run.
   */
  public static void gc() {
      boolean shouldRunGC;
      synchronized(lock) {
          shouldRunGC = justRanFinalization;
          if (shouldRunGC) {
              justRanFinalization = false;
        } else {
            runGC = true;
          }
    }
   if (shouldRunGC) {
          Runtime.getRuntime().gc();
   } 
}

这样改之后,单纯调用System.gc()是不会触发Runtime.getRuntime().gc()的。但是会把这次尝试纪录下来,等到下次调用System.runFinalization()时,会先执行这个Runtime.getRuntime().gc()。 
这样改后的影响至少有两点: 
1.单纯调用System.gc()是不会触发Runtime.getRuntime().gc()的,直到调用了System.runFinalization() 
2.System.gc() -> System.gc() -> … -> System.gc() ->System.runFinalization(),最终只会调用一次Runtime.getRuntime().gc()

为什么要这样改呢? 
找到了这个commit,是这样描述的:

Avoid running Runtime.gc() until we need to run finalization.


This prevents excessive explicit GC which are called from apps to get 
good GC behavior on Dalvik. Calling System.gc() does not help on ART 
since GC for alloc is much rarer.


If running finalizers is requested following a System.gc we remember 
that a GC was requested and perform it ahead of finalization.


Bug: 12004934

从这里可以得到两点信息: 
1.首先这是为了修复一个bug 12004934,具体什么bug找不到了 
2.其次在art模式下,直接调用gc的效果不大。至于为什么,还没有深入进去了解,这是ART相关的另外一个专题了,后面再详细跟进。

回到开头,leakcanary的作者在这里直接用了Runtime.getRuntime().gc()的确是有理由的,但是这应该不是最好的方式,因为从这个提交的描述来看,连续调用Runtime.getRuntime().gc()可能存在bug。修改后的模式是gc / finalization / gc,虽然leakcanary这里的使用不会有问题。但是我觉得我们自己使用的话,用System.gc() 配合 System.runFinalization()会比较好。


更多相关文章

  1. Android调用百度地图API实现――实时定位代码
  2. Android(安卓)之 setContentView 源码阅读
  3. android Json数据构建于解析
  4. 火爆新东西,仿QQ版本的ResideMenuItem框架(最新QQ版本的)
  5. Android积木之图片的生成和保存
  6. 从源码一次彻底理解Android的消息机制
  7. android实现退出时关闭所有activity
  8. Delphi XE5 Android(安卓)调用手机震动
  9. Android(安卓)requestFeature() must be called before adding c

随机推荐

  1. Android Toast提示封装
  2. [Android]查看KeyStore的MD5或SHA1签名
  3. Android(安卓)ApiDemos示例解析(106):Vie
  4. 深入了解Android图形管道-part2
  5. ORB_SLAM2在android studio上用cmake编译
  6. Android(安卓)有效的解决内存泄漏的问题
  7. Android GPS 获取
  8. Android bitmap内存优化测试
  9. Android 中 动画效果实现
  10. Android(java)学习笔记99:android的短信发送