小杨不想努力了
小杨不想努力了

内存泄漏+leakCanary

参考：https://carsonho.blog.csdn.net/article/details/79407707

       https://allenwu.itscoder.com/leakcanary-source

内存泄漏：

长期存活对象引用短期存活对象，导致短期存活对象占用的内存无法回收，这种现象称为内存泄漏。

内存溢出：

应用程序所需的内存超出了系统为其分配的内存限额的现象

常见的内存泄漏

  1. 集合类

    • 原因

      集合类添加元素后，仍引用着集合元素对象，导致该集合元素对象不可被回收，从而导致内存泄漏

    • 实例

      //通过 循环申请Object 对象 & 将申请的对象逐个放入到集合List
    List objectList = new ArrayList<>();        
       for (int i = 0; i < 10; i++) {
            Object o = new Object();
            objectList.add(o);
            o = null;
        }
//虽释放了集合元素引用的本身：o=null）
//但集合List仍然引用该对象，故垃圾回收器GC 依然不可回收该对象
  
    
    •  
      解决
       
      //集合类 添加集合元素对象后，在使用后必须从集合中删除
objectList.clear();
objectList=null;

       
      •  
     
  
    •  
      static关键字修饰的成员变量
       
   
         
    
      • 被 Static 关键字修饰的成员变量的生命周期 = 应用程序的生命周期
        •  
    
      •  
        原因
         
        若使被 Static 关键字修饰的成员变量 引用耗费资源过多的实例（如Context），则容易出现该成员变量的生命周期 > 引用实例生命周期的情况，当引用实例需结束生命周期销毁时，会因静态变量的持有而无法被回收，从而出现内存泄
         
        •  
    
      •  
        实例
         
        // 创建单例时，需传入一个Context
// 若传入的是Activity的Context，此时单例 则持有该Activity的引用
// 由于单例一直持有该Activity的引用（直到整个应用生命周期结束），即使该Activity退出，该Activity的内存也不会被回收
// 特别是一些庞大的Activity，此处非常容易导致OOM

public class SingleInstanceClass {    
    private static SingleInstanceClass instance;    
    private Context mContext;    
    private SingleInstanceClass(Context context) {        
        this.mContext = context; // 传递的是Activity的context
    }  
  
    public SingleInstanceClass getInstance(Context context) {        
        if (instance == null) {
            instance = new SingleInstanceClass(context);
        }        
        return instance;
    }
}
//单例模式 由于其静态特性，其生命周期的长度 = 应用程序的生命周期
//若1个对象已不需再使用 而单例对象还持有该对象的引用，那么该对象将不能被正常回收 从而 导致内存泄漏

         
        •  
    
      •  
        解决
         
        单例模式应该引用生命周期等于应用生命周期的对象。
         
        public class SingleInstanceClass {    
    private static SingleInstanceClass instance;    
    private Context mContext;    
    private SingleInstanceClass(Context context) {        
        this.mContext = context.getApplicationContext(); // 传递的是Application 的context
    }    

    public SingleInstanceClass getInstance(Context context) {        
        if (instance == null) {
            instance = new SingleInstanceClass(context);
        }        
        return instance;
    }
}

         
        •  
   
       
      •  
  
    •  
      非静态内部类/匿名类
       
      非静态内部类/匿名类默认持有外部类的引用；而静态内部类则不会
       
      常见3种情况，分别是：非静态内部类的实例 = 静态、多线程、消息传递机制（Handler）
       
   
         
    
      1.  
        非静态内部类的实例 = 静态
         
     
           
      
        •  
          原因
           
          若 非静态内部类所创建的实例 = 静态（其生命周期 = 应用的生命周期），会因 非静态内部类默认持有外部类的引用 而导致外部类无法释放，最终 造成内存泄露
           
          •  
      
        •  
          实例
           
          // 背景：
// a. 在启动频繁的Activity中，为了避免重复创建相同的数据资源，会在Activity内部创建一个非静态内部类的单例
// b. 每次启动Activity时都会使用该单例的数据

public class TestActivity extends AppCompatActivity {  
    
    // 非静态内部类的实例的引用
    // 注：设置为静态  
    public static InnerClass innerClass = null; 
   
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {        
        super.onCreate(savedInstanceState);   

        // 保证非静态内部类的实例只有1个
        if (innerClass == null)
            innerClass = new InnerClass();
    }

    // 非静态内部类的定义    
    private class InnerClass {        
        //...
    }
}

// 造成内存泄露的原因：
// a. 当TestActivity销毁时，因非静态内部类单例的引用（innerClass）的生命周期 = 应用App的生命周期、持有外部类TestActivity的引用
// b. 故 TestActivity无法被GC回收，从而导致内存泄漏

           
          •  
      
        •  
          解决:
           
       
             
        
          1. 将非静态内部类设置为：静态内部类（静态内部类默认不持有外部类的引用）
            2.  
        
          2. 该内部类抽取出来封装成一个单例
            3.  
        
          3. 尽量 避免 非静态内部类所创建的实例 = 静态
            4.  
       
           
          ps：若需使用Context，建议使用 Application 的 Context
           
          •  
     
         
        2.  
    
      2.  
        多线程：AsyncTask、实现Runnable接口、继承Thread类
         
     
           
      
        •  
          原因
           
          多线程的使用方法 = 非静态内部类 / 匿名类；即线程类属于非静态内部类 / 匿名类
           当工作线程正在处理任务，外部类需销毁时，由于工作线程实例持有外部类引用，将使得外部类无法被垃圾回收器（GC）回收，从而造成内存泄露
           
          •  
      
        •  
          实例
           
            /** 
   * 方式1：新建Thread子类（内部类）
   */  
    public class MainActivity extends AppCompatActivity {

    public static final String TAG = "carson：";
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        // 通过创建的内部类 实现多线程
        new MyThread().start();

    }
    // 自定义的Thread子类
    private class MyThread extends Thread{
        @Override
        public void run() {
            try {
                Thread.sleep(5000);
                Log.d(TAG, "执行了多线程");
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

 /** 
   * 方式2：匿名Thread内部类
   */ 
    public class MainActivity extends AppCompatActivity {

    public static final String TAG = "carson：";

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        // 通过匿名内部类 实现多线程
        new Thread() {
            @Override
            public void run() {
                try {
                    Thread.sleep(5000);
                    Log.d(TAG, "执行了多线程");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

            }
        }.start();
    }
}

/** 
* 分析：内存泄露原因
*/ 
// 工作线程Thread类属于非静态内部类 / 匿名内部类，运行时默认持有外部类的引用
// 当工作线程运行时，若外部类MainActivity需销毁
// 由于此时工作线程类实例持有外部类的引用，将使得外部类无法被垃圾回收器（GC）回收，从而造成 内存泄露

           
          •  
      
        •  
          解决方案1：静态内部类不默认持有外部类的引用，从而使得 “工作线程实例 持有外部类引用” 的引用关系 不复存在将Thread的子类设置成静态内部类
           
          /** 
 * 解决方式1：静态内部类
 * 原理：静态内部类 不默认持有外部类的引用，从而使得 “工作线程实例 持有 外部类引用” 的引用关系 不复存在
 * 具体实现：将Thread的子类设置成 静态内部类
 */  
  public class MainActivity extends AppCompatActivity {

  public static final String TAG = "carson：";
  @Override
  public void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_main);

      // 通过创建的内部类 实现多线程
      new MyThread().start();

  }
  // 分析1：自定义Thread子类
  // 设置为：静态内部类
  private static class MyThread extends Thread{
      @Override
      public void run() {
          try {
              Thread.sleep(5000);
              Log.d(TAG, "执行了多线程");
          } catch (InterruptedException e) {
              e.printStackTrace();
          }
      }
  }
}

/** 
 * 解决方案2：当外部类结束生命周期时，强制结束线程
 * 原理：使得 工作线程实例的生命周期 与 外部类的生命周期 同步
 * 具体实现：当 外部类（此处以Activity为例） 结束生命周期时（此时系统会调用onDestroy（）），强制结束线程（调用stop（））
 */ 
 @Override
  protected void onDestroy() {
      super.onDestroy();
      Thread.stop();
      // 外部类Activity生命周期结束时，强制结束线程
  }

           
          •  
      
        •  
          解决方案2：使得工作线程实例的生命周期 外部类的生命周期同步
           
          当外部类（此处以Activity为例） 结束生命周期时（此时系统会调用onDestroy()，强制结束线程（调用stop()）
           
           @Override
protected void onDestroy() {
       super.onDestroy();
       Thread.stop();
       // 外部类Activity生命周期结束时，强制结束线程
}

           
          •  
     
         
        3.  
    
      3.  
        Handler机制
         
     
           
      
        •  
          解决方案1
           
          静态内部类+弱引用
           
          private static class FHandler extends Handler{
        // 定义 弱引用实例
        private WeakReference reference;
        // 在构造方法中传入需持有的Activity实例
        public FHandler(Activity activity) {
            // 使用WeakReference弱引用持有Activity实例
            reference = new WeakReference(activity); 
        }
        // 通过复写handlerMessage() 从而确定更新UI的操作
        @Override
        public void handleMessage(Message msg) {
            switch (msg.what) {
                case 1:
                    Log.d(TAG, "收到线程1的消息");
                    break;
                case 2:
                    Log.d(TAG, " 收到线程2的消息");
                    break;
            }
        }
    }
//要使用静态内部类，不然可能会造成内存泄露。原因是非静态内部类会持有外部类的引用，而Handler发出的Message会持有Handler的引用。如果这个Message是个延迟的消息，此时activity被退出了，但Message依然在“流水线”上，Message->handler->activity（可达性分析法），那么activity就无法被回收，导致内存泄露。

           
          •  
      
        •  
          解决方案2
           
          当外部类结束生命周期时，清空Handler内消息队列
           
          @Override
protected void onDestroy() {
       super.onDestroy();
       mHandler.removeCallbacksAndMessages(null);
       // 外部类Activity生命周期结束时，同时清空消息队列 & 结束Handler生命周期
}

           
          •  
     
         
        4.  
    
      4.  
        资源使用后未关闭
         
     
           
      
        •  
          原因：
           
          对于资源的使用（如广播BraodcastReceiver、文件流File、数据库游标Cursor、图片资源Bitmap等），若在Activity销毁时无及时关闭/注销这些资源，则这些资源将不会被回收，从而造成内存泄漏。
           
          •  
      
        •  
          解决：
           
          // 对于 广播BraodcastReceiver：注销注册
unregisterReceiver()

// 对于 文件流File：关闭流
InputStream / OutputStream.close()

// 对于数据库游标cursor：使用后关闭游标
cursor.close（）

// 对于 图片资源Bitmap：Android分配给图片的内存只有8M，若1个Bitmap对象占内存较多，当它不再被使用时，应调用recycle()回收此对象的像素所占用的内存；最后再赋为null 
Bitmap.recycle()；
Bitmap = null;

// 对于动画（属性动画）
// 将动画设置成无限循环播放repeatCount = “infinite”后
// 在Activity退出时记得停止动画

           
          •  
     
         
        5.  
    
      5.  
        其他
         
     
         
      
         
       
          
       
         
      
         
      
        
        图片已经损坏 :< 
      
         
     
         
        6.  
   
       
      •  
  
 
      LeakCanary
       
 
      参考：https://zhuanlan.zhihu.com/p/57425510
       
 
      官方原理解释
       
 
      正常情况下一个Activity在执行Destroy之后就要销毁，LeakCanary做的就是在一个Activity 被Destroy之后将它放在一个WeakReference中，然后将这个WeakReference关联到一个ReferenceQueue，查看ReferenceQueue队列是否存在这个Activity的引用，如果不在这个队列中，执行一些GC清洗操作，再次查看。如果仍然不存在则证明该Activity泄漏了，之后Dump出heap信息，并用haha这个开源库去分析泄漏路径。
       
 
      基本原理
       
 
         
  
      1. LeakCanary通过 install() 方法初始化，主要是构造出一个RefWatcher，来监听Activity(ActivityRefWatcher） 或者Fragment(FragmentRefWatcher)
        2.  
  
      2. 监听Actvity，原理在于 Application 的registerActivityLifecycleCallbacks()，该方法可以对应用内所有 Activity 的生命周期做监听, LeakCanary只监听了Destroy()方法。
         在每个Activity的OnDestroy()方法中都会回调refWatcher.watch()方法。
        3.  
  
      3. watch()方法中先随机生成一个数作为key放在一个叫retainedKeys的set容器里面，用来区分待分析对象是否被回收。将弱引用和引用队列ReferenceQueue联合使用，如果弱引用持有的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。
         即 KeyedWeakReference持有的Activity对象如果被垃圾回收，该对象就会加入到引用队列中。
        4.  
  
      4. 避免因为gc不及时带来的误判，leakcanay会进行二次确认进行保证。首先清除此时已经到 RQ 的弱引用，调用 removeWeaklyReachableReferences()
         把已被回收的对象的 key 从 retainedKeys 移除，剩下的 key 都是未被回收的对象。
        5.  
  
      5. 通过gone(reference)判断当前弱引用对应的Activity是否已经被回收，如果已经回收说明activity没有泄漏，直接返回即可。
        6.  
  
      6. 如果当前检测对象没有改变其可达状态，则进行手动GC,再次清除已经到 RQ的弱引用,调用 removeWeaklyReachableReferences()；如果此时对象还没有到队列，则此时已经可能泄漏。
        7.  
  
      7. 将heap信息dump出来，抓取dump文件。
        8.  
  
      8. HeapAnalyzerService被开启在一个独立的进程中，并且HeapAnalyzer使用了HAHA开源库解析了指定时刻的堆栈快照文件heap dump。
        9.  
  
      9. 从heap dump中，HeapAnalyzer根据一个独特的引用key找到了KeyedWeakReference，并且定位了泄露的引用。
        10.  
  
      10. HeapAnalyzer为了确定是否有泄露，计算了到GC Roots的最短强引用路径，然后建立了导致泄露的链式引用。
        11.  
  
      11. 这个结果被传回到app进程中的DisplayLeakService，然后一个泄露通知便展现出来了。
        12.  
 
       
 
      源码分析（版本二更深入）
       
 
      版本一
       
 
      创建RefWatcher
       
 
      public final class LeakCanary {

    public static @NonNull RefWatcher install(@NonNull Application application) {
        return refWatcher(application) // 创建AndroidRefWatcherBuilder对象
            .listenerServiceClass(DisplayLeakService.class) // 配置监听分析结果的服务
            .excludedRefs(AndroidExcludedRefs.createAppDefaults().build()) // 配置排除的系统泄露
            .buildAndInstall(); // 创建一个Refwatcher并监听Activity的引用
    }
    // ...
}

       
 
      AndroidRefWatcherBuilder#buildAndInstall
       
 
      public final class AndroidRefWatcherBuilder extends RefWatcherBuilder {

    public @NonNull RefWatcher buildAndInstall() {
        if (LeakCanaryInternals.installedRefWatcher != null) {
            throw new UnsupportedOperationException("buildAndInstall() should only be called once.");
        }
        // 创建RefWatcher对象
        RefWatcher refWatcher = build();
        if (refWatcher != DISABLED) {
            if (enableDisplayLeakActivity) {
                LeakCanaryInternals.setEnabledAsync(context, DisplayLeakActivity.class, true);
            }
            if (watchActivities) {
                // 监听Activity的引用
                ActivityRefWatcher.install(context, refWatcher);
            }
            if (watchFragments) {
                // 监听Fragment的引用
                FragmentRefWatcher.Helper.install(context, refWatcher);
            }
        }
        LeakCanaryInternals.installedRefWatcher = refWatcher;
        return refWatcher;
    }
  // ...
}

       
 
      监听Activity的引用
       
 
      ActivityRefWatcher
       
 
      public final class ActivityRefWatcher {

    public static void install(@NonNull Context context, @NonNull RefWatcher refWatcher) {
        Application application = (Application) context.getApplicationContext();
        ActivityRefWatcher activityRefWatcher = new ActivityRefWatcher(application, refWatcher);

        application.registerActivityLifecycleCallbacks(activityRefWatcher.lifecycleCallbacks);
    }

    private final Application.ActivityLifecycleCallbacks lifecycleCallbacks = new ActivityLifecycleCallbacksAdapter() {

        @Override
        public void onActivityDestroyed(Activity activity) {
            // 在Activity执行完onDestroyed方法时，调用RefWatcher的watch来监控该Activity是否泄露
            refWatcher.watch(activity);
        }
    };
    // ...
}

       
 
      检查引用
       
 
      public final class RefWatcher {

    public static final RefWatcher DISABLED = new RefWatcherBuilder<>().build();

    // 线程控制器，在 onDestroy() 之后并且主线程空闲时执行内存泄漏检测
    private final WatchExecutor watchExecutor;
    // 判断是否处于调试模式，调试模式中不会进行内存泄漏检测，因为在调试过程中可能会保留上一个引用从而导致错误信息上报。
    private final DebuggerControl debuggerControl;
    // 用于主动触发GC操作
    private final GcTrigger gcTrigger;
    // 堆信息转储者，dump 内存泄漏处的 heap 信息到 hprof 文件
    private final HeapDumper heapDumper;
    private final HeapDump.Listener heapdumpListener;
    private final HeapDump.Builder heapDumpBuilder;
    // 保存每个被检测对象所对应的唯一key
    private final Set retainedKeys;
    // 引用队列，和WeakReference配合使用，当弱引用所引用的对象被GC回收，该弱引用就会被加入到这个队列
    private final ReferenceQueue queue;

    public void watch(Object watchedReference) {
        watch(watchedReference, "");
    }

    public void watch(Object watchedReference, String referenceName) {
        if (this == DISABLED) {
            return;
        }
        checkNotNull(watchedReference, "watchedReference");
        checkNotNull(referenceName, "referenceName");
        final long watchStartNanoTime = System.nanoTime();
        // 为被检测对象生成唯一的key值，并保存到retainedKeys
        String key = UUID.randomUUID().toString();
        retainedKeys.add(key);
        // 创建被检测对象的弱引用，并传入该对象的key
        final KeyedWeakReference reference = new KeyedWeakReference(watchedReference, key, referenceName, queue);

        // 异步检测这个对象是否被回收
        ensureGoneAsync(watchStartNanoTime, reference);
    }


    private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) {
        watchExecutor.execute(new Retryable() {
            @Override public Retryable.Result run() {
                return ensureGone(reference, watchStartNanoTime);
            }
        });
    }

    @SuppressWarnings("ReferenceEquality") // Explicitly checking for named null.
    Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) {
        long gcStartNanoTime = System.nanoTime();
        long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);

        // 移除对象已经被回收的弱引用
        removeWeaklyReachableReferences();

        // 调试模式检测不准确
        if (debuggerControl.isDebuggerAttached()) {
            // The debugger can create false leaks.
            return RETRY;
        }
        // 判断引用是否存在，不存在，表示被对象被回收
        if (gone(reference)) {
            return DONE;
        }
        // 触发GC
        gcTrigger.runGc();
        // GC后再移除对象已经被回收的弱引用
        removeWeaklyReachableReferences();
        // 如果该引用还存在，就表示对象已经泄露
        if (!gone(reference)) {
            long startDumpHeap = System.nanoTime();
            long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime);

            // dump出heap的内存快照
            File heapDumpFile = heapDumper.dumpHeap();
            if (heapDumpFile == RETRY_LATER) {
                // Could not dump the heap.
                return RETRY;
            }
            long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap);
            // 构建HeapDump对象
            HeapDump heapDump = heapDumpBuilder.heapDumpFile(heapDumpFile).referenceKey(reference.key)
                                               .referenceName(reference.name)
                                               .watchDurationMs(watchDurationMs)
                                               .gcDurationMs(gcDurationMs)
                                               .heapDumpDurationMs(heapDumpDurationMs)
                                               .build();
            // 分析HeapDump对象
            heapdumpListener.analyze(heapDump);
        }
        return DONE;
    }

    private boolean gone(KeyedWeakReference reference) {
        return !retainedKeys.contains(reference.key);
    }

    private void removeWeaklyReachableReferences() {
        KeyedWeakReference ref;
        // 当弱引用所引用的对象被回收，就会把该引用放到queue中，所以可以通过queue来判断对象是否被回收
        while ((ref = (KeyedWeakReference) queue.poll()) != null) {
            retainedKeys.remove(ref.key);
        }
    }
    // ...
}
 
 
      Dump Heap
       
 
       
  
      AndroidHeapDumper是HeapDumper的实现类。
       
 
       
 
      public final class AndroidHeapDumper implements HeapDumper {
    
    @Override @Nullable
    public File dumpHeap() {
        File heapDumpFile = leakDirectoryProvider.newHeapDumpFile();

        if (heapDumpFile == RETRY_LATER) {
            return RETRY_LATER;
        }
        // ...
        try {
            // 生成.hprof文件
            Debug.dumpHprofData(heapDumpFile.getAbsolutePath());
            cancelToast(toast);
            notificationManager.cancel(notificationId);
            return heapDumpFile;
        } catch (Exception e) {
            CanaryLog.d(e, "Could not dump heap");
            // Abort heap dump
            return RETRY_LATER;
        }
    }

    // ...
}

       
 
      解析hprof
       
 
      public final class ServiceHeapDumpListener implements HeapDump.Listener {
    // ...
    @Override 
    public void analyze(@NonNull HeapDump heapDump) {
        checkNotNull(heapDump, "heapDump");
        // 启动HeapAnalyzerServiceService来分析heapDump
        HeapAnalyzerService.runAnalysis(context, heapDump, listenerServiceClass);
    }
}
public final class HeapAnalyzerService extends ForegroundService implements AnalyzerProgressListener {
    // ...

    public static void runAnalysis(Context context, HeapDump heapDump,  Class listenerServiceClass) {
        setEnabledBlocking(context, HeapAnalyzerService.class, true);
        setEnabledBlocking(context, listenerServiceClass, true);
        Intent intent = new Intent(context, HeapAnalyzerService.class);
        intent.putExtra(LISTENER_CLASS_EXTRA, listenerServiceClass.getName());
        intent.putExtra(HEAPDUMP_EXTRA, heapDump);
        ContextCompat.startForegroundService(context, intent);
    }

    @Override 
    protected void onHandleIntentInForeground(@Nullable Intent intent) {
        if (intent == null) {
            CanaryLog.d("HeapAnalyzerService received a null intent, ignoring.");
            return;
        }
        String listenerClassName = intent.getStringExtra(LISTENER_CLASS_EXTRA);
        HeapDump heapDump = (HeapDump) intent.getSerializableExtra(HEAPDUMP_EXTRA);

        HeapAnalyzer heapAnalyzer = new HeapAnalyzer(heapDump.excludedRefs, this, heapDump.reachabilityInspectorClasses);

        // 分析内存泄露的地方
        AnalysisResult result = heapAnalyzer.checkForLeak(heapDump.heapDumpFile, heapDump.referenceKey, heapDump.computeRetainedHeapSize);
        // 发送内存泄露检测结果的通知
        AbstractAnalysisResultService.sendResultToListener(this, listenerClassName, heapDump, result);
    }
}
public final class HeapAnalyzer {
    // ...

    public @NonNull AnalysisResult checkForLeak(@NonNull File heapDumpFile, @NonNull String referenceKey, boolean computeRetainedSize) {
        long analysisStartNanoTime = System.nanoTime();

        if (!heapDumpFile.exists()) {
            Exception exception = new IllegalArgumentException("File does not exist: " + heapDumpFile);
            return failure(exception, since(analysisStartNanoTime));
        }

        try {
            listener.onProgressUpdate(READING_HEAP_DUMP_FILE);
            // 使用haha库解析.hprof文件
            HprofBuffer buffer = new MemoryMappedFileBuffer(heapDumpFile);
            HprofParser parser = new HprofParser(buffer);
            listener.onProgressUpdate(PARSING_HEAP_DUMP);
            // 解析.hprof文件生成对应的快照对象
            Snapshot snapshot = parser.parse();
            listener.onProgressUpdate(DEDUPLICATING_GC_ROOTS);
            // 删除gcRoots中重复的根对象RootObj
            deduplicateGcRoots(snapshot);
            listener.onProgressUpdate(FINDING_LEAKING_REF);
            // 检查对象是否泄露
            Instance leakingRef = findLeakingReference(referenceKey, snapshot);

            // leakingRef为空表示对象没有泄露
            if (leakingRef == null) {
                String className = leakingRef.getClassObj().getClassName();
                return noLeak(className, since(analysisStartNanoTime));
            }
            // 查找引用链
            return findLeakTrace(analysisStartNanoTime, snapshot, leakingRef, computeRetainedSize);
        } catch (Throwable e) {
            return failure(e, since(analysisStartNanoTime));
        }
    }
}

       
 
      定位泄露的引用
       
 
      public final class HeapAnalyzer {
    // ...

    private Instance findLeakingReference(String key, Snapshot snapshot) {
        ClassObj refClass = snapshot.findClass(KeyedWeakReference.class.getName());
        if (refClass == null) {
            throw new IllegalStateException(
                    "Could not find the " + KeyedWeakReference.class.getName() + " class in the heap dump.");
        }
        List keysFound = new ArrayList<>();
        for (Instance instance : refClass.getInstancesList()) {
            List values = classInstanceValues(instance);
            Object keyFieldValue = fieldValue(values, "key");
            if (keyFieldValue == null) {
                keysFound.add(null);
                continue;
            }
            String keyCandidate = asString(keyFieldValue);
            if (keyCandidate.equals(key)) {
                return fieldValue(values, "referent");
            }
            keysFound.add(keyCandidate);
        }
        throw new IllegalStateException("Could not find weak reference with key " + key + " in " + keysFound);
    }
}

       
 
      建立引用链
       
 
      public final class HeapAnalyzer {
    // ...

    private AnalysisResult findLeakTrace(long analysisStartNanoTime, Snapshot snapshot, Instance leakingRef, boolean computeRetainedSize) {

        listener.onProgressUpdate(FINDING_SHORTEST_PATH);
        // 查找到GC Roots的最短引用路径
        ShortestPathFinder pathFinder = new ShortestPathFinder(excludedRefs);
        ShortestPathFinder.Result result = pathFinder.findPath(snapshot, leakingRef);

        String className = leakingRef.getClassObj().getClassName();

        // False alarm, no strong reference path to GC Roots.
        if (result.leakingNode == null) {
            return noLeak(className, since(analysisStartNanoTime));
        }

        listener.onProgressUpdate(BUILDING_LEAK_TRACE);
        // 构建泄露的引用链
        LeakTrace leakTrace = buildLeakTrace(result.leakingNode);

        long retainedSize;
        if (computeRetainedSize) {

            listener.onProgressUpdate(COMPUTING_DOMINATORS);
            // 计算内存泄露的大小
            snapshot.computeDominators();

            Instance leakingInstance = result.leakingNode.instance;

            retainedSize = leakingInstance.getTotalRetainedSize();

            // TODO: check O sources and see what happened to android.graphics.Bitmap.mBuffer
            if (SDK_INT <= N_MR1) {
                listener.onProgressUpdate(COMPUTING_BITMAP_SIZE);
                retainedSize += computeIgnoredBitmapRetainedSize(snapshot, leakingInstance);
            }
        } else {
            retainedSize = AnalysisResult.RETAINED_HEAP_SKIPPED;
        }

        return leakDetected(result.excludingKnownLeaks, className, leakTrace, retainedSize, since(analysisStartNanoTime));
    }

}

       
 
      展示分析结果
       
 
      public class DisplayLeakService extends AbstractAnalysisResultService {
    // ...

    @Override
    protected final void onHeapAnalyzed(@NonNull AnalyzedHeap analyzedHeap) {
        HeapDump heapDump = analyzedHeap.heapDump;
        AnalysisResult result = analyzedHeap.result;

        String leakInfo = leakInfo(this, heapDump, result, true);
        CanaryLog.d("%s", leakInfo);

        heapDump = renameHeapdump(heapDump);
        boolean resultSaved = saveResult(heapDump, result);

        String contentTitle;
        if (resultSaved) {
            PendingIntent pendingIntent = DisplayLeakActivity.createPendingIntent(this, heapDump.referenceKey);
            if (result.failure != null) {
                contentTitle = getString(R.string.leak_canary_analysis_failed);
            } else {
                String className = classSimpleName(result.className);
                // ...
            }
            String contentText = getString(R.string.leak_canary_notification_message);
            showNotification(pendingIntent, contentTitle, contentText);
        } else {
            onAnalysisResultFailure(getString(R.string.leak_canary_could_not_save_text));
        }

        afterDefaultHandling(heapDump, result, leakInfo);
    }

    @Override 
    protected final void onAnalysisResultFailure(String failureMessage) {
        super.onAnalysisResultFailure(failureMessage);
        String failureTitle = getString(R.string.leak_canary_result_failure_title);
        showNotification(null, failureTitle, failureMessage);
    }
}

       
 
      总结
       
 
       
  
       
   
        
   
       
  
       
  
      
    img 
  
       
 
       
 
      版本二
       
 
      https://jsonchao.github.io/2019/01/06/Android%E4%B8%BB%E6%B5%81%E4%B8%89%E6%96%B9%E5%BA%93%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%EF%BC%88%E5%85%AD%E3%80%81%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3Leakcanary%E6%BA%90%E7%A0%81%EF%BC%89/
       
 
         
  
      1.  
        LeakCanary#install()
         
        public static @NonNull RefWatcher install(@NonNull Application application) {
  return refWatcher(application)// 创建AndroidRefWatcherBuilder对象
      .listenerServiceClass(DisplayLeakService.class)// 配置监听分析结果的服务
      .excludedRefs(AndroidExcludedRefs.createAppDefaults().build())// 配置排除的系统泄露
      .buildAndInstall();// 创建一个Refwatcher并监听Activity的引用
}

         
        在install()方法中，可以理解为如下4步骤
         
   
           
    
        1. refWatcher(application)
          2.  
    
        2. 链式调用listenerServiceClass(DisplayLeakService.class)
          3.  
    
        3. 链式调用excludedRefs(AndroidExcludedRefs.createAppDefaults().build())
          4.  
    
        4. 链式调用buildAndInstall()
          5.  
   
         
        首先，我们来看下第一步，这里调用了LeakCanary类的refWatcher方法，如下所示：
         
        public static @NonNull AndroidRefWatcherBuilder refWatcher(@NonNull Context context) {
  return new AndroidRefWatcherBuilder(context);
}

         
        然后新建了一个AndroidRefWatcherBuilder对象，再看看AndroidRefWatcherBuilder这个类。
         
        2.  
  
      2.  
        AndroidRefWatcherBuilder
         
        /** A {@link RefWatcherBuilder} with appropriate Android defaults. */
public final class AndroidRefWatcherBuilder extends RefWatcherBuilder {
...
    AndroidRefWatcherBuilder(@NonNull Context context) {
        this.context = context.getApplicationContext();
    }
...
}

         
        在AndroidRefWatcherBuilder的构造方法中仅仅是将外部传入的applicationContext对象保存起来了。AndroidRefWatcherBuilder是一个适配Android平台的引用观察者构造器对象，它继承了RefWatcherBuilder，RefWatcherBuilder是一个负责建立引用观察者RefWatcher实例的基类构造器。继续看看RefWatcherBuilder这个类。
         
        3.  
  
      3.  
        RefWatchBuilder
         
        public class RefWatcherBuilder> {
    ...
    public RefWatcherBuilder() {
        heapDumpBuilder = new HeapDump.Builder();
    }
    ...
}

         
        在RefWatcher的基类构造器RefWatcherBuilder的构造方法中新建了一个HeapDump的构造器对象。其中HeapDump就是一个保存heap dump信息的数据结构。
         
        接着来分析下install()方法中的链式调用的listenerServiceClass(DisplayLeakService.class)这部分逻辑。
         
        4.  
  
      4.  
        AndroidRefWatcherBuilder#listenerServiceClass()
         
        public @NonNull AndroidRefWatcherBuilder listenerServiceClass(
  @NonNull Class listenerServiceClass) {
    return heapDumpListener(new ServiceHeapDumpListener(context, listenerServiceClass));
}

         
        在这里，传入了一个DisplayLeakService的Class对象，它的作用是展示泄露分析的结果日志，然后会展示一个用于跳转到显示泄露界面DisplayLeakActivity的通知。在listenerServiceClass()这个方法中新建了一个ServiceHeapDumpListener对象，看看它内部的操作。
         
        5.  
  
      5.  
        ServiceHeapDumpListener
         
        public final class ServiceHeapDumpListener implements HeapDump.Listener {
    ...
    public ServiceHeapDumpListener(@NonNull final Context context,
        @NonNull final Class listenerServiceClass) {
      this.listenerServiceClass = checkNotNull(listenerServiceClass, "listenerServiceClass");
      this.context = checkNotNull(context, "context").getApplicationContext();
    }
    ...
}

         
        可以看到这里仅仅是在ServiceHeapDumpListener中保存了DisplayLeakService的Class对象和application对象。它的作用就是接收一个heap dump去分析。
         
        然后我们继续看install()方法链式调用.excludedRefs(AndroidExcludedRefs.createAppDefaults().build())的这部分代码。先看AndroidExcludedRefs.createAppDefaults()。
         
        6.  
  
      6.  
        AndroidExcludedRefs#createAppDefaults()
         
        public enum AndroidExcludedRefs {
    ...
    public static @NonNull ExcludedRefs.Builder createAppDefaults() {
      return createBuilder(EnumSet.allOf(AndroidExcludedRefs.class));
    }
    public static @NonNull ExcludedRefs.Builder createBuilder(EnumSet refs) {
      ExcludedRefs.Builder excluded = ExcludedRefs.builder();
      for (AndroidExcludedRefs ref : refs) {
        if (ref.applies) {
          ref.add(excluded);
          ((ExcludedRefs.BuilderWithParams) excluded).named(ref.name());
        }
      }
      return excluded;
    }
    ...
}

         
        先来说下AndroidExcludedRefs这个类，它是一个enum类，它声明了Android SDK和厂商定制的SDK中存在的内存泄露的case，根据AndroidExcludedRefs这个类的类名就可看出这些case都会被Leakcanary的监测过滤掉。目前这个版本是有46种这样的case被包含在内，后续可能会一直增加。然后EnumSet.allOf(AndroidExcludedRefs.class)这个方法将会返回一个包含AndroidExcludedRefs元素类型的EnumSet。Enum是一个抽象类，在这里具体的实现类是通用正规型的RegularEnumSet，如果Enum里面的元素个数大于64，则会使用存储大数据量的JumboEnumSet。最后，在createBuilder这个方法里面构建了一个排除引用的建造器excluded，将各式各样的case分门别类地保存起来再返回出去。
         
        最后，我们看到链式调用的最后一步buildAndInstall()。
         
        7.  
  
      7.  
        AndroidRefWatcherBuilder#buildAndInstall()
         
        private boolean watchActivities = true;
private boolean watchFragments = true;

public @NonNull RefWatcher buildAndInstall() {
    // 1
    if (LeakCanaryInternals.installedRefWatcher != null) {
      throw new UnsupportedOperationException("buildAndInstall() should only be called once.");
    }

    // 2 创建RefWatcher对象
    RefWatcher refWatcher = build();
    if (refWatcher != DISABLED) {
      // 3
      LeakCanaryInternals.setEnabledAsync(context, DisplayLeakActivity.class, true);
      if (watchActivities) {
        // 4 监听Activity的引用
        ActivityRefWatcher.install(context, refWatcher);
      }
      if (watchFragments) {
        // 5 监听Fragment的引用
        FragmentRefWatcher.Helper.install(context, refWatcher);
      }
    }
    // 6
    LeakCanaryInternals.installedRefWatcher = refWatcher;
    return refWatcher;
}

         
        首先，在注释1处，会判断LeakCanaryInternals.installedRefWatcher是否已经被赋值，如果被赋值了，则会抛出异常，警告buildAndInstall()这个方法应该仅仅只调用一次，在此方法结束时，即在注释6处，该LeakCanaryInternals.installedRefWatcher才会被赋值。再来看注释2处，调用了AndroidRefWatcherBuilder其基类RefWatcherBuilder的build()方法，我们它是如何建造的。
         
        8.  
  
      8.  
        RefWatcherBuilder#build()
         
        public final RefWatcher build() {
    if (isDisabled()) {
      return RefWatcher.DISABLED;
    }

    if (heapDumpBuilder.excludedRefs == null) {
      heapDumpBuilder.excludedRefs(defaultExcludedRefs());
    }

    HeapDump.Listener heapDumpListener = this.heapDumpListener;
    if (heapDumpListener == null) {
      heapDumpListener = defaultHeapDumpListener();
    }

    DebuggerControl debuggerControl = this.debuggerControl;
    if (debuggerControl == null) {
      debuggerControl = defaultDebuggerControl();
    }

    HeapDumper heapDumper = this.heapDumper;
    if (heapDumper == null) {
      heapDumper = defaultHeapDumper();
    }

    WatchExecutor watchExecutor = this.watchExecutor;
    if (watchExecutor == null) {
      watchExecutor = defaultWatchExecutor();
    }

    GcTrigger gcTrigger = this.gcTrigger;
    if (gcTrigger == null) {
      gcTrigger = defaultGcTrigger();
    }

    if (heapDumpBuilder.reachabilityInspectorClasses == null) {
      heapDumpBuilder.reachabilityInspectorClasses(defa  ultReachabilityInspectorClasses());
    }

    return new RefWatcher(watchExecutor, debuggerControl, gcTrigger, heapDumper, heapDumpListener,
        heapDumpBuilder);
}

         
        可以看到，RefWatcherBuilder包含了7个组成部分
         
   
           
    
        • 1、excludedRefs : 记录可以被忽略的泄漏路径。
          •  
    
        • 2、heapDumpListener : 转储堆信息到hprof文件，并在解析完 hprof 文件后进行回调，最后通知 DisplayLeakService 弹出泄漏提醒。
          •  
    
        • 3、debuggerControl : 判断是否处于调试模式，调试模式中不会进行内存泄漏检测。为什么呢？因为在调试过程中可能会保留上一个引用从而导致错误信息上报。
          •  
    
        • 4、heapDumper : 堆信息转储者，dump 内存泄漏处的 heap 信息到 hprof 文件
          •  
    
        • 5、watchExecutor : 线程控制器，在 onDestroy() 之后并且主线程空闲时执行内存泄漏检测
          •  
    
        • 6、gcTrigger : 用于 GC，watchExecutor 首次检测到可能的内存泄漏，会主动进行 GC，GC 之后会再检测一次，仍然泄漏的判定为内存泄漏，最后根据heapDump信息生成相应的泄漏引用链。
          •  
    
        • 7、reachabilityInspectorClasses : 用于要进行可达性检测的类列表。
          •  
   
         
        最后，会使用建造者模式将这些组成部分构建成一个新的RefWatcher并将其返回。
         
        我们继续看回到AndroidRefWatcherBuilder的注释3处的 LeakCanaryInternals.setEnabledAsync(context, DisplayLeakActivity.class, true)这行代码。
         
        9.  
  
      9.  
        LeakCanaryInternals#setEnabledAsync()
         
        public static void setEnabledAsync(Context context, final Class componentClass,
final boolean enabled) {
  final Context appContext = context.getApplicationContext();
  AsyncTask.THREAD_POOL_EXECUTOR.execute(new Runnable() {
    @Override public void run() {
      setEnabledBlocking(appContext, componentClass, enabled);
    }
  });
}

         
        在这里使用了AsyncTask内部自带的THREAD_POOL_EXECUTOR线程池进行阻塞式地显示DisplayLeakActivity。
         
        然后我们再继续看AndroidRefWatcherBuilder的注释4处的代码。
         
        10.  
  
      10.  
        ActivityRefWatcher#install()
         
        public static void install(@NonNull Context context, @NonNull RefWatcher refWatcher) {
    Application application = (Application) context.getApplicationContext();
    // 1
    ActivityRefWatcher activityRefWatcher = new ActivityRefWatcher(application, refWatcher);

    // 2
    application.registerActivityLifecycleCallbacks(activityRefWatcher.lifecycleCallbacks);
}

         
        可以看到，在注释1处创建一个自己的activityRefWatcher实例，并在注释2处调用了application的registerActivityLifecycleCallbacks()方法，这样就能够监听activity对应的生命周期事件了。继续看看activityRefWatcher.lifecycleCallbacks里面的操作。
         
        private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
    new ActivityLifecycleCallbacksAdapter() {
      @Override public void onActivityDestroyed(Activity activity) {
          refWatcher.watch(activity);
      }
};

public abstract class ActivityLifecycleCallbacksAdapter implements Application.ActivityLifecycleCallbacks {

}

         
        很明显，实现并重写了Application的ActivityLifecycleCallbacks的onActivityDestroyed()方法，这样便能在所有Activity执行完onDestroyed()方法之后调用 refWatcher.watch(activity)这行代码进行内存泄漏的检测了。
         
        我们再看到注释5处的FragmentRefWatcher.Helper.install(context, refWatcher)这行代码。
         
        11.  
  
      11.  
        FragmentRefWatcher.Helper#install()
         
        public interface FragmentRefWatcher {
    void watchFragments(Activity activity);
    final class Helper {
      private static final String SUPPORT_FRAGMENT_REF_WATCHER_CLASS_NAME =
          "com.squareup.leakcanary.internal.SupportFragmentRefWatcher";
      public static void install(Context context, RefWatcher refWatcher) {
        List fragmentRefWatchers = new ArrayList<>();
        // 1
        if (SDK_INT >= O) {
          fragmentRefWatchers.add(new AndroidOFragmentRefWatcher(refWatcher));
        }
        // 2
        try {
          Class fragmentRefWatcherClass = Class.forName(SUPPORT_FRAGMENT_REF_WATCHER_CLASS_NAME);
          Constructor constructor =
              fragmentRefWatcherClass.getDeclaredConstructor(RefWatcher.class);
          FragmentRefWatcher supportFragmentRefWatcher   =
              (FragmentRefWatcher) constructor.newInstance(refWatcher);
          fragmentRefWatchers.add(supportFragmentRefWatcher);
        } catch (Exception ignored) {
        }
        if (fragmentRefWatchers.size() == 0) {
          return;
        }
        Helper helper = new Helper(fragmentRefWatchers);
        // 3
        Application application = (Application) context.getApplicationContext();
        application.registerActivityLifecycleCallbacks(helper.activityLifecycleCallbacks);
      }
    ...
}

         
        这里面的逻辑很简单，首先在注释1处将Android标准的Fragment的RefWatcher类，即AndroidOFragmentRefWatcher添加到新创建的fragmentRefWatchers中。在注释2处使用反射将leakcanary-support-fragment包下面的SupportFragmentRefWatcher添加进来，如果你在app的build.gradle下没有添加下面这行引用的话，则会拿不到此类，即LeakCanary只会检测Activity和标准Fragment这两种情况。
         
        debugImplementation   'com.squareup.leakcanary:leakcanary-support-fragment:1.6.2'

         
        继续看到注释3处helper.activityLifecycleCallbacks里面的代码。
         
        private final Application.ActivityLifecycleCallbacks activityLifecycleCallbacks =
    new ActivityLifecycleCallbacksAdapter() {
      @Override public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
        for (FragmentRefWatcher watcher : fragmentRefWatchers) {
            watcher.watchFragments(activity);
        }
    }
};

         
        可以看到，在Activity执行完onActivityCreated()方法之后，会调用指定watcher的watchFragments()方法，注意，这里的watcher可能有两种，但不管是哪一种，都会使用当前传入的activity获取到对应的FragmentManager/SupportFragmentManager对象，调用它的registerFragmentLifecycleCallbacks()方法，在对应的onDestroyView()和onDestoryed()方法执行完后，分别使用refWatcher.watch(view)和refWatcher.watch(fragment)进行内存泄漏的检测，代码如下所示。
         
        @Override public void onFragmentViewDestroyed(FragmentManager fm, Fragment fragment) {
    View view = fragment.getView();
    if (view != null) {
        refWatcher.watch(view);
    }
}

@Override
public void onFragmentDestroyed(FragmentManagerfm, Fragment fragment) {
    refWatcher.watch(fragment);
}

         
        注意，下面到真正关键的地方了，接下来分析refWatcher.watch()这行代码。
         
        12.  
  
      12.  
        RefWatcher#watch()
         
        public void watch(Object watchedReference, String referenceName) {
    if (this == DISABLED) {
      return;
    }
    checkNotNull(watchedReference, "watchedReference");
    checkNotNull(referenceName, "referenceName");
    final long watchStartNanoTime = System.nanoTime();
    // 1
    String key = UUID.randomUUID().toString();
    // 2
    retainedKeys.add(key);
    // 3
    final KeyedWeakReference reference =
        new KeyedWeakReference(watchedReference, key, referenceName, queue);
    // 4
    ensureGoneAsync(watchStartNanoTime, reference);
}

         
        注意到在注释1处使用随机的UUID保证了每个检测对象对应的
         key 的唯一性。在注释2处将生成的key添加到类型为CopyOnWriteArraySet的Set集合中。在注释3处新建了一个自定义的弱引用KeyedWeakReference，看看它内部的实现。
         
        13.  
  
      13.  
        KeyedWeakReference
         
        final class KeyedWeakReference extends WeakReference {
    public final String key;
    public final String name;

    KeyedWeakReference(Object referent, String key, String name,
        ReferenceQueue referenceQueue) {
      // 1
      super(checkNotNull(referent, "referent"), checkNotNull(referenceQueue, "referenceQueue"));
      this.key = checkNotNull(key, "key");
      this.name = checkNotNull(name, "name");
    }
}
 
        可以看到，在KeyedWeakReference内部，使用了key和name标识了一个被检测的WeakReference对象。在注释1处，将弱引用和引用队列 ReferenceQueue 关联起来，如果弱引用referent持有的对象被GC回收，JVM就会把这个弱引用加入到与之关联的引用队列referenceQueue中。即 KeyedWeakReference 持有的 Activity 对象如果被GC回收，该对象就会加入到引用队列 referenceQueue 中。
         
        接着我们回到RefWatcher.watch()里注释4处的ensureGoneAsync()方法。
          
  
      14.  
        RefWatcher#ensureGoneAsync()
         
        private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) {
    // 1
    watchExecutor.execute(new Retryable() {
        @Override public Retryable.Result run() {
            // 2
            return ensureGone(reference watchStartNanoTime);
        }
    });
}

         
        在ensureGoneAsync()方法中，在注释1处使用 watchExecutor 执行了注释2处的 ensureGone 方法，watchExecutor 是 AndroidWatchExecutor 的实例。
         
        下面看看watchExecutor内部的逻辑。
         
        15.  
  
      15.  
        AndroidWatchExecutor
         
        public final class AndroidWatchExecutor implements WatchExecutor {
    ...
    public AndroidWatchExecutor(long initialDelayMillis)     {
      mainHandler = new Handler(Looper.getMainLooper());
      HandlerThread handlerThread = new HandlerThread(LEAK_CANARY_THREAD_NAME);
      handlerThread.start();
      // 1
      backgroundHandler = new Handler(handlerThread.getLooper());
      this.initialDelayMillis = initialDelayMillis;
      maxBackoffFactor = Long.MAX_VALUE / initialDelayMillis;
    }

    @Override public void execute(@NonNull Retryable retryable) {
      // 2
      if (Looper.getMainLooper().getThread() == Thread.currentThread()) {
        waitForIdle(retryable, 0);
      } else {
        postWaitForIdle(retryable, 0);
      }
    }
    ...
}

         
        在注释1处AndroidWatchExecutor的构造方法中，注意到这里使用HandlerThread的looper新建了一个backgroundHandler，后面会用到。在注释2处，会判断当前线程是否是主线程，如果是，则直接调用waitForIdle()方法，如果不是，则调用postWaitForIdle()，来看看这个方法。
         
        private void postWaitForIdle(final Retryable retryable, final int failedAttempts) {
  mainHandler.post(new Runnable() {
    @Override public void run() {
      waitForIdle(retryable, failedAttempts);
    }
  });
}

         
        很清晰，这里使用了在构造方法中用主线程looper构造的mainHandler进行post，那么waitForIdle()最终也会在主线程执行。接着看看waitForIdle()的实现。
         
        private void waitForIdle(final Retryable retryable,     final int failedAttempts) {
  Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {
    @Override public boolean queueIdle() {
      postToBackgroundWithDelay(retryable, failedAttempts);
      return false;
    }
  });
}

         
        这里MessageQueue.IdleHandler()回调方法的作用是当 looper 空闲的时候，会回调 queueIdle 方法，然后执行内部的postToBackgroundWithDelay()方法。接下来看看它的实现。
         
        private void postToBackgroundWithDelay(final Retryable retryable, final int failedAttempts) {
  long exponentialBackoffFactor = (long) Math.min(Math.pow(2, failedAttempts),     maxBackoffFactor);
  // 1
  long delayMillis = initialDelayMillis * exponentialBackoffFactor;
  // 2
  backgroundHandler.postDelayed(new Runnable() {
    @Override public void run() {
      // 3
      Retryable.Result result = retryable.run();
      // 4
      if (result == RETRY) {
        postWaitForIdle(retryable, failedAttempts +   1);
      }
    }
  }, delayMillis);
}

         
        先看到注释4处，可以明白，postToBackgroundWithDelay()是一个递归方法，如果result 一直等于RETRY的话，则会一直执行postWaitForIdle()方法。在回到注释1处，这里initialDelayMillis 的默认值是 5s，因此delayMillis就是5s。在注释2处，使用了在构造方法中用HandlerThread的looper新建的backgroundHandler进行异步延时执行retryable的run()方法。这个run()方法里执行的就是RefWatcher的ensureGoneAsync()方法中注释2处的ensureGone()这行代码，继续看它内部的逻辑。
         
        16.  
  
      16.  
        RefWatcher#ensureGone()
         
        Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) {
    long gcStartNanoTime = System.nanoTime();
    long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime -     watchStartNanoTime);

    // 1
    removeWeaklyReachableReferences();

    // 2
    if (debuggerControl.isDebuggerAttached()) {
      // The debugger can create false leaks.
      return RETRY;
    }

    // 3
    if (gone(reference)) {
      return DONE;
    }

    // 4
    gcTrigger.runGc();
    removeWeaklyReachableReferences();

    // 5
    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;
}

         
        在注释1处，执行了removeWeaklyReachableReferences()这个方法，接下来分析下它的含义。
         
        private void removeWeaklyReachableReferences() {
    KeyedWeakReference ref;
    while ((ref = (KeyedWeakReference) queue.poll()) != null) {
        retainedKeys.remove(ref.key);
    }
}

         
        这里使用了while循环遍历 ReferenceQueue ，并从 retainedKeys中移除对应的Reference。
         
        再看到注释2处，当Android设备处于debug状态时，会直接返回RETRY进行延时重试检测的操作。在注释3处，我们看看gone(reference)这个方法的逻辑。
         
        private boolean gone(KeyedWeakReference reference) {
    return !retainedKeys.contains(reference.key);
}

         
        这里会判断 retainedKeys 集合中是否还含有 reference，若没有，证明已经被回收了，若含有，可能已经发生内存泄露（或Gc还没有执行回收）。前面的分析中我们知道了 reference 被回收的时候，会被加进 referenceQueue 里面，然后我们会调用removeWeaklyReachableReferences()遍历 referenceQueue 移除掉 retainedKeys 里面的 refrence。
         
        接着我们看到注释4处，执行了gcTrigger的runGc()方法进行垃圾回收，然后使用了removeWeaklyReachableReferences()方法移除已经被回收的引用。这里我们在深入地分析下runGc()的实现。
         
        GcTrigger DEFAULT = new GcTrigger() {
    @Override public void runGc() {
      // Code taken from AOSP FinalizationTest:
      // https://android.googlesource.com/platform/libc  ore/+/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 perform a gc.
      Runtime.getRuntime().gc();
      enqueueReferences();
      System.runFinalization();
    }

    private void enqueueReferences() {
      // Hack. We don't have a programmatic way to wait   for the reference queue daemon to move
      // references to the appropriate queues.
      try {
        Thread.sleep(100);
      } catch (InterruptedException e) {
        throw new AssertionError();
      }
    }
};

         
        这里并没有使用System.gc()方法进行回收，因为system.gc()并不会每次都执行。而是从AOSP中拷贝一段GC回收的代码，从而相比System.gc()更能够保证进行垃圾回收的工作。
         
        最后我们分析下注释5处的代码处理。首先会判断activity 如果还没有被回收，则证明发生内存泄露，进行if判断里面的操作。在里面先调用堆信息转储者heapDumper的dumpHeap()生成相应的 hprof 文件。这里的heapDumper是一个HeapDumper接口，具体的实现是AndroidHeapDumper。我们分析下AndroidHeapDumper的dumpHeap()方法是如何生成hprof文件的。
         
        public File dumpHeap() {
    File heapDumpFile = leakDirectoryProvider.newHeapDumpFile();

    if (heapDumpFile == RETRY_LATER) {
        return RETRY_LATER;
    }

    ...

    try {
      Debug.dumpHprofData(heapDumpFile.getAbsolutePath());
      ...

      return heapDumpFile;
    } catch (Exception e) {
      ...
      // Abort heap dump
      return RETRY_LATER;
    }
}

         
        这里的核心操作就是调用了
         Android SDK的API Debug.dumpHprofData() 来生成 hprof 文件。
         
        如果这个文件等于RETRY_LATER则表示生成失败，直接返回RETRY进行延时重试检测的操作。如果不等于的话，则表示生成成功，最后会执行heapdumpListener的analyze()对新创建的HeapDump对象进行泄漏分析。由前面对AndroidRefWatcherBuilder的listenerServiceClass()的分析可知，heapdumpListener的实现
         就是ServiceHeapDumpListener，接着看到ServiceHeapDumpListener的analyze方法。
         
        17.  
  
      17.  
        ServiceHeapDumpListener#analyze()
         
        @Override public void analyze(@NonNull HeapDump heapDump) {
    checkNotNull(heapDump, "heapDump");
    HeapAnalyzerService.runAnalysis(context, heapDump, listenerServiceClass);
}

         
        可以看到，这里执行了HeapAnalyzerService的runAnalysis()方法，为了避免减慢app进程或占用内存，这里将HeapAnalyzerService设置在了一个独立的进程中。接着继续分析runAnalysis()方法里面的处理。
         
        public final class HeapAnalyzerService extends ForegroundService
implements AnalyzerProgressListener {

    ...

    public static void runAnalysis(Context context, HeapDump heapDump,
    Class listenerServiceClass) {
        ...

        ContextCompat.startForegroundService(context, intent);
    }

    ...

    @Override protected void onHandleIntentInForeground(@Nullable Intent intent) {
        ...

        // 1
        HeapAnalyzer heapAnalyzer =
            new HeapAnalyzer(heapDump.excludedRefs, this, heapDump.reachabilityInspectorClasses);

        // 2
        AnalysisResult result = heapAnalyzer.checkForLeak(heapDump.heapDumpFile, heapDump.referenceKey,
        heapDump.computeRetainedHeapSize);

        // 3
        AbstractAnalysisResultService.sendResultToListener(this, listenerClassName, heapDump, result);
    }
        ...
}

         
        这里的HeapAnalyzerService实质是一个类型为IntentService的ForegroundService，执行startForegroundService()之后，会回调onHandleIntentInForeground()方法。注释1处，首先会新建一个HeapAnalyzer对象，顾名思义，它就是根据RefWatcher生成的heap dumps信息来分析被怀疑的泄漏是否是真的。在注释2处，然后会调用它的checkForLeak()方法去使用haha库解析 hprof文件，如下所示：
         
        public @NonNull AnalysisResult checkForLeak(@NonNull File heapDumpFile,
  @NonNull String referenceKey,
  boolean computeRetainedSize) {
    ...

    try {
    listener.onProgressUpdate(READING_HEAP_DUMP_FILE);
    // 1
    HprofBuffer buffer = new MemoryMappedFileBuffer(heapDumpFile);

    // 2
    HprofParser parser = new HprofParser(buffer);
    listener.onProgressUpdate(PARSING_HEAP_DUMP);
    Snapshot snapshot = parser.parse();

    listener.onProgressUpdate(DEDUPLICATING_GC_ROOTS);
    // 3
    deduplicateGcRoots(snapshot);
    listener.onProgressUpdate(FINDING_LEAKING_REF);

    // 4
    Instance leakingRef = findLeakingReference(referenceKey, snapshot);

    // 5
    if (leakingRef == null) {
        return noLeak(since(analysisStartNanoTime));
    }

    // 6
    return findLeakTrace(analysisStartNanoTime, snapshot, leakingRef, computeRetainedSize);
    } catch (Throwable e) {
    return failure(e, since(analysisStartNanoTime));
    }
}

         
        在注释1处，会新建一个内存映射缓存文件buffer。在注释2处，会使用buffer新建一个HprofParser解析器去解析出对应的引用内存快照文件snapshot。在注释3处，为了减少在Android 6.0版本中重复GCRoots带来的内存压力的影响，使用deduplicateGcRoots()删除了gcRoots中重复的根对象RootObj。在注释4处，调用了findLeakingReference()方法将传入的referenceKey和snapshot对象里面所有类实例的字段值对应的keyCandidate进行比较，如果没有相等的，则表示没有发生内存泄漏，直接调用注释5处的代码返回一个没有泄漏的分析结果AnalysisResult对象。如果找到了相等的，则表示发生了内存泄漏，执行注释6处的代码findLeakTrace()方法返回一个有泄漏分析结果的AnalysisResult对象。
         
        最后，我们来分析下HeapAnalyzerService中注释3处的AbstractAnalysisResultService.sendResultToListener()方法，很明显，这里AbstractAnalysisResultService的实现类就是我们刚开始分析的用于展示泄漏路径信息得DisplayLeakService对象。在里面直接创建一个由PendingIntent构建的泄漏通知用于供用户点击去展示详细的泄漏界面DisplayLeakActivity。核心代码如下所示：
         
        public class DisplayLeakService extends AbstractAnalysisResultService {

    @Override
    protected final void onHeapAnalyzed(@NonNull AnalyzedHeap analyzedHeap) {

        ...

        boolean resultSaved = false;
        boolean shouldSaveResult = result.leakFound || result.failure != null;
        if (shouldSaveResult) {
            heapDump = renameHeapdump(heapDump);
            // 1
            resultSaved = saveResult(heapDump, result);
        }

        if (!shouldSaveResult) {
            ...
            showNotification(null, contentTitle, contentText);
        } else if (resultSaved) {
            ...
            // 2
            PendingIntent pendingIntent =
                DisplayLeakActivity.createPendingIntent(this, heapDump.referenceKey);

            ...

            showNotification(pendingIntent, contentTitle, contentText);
        } else {
             onAnalysisResultFailure(getString(R.string.leak_canary_could_not_save_text));
        }

    ...
}

@Override protected final void onAnalysisResultFailure(String failureMessage) {
    super.onAnalysisResultFailure(failureMessage);
    String failureTitle = getString(R.string.leak_canary_result_failure_title);
    showNotification(null, failureTitle, failureMessage);
}

         
        可以看到，只要当分析的堆信息文件保存成功之后，即在注释1处返回的resultSaved为true时，才会执行注释2处的逻辑，即创建一个供用户点击跳转到DisplayLeakActivity的延时通知。
         
        18.  
  

                            
                        
                    
                    
                    
        
                    
                    
                    
        
                
                
        
                    
                
        
            
        
    
    
        
        
        你可能感兴趣的:(内存泄漏+leakCanary)
        
        
        
            
        
                
          
                    
        • C++八股
                        Petrichorzncu
八股总结c++开发语言
                        
          这里写目录标题C++内存管理C++的构造函数，复制构造函数，和析构函数深复制与浅复制：构造函数和析构函数哪个能写成虚函数，为什么？C++数据结构内存排列结构体和类占用的内存：==虚函数和虚表的原理==虚函数虚表（Vtable）虚函数和虚表的实现细节==内存泄漏==指针的工作原理函数的传值和传址new和delete与malloc和freeC++内存区域划分C++11新特性C++常见新特性==智能指针
          
                    
          • 
                    
        • 【解决内存泄漏的问题】 Qt 框架中的父子对象关系会自动管理内存，父对象会在其销毁时自动销毁所有子对象。
                        课堂随想
QTqt
                        
          修改前的代码这段代码可能会出现内存泄漏问题，主要原因是构造函数中创建的LoginDialog和RegisterDialog对象未在合适的地方被正确释放。具体分析如下：1.构造函数中的问题_login_dlg=newLoginDialog();setCentralWidget(_login_dlg);_login_dlg->show();connect(_login_dlg,&LoginDialog
          
                    
          • 
                    
        • Java中的垃圾回收机制是如何工作的？
                        Good_tea_h
javajvm算法
                        
          Java中的垃圾回收机制（GarbageCollection,GC）是Java虚拟机（JVM）的一个重要组成部分，它负责自动管理内存的分配和释放，以减轻程序员在内存管理方面的负担，并防止内存泄漏和内存溢出等问题。一、垃圾回收机制的核心思想Java的垃圾回收机制主要基于两个核心思想：标记和回收。标记：垃圾收集器会定期自动扫描内存中的对象，根据特定的算法（如可达性分析法）来判断哪些对象已经不再被程序使
          
                    
          • 
                    
        • 嵌入式八股文(一) C语言篇
                        云雨歇
学习笔记c语言
                        
          文章目录前言一、指针和变量二、关键字1.volatile2.const3.static4.extern三、数据结构1.结构体1.1结构体基本内容1.2通过指针对结构体赋值1.3结构体指针2.联合体3.链表3.1基本概念3.2链表的插入和删除4.栈（Stack）5.堆（Heap）6.队列四、内存1.内存分配的方法2.malloc和free3.内存泄漏4.内存溢出前言笔者在学习时发觉自己的C语言很久没
          
                    
          • 
                    
        • JVM垃圾回收（Garbage Collection）机制
                        小码ssim
jvm
                        
          1、定义描述Java的垃圾回收（GarbageCollection，GC）机制是Java虚拟机（JVM）的一项关键功能，旨在自动管理内存，回收不再使用的对象，保证程序运行过程中不出现内存泄漏和内存溢出。2、回收位置VM内存结构中，垃圾回收的主要工作集中在堆内存区域（回收无引用或循环的废弃对象实例）。其他内存区域，如方法区（存储元数据，常量、静态变量和即将编译的代码，垃圾回收不频繁，且不如堆内存高效
          
                    
          • 
                    
        • Android-面试-Jetpack-LiveData-你必须滴知道得知道的那些玩意儿(1)
                        m0_64603929
程序员面试移动开发android
                        
          作者：RicardoMJiang前言阅读本文前，大家可以先思考一些这几个问题：1.LiveData为什么可以自动取消订阅，如何避免内存泄漏？2.LiveData设置相同的值，会不会回调？3.LiveData有什么坑？如何实现LiveDataBus？带着问题学习可以让我们在学习的过程中更加有目的性与条理。例如在读源码的过程中，我们如果从头开始读，往往千头万绪，抓不住要领。而如果在开始读之前先带着几个
          
                    
          • 
                    
        • Python | 使用Pandas DataFrame时的内存泄漏问题及示例
                        python收藏家
python数据科学python
                        
          Pandas是一个功能强大且广泛使用的Python开源数据分析和操作库。它提供了一个DataFrame对象，允许您以非常直观的方式存储和操作行和列中的表格数据。PandasDataFrames是处理数据的强大工具，但如果不小心使用，它们也可能成为内存泄漏的来源。当程序分配了要使用的内存，但在不再需要时未能正确释放该内存时，就会发生内存泄漏。这可能会导致程序随着时间的推移使用越来越多的内存，从而可能
          
                    
          • 
                    
        • Android之性能优化
                        追梦的鱼儿
android性能优化
                        
          目录1.内存优化1.1避免内存泄漏1.2使用合适的数据结构2.布局优化2.1减少布局层级2.2避免过度绘制3.网络优化3.1使用缓存3.2压缩数据4.I/O操作优化4.1异步处理4.2使用高效的I/OAPI5.动画优化5.1使用硬件加速5.2避免频繁的属性更新6.数据库优化6.1使用索引6.2批量操作7.启动时间优化7.1延迟初始化7.2使用SplashScreen8.代码优化8.1避免不必要的对
          
                    
          • 
                    
        • 【C语言】动态内存管理
                        我言秋日胜春朝★
C语言进阶c语言开发语言
                        
          目录一、动态内存管理函数：1、malloc：2、free：3、calloc：4、realloc：二、常见的错误：1、对NULL指针解引用：2、对动态开辟空间的越界访问：3、对非动态开辟内存的释放：4、使用free释放动态内存开辟的一部分：5、对同一块内存多次释放：6、动态内存开辟的空间忘记释放：（内存泄漏）前言：动态内存管理是在内存中的堆区上进行维护的：一、动态内存管理函数：1、malloc：这个
          
                    
          • 
                    
        • Puppeteer Heap Snapshot: 探索JavaScript内存世界的利器
                        金畏战Goddard

                        
          PuppeteerHeapSnapshot:探索JavaScript内存世界的利器puppeteer-heap-snapshotadriancooney/puppeteer-heap-snapshot:puppeteer-heap-snapshot是一个Node.js包，提供了通过Puppeteer获取浏览器内存堆快照的功能，以辅助JavaScript应用的内存泄漏检测和性能优化工作。项目地址:h
          
                    
          • 
                    
        • C++——智能指针
                        很楠不爱
c++开发语言
                        
          前言：哈喽小伙伴们，今天我们继续来分享C++的一个全新知识——智能指针。目录一.何为智能指针RAII二.智能指针的种类三.内存泄漏结语一.何为智能指针RAIIRAII（ResourceAcquisitionIsInitialization）是一种利用对象生命周期来控制程序资源（如内存、文件句柄、网络连接、互斥量等等）的简单技术。在对象构造时获取资源，接着控制对资源的访问使之在对象的生命周期内始终保
          
                    
          • 
                    
        • ThreadLocal 释放的方式有哪些
                        程序猿进阶
Java并发编程（多线程）java开发语言并发编程ThreadLocal线程池架构性能优化
                        
          ThreadLocal基础概念：IT-BLOG-CNThreadLocal是Java中用于在同一个线程中存储和隔离变量的一种机制。通常情况下，我们使用ThreadLocal来存储线程独有的变量，并在任务完成后通过remove方法清理这些变量，以防止内存泄漏。然而，在使用线程池时，线程会被重用，这可能导致ThreadLocal变量未被及时清理，从而引发内存泄漏问题。除了直接调用ThreadLocal
          
                    
          • 
                    
        • 【C++】List容器（2）-内存管理-创建-插入-删除-遍历-排序-查找-底层分析-构造和析构函数-内存泄漏等
                        JasonHuan1123
#C++c++list开发语言
                        
          std::list是C++STL中的一种双向链表容器，它提供了一系列的迭代器来访问元素，包括前方迭代器、后方迭代器和const迭代器。std::list采用双向链表实现，每个节点都存储了数据以及两个指向前一个节点和后一个节点的指针。内存管理在C++中，std::list容器是由标准模板库（STL）管理的，这意味着开发者不需要手动管理其内存分配和释放。std::list容器使用动态内存分配在内部维护
          
                    
          • 
                    
        • Node.js sqlite3的db.close方法：正确关闭数据库连接
                        软考鸭
sqlitenodejs帮助文档数据库sqlitesql
                        
          在Node.js环境中，sqlite3是一个广受欢迎的轻量级数据库库，它为开发者提供了一个简洁的API来与SQLite数据库进行交互。当完成数据库操作后，正确关闭数据库连接是一个重要的步骤，以确保资源得到释放并避免潜在的内存泄漏。sqlite3库提供了db.close方法来实现这一功能。本文将深入解析db.close方法，包括其API函数定义和相应的代码示例解释。一、db.close方法简介db.
          
                    
          • 
                    
        • 最佳实践：API速率限制与节流
                        幂简集成
API基础知识githubAPI
                        
          有限的资源是这个世界上每一个系统的基础。例如，计算机系统的可用内存量是有限的。这是软件开发人员在管理应用程序中的内存使用时通常面临的挑战。由于使用过多内存会导致程序变慢或崩溃，开发人员需要小心优化内存使用并避免内存泄漏。应用程序编程接口（API）也是一样的。为了保持最佳质量并确保其安全，应用速率限制是必不可少的。速率限制可以充当API安全措施来保护API———消除恶意机器人和DDoS攻击导致的性能
          
                    
          • 
                    
        • 了解什么是JavaScript的垃圾回收机制
                        yang295242361
javascript开发语言
                        
          今天我们来聊一聊js中的垃圾回收机制，小编将会从两个方面带大家去了解js中的垃圾回收机制，分别是：为什么需要垃圾回收机制垃圾回收机制的实现方式是什么为什么需要垃圾回收机制顾名思义，垃圾回收就是把垃圾给回收起来(听君一席话，如听一席话，哈哈哈)，其实对应到js当中就是把不再使用的变量所占用的内存给释放掉，至于为什么需要这样，这就得说一下内存泄漏了：什么是内存泄漏我们知道，一个程序的运行是需要操作系统
          
                    
          • 
                    
        • 华为APP UI自动化测试岗面试真题，真实面试经历。
                        自动化测试君
自动化测试接口测试软件测试ui面试职场和发展经验分享软件测试
                        
          1.AndroidAPP内存不足时，如何获得内存？系统优先结束被挂起（暂停）的进程，释放内存。2.APP测试常见问题有哪些？原因有哪些？常见的有crash、ANR（应用无响应、卡死），一般由设备碎片化、网络波动大、内存泄漏、代码编写错误。3.APP自动化测试工具开放性问题，带点主观意见：对比其他熟悉的自动化工具的优缺点；自动化的简要方案（简要的同时关键内容请具体）。4.Android与web测试区
          
                    
          • 
                    
        • 【Xcode】Xcode基本使用指引
                        ADi_hhh
iOSxcodemacoside
                        
          文章目录Xcode安装及iphone模拟器的安装Xcode中Debug和Release的切换Xcode中控件的使用Xcode工程的基本组成XcodeUI基本设计及使用iOS开发项目中的日志系统静态库支持多种架构制作xcframeworklibuv库Xcode路径.pbxproj文件苹果平台的宏Leaks检测内存泄漏OC中的ARC和MRC小结Xcode安装及iphone模拟器的安装参考文章：Xcod
          
                    
          • 
                    
        • 七、性能测试
                        for_everyoung01
测试开发功能测试单元测试压力测试
                        
          文章目录一、常见的性能测试二、为什么要进行性能测试三、性能测试实施的流程（一）如何确定性能测试的需求1.关键性能指标分析2.关键业务分析（二）常见的性能指标三、性能测试定义四、性能测试关键指标（一）并发用户数一、常见的性能测试系统内部以及软件的代码实现资源泄漏，包括内存泄漏。CPU使用率达到100%，系统被锁定等。线程死锁，阻塞等造成系统越来越慢。查询速度慢，或者列表的效率低。受外部系统影响越来越
          
                    
          • 
                    
        • JavaScript高级 —— 学习（一）
                        COLDEHY
es6学习前端
                        
          目录一、作用域（一）局部作用域1.函数作用域2.块作用域（二）全局作用域二、垃圾回收机制GC（一）生命周期1.内存分配2.内存使用3.内存回收4.特殊情况——内存泄漏：注意：（二）算法说明1.堆栈空间分配区别2.常见的浏览器垃圾回收算法引用计数法（基本不咋用）标记清除法三、闭包（一）闭包简介（二）闭包的基本格式（三）闭包应用——实现函数的私有四、变量提升五、函数进阶（一）函数提升（二）函数参数1.
          
                    
          • 
                    
        • android文件上传优化分享（切片上传）
                        2401_84520332
程序员android
                        
          数据UI分离：使用观察模式，抽离UI部分代码。使用弱引用设置观察者，避免生命周期不一致引起的内存泄漏。费时操作前置：在选择图片的步骤，开启异步线程压缩图片、计算md5，将费时操作提前处理掉_（此步骤在mx4pro上处理拍照的图片耗时100~200ms，基本上选择图片后就已经完成好了计算）_将文件上传成功的md5值保存在内存中，避免重复处理。分次请求合并：向服务端开发者申请批校验的接口，将多个文件存
          
                    
          • 
                    
        • effective java笔记
                        Mrryo

                        
          1、Java中创建（实例化）对象的五种方式：a、new一个对象。b、反射，Objecta=Class.forName("java.lang.Object").newInstance();c、通过I/O流(包括反序列化)。d、对象的clone()。e、通过工厂方法返回对象。2、抽象类，要想对其实例化，只能用getInstance().(单例模式)。3、内存泄漏：用数组、集合、缓存、监听器等时要注意释
          
                    
          • 
                    
        • ThreadLocal中的内存泄漏问题及JDK处理方法13
                        高洪岩
jvmjava开发语言
                        
          由图可知，ThreadLocal.ThreadLocalMap对应的Entry中，key为ThreadLocal对象的弱引用，方法执行对应栈帧中的ThreadLocal引用为强引用。当方法执行过程中，由于栈帧销毁或者主动释放等原因，释放了ThreadLocal对象的强引用，即表示该ThreadLocal对象可以被回收了。又因为Entry中key为ThreadLocal对象的弱引用，所以当jvm执行
          
                    
          • 
                    
        • 深入理解JavaScript闭包：避免常见的内存泄漏问题
                        几何心凉
前端入门之旅javascript开发语言ecmascript
                        
          聚沙成塔·每天进步一点点本文回顾⭐专栏简介深入理解JavaScript闭包：避免常见的内存泄漏问题1.引言2.什么是闭包？2.1闭包的定义2.2闭包的基本示例3.闭包的工作原理3.1词法作用域和闭包3.2执行上下文和作用域链3.3闭包的内存管理4.内存泄漏问题及其原因4.1什么是内存泄漏？4.2闭包导致内存泄漏的常见情况4.2.1不必要的全局变量4.2.2DOM元素引用4.2.3计时器和异步操作5
          
                    
          • 
                    
        • 防止内存泄漏的神兵利器 — 智能指针
                        手捧向日葵的花语
C/C++jvm
                        
          1.内存泄漏1.1什么是内存泄漏当我们在写C/C++程序的时候，难免会出现内存泄漏的错误，因为C/C++不像Java语言那样，拥有自己的垃圾回收机制，C/C++中对于资源的管理，完全交给程序员自己打理，也就是说使用C/C++的程序员可以直接和内存打交道，写出来的程序效率自然比其他语言的运行速度更快，这是C++的优点，但同样也是C++的缺点，因为，我们难以保证我们是否正确释放了不在使用的资源。比如：
          
                    
          • 
                    
        • egret项目游戏内存泄漏总结
                        独一人守座城

                        
          JS内存管理JS中内存的分配和回收都是虚拟机自动完成的，不需要像C/C++为每一个new/malloc操作去写配对的delete/free代码，不容易出现内存泄漏的问题。JS引擎中对变量的存储主要是在栈内存，堆内存。内存泄漏的实质是应该回收的对象出现意外而没有被回收，而是常驻内存。GC原理在堆中查看无用的对象，把这些对象占用的内存空间进行回收。浏览器上的GC(GabageCollection垃圾回
          
                    
          • 
                    
        • 内存泄漏是什么？发生在什么场景？如何解决？
                        Rainyocode
jvm
                        
          内存泄漏定义内存泄漏发生在程序中，当对象不再被需要时，仍然存在对它的引用，导致垃圾回收器无法回收这些对象。虽然这些对象占用的内存并没有被释放，但程序仍然在继续消耗内存，最终可能导致系统内存不足。发生的场景在Java中，如果一个对象被添加到一个静态集合中，而没有在不再需要时将其移除，就会发生内存泄漏。首先我们了解一下静态集合：静态集合的特点共享性：所有实例都可以访问同一个静态集合，任何一个实例对集合
          
                    
          • 
                    
        • 系统开发压力测试高并发
                        朱杰jjj
java压力测试json大数据
                        
          目的：压力测试软景见环境下的系统多能承受的最大负荷以及高访问量出现的并发带来的问题。压力测试能够帮助系统在线上稳定持续的运行，在一定范围内可以做到心中有数。我们希望压力测试能够发现更多的错误。其中两种：并发同步问题、内存泄漏问题。性能指标1.响应时间（RT）:指从客户端发起一个请求开始到客户端接收到服务端返回的响应结束的整个过程所耗费的时间。2.HPS：每秒点击次数。3.TPS：系统每秒处理交易的
          
                    
          • 
                    
        • 使用C++开发黑神话悟空类似3A如何避免内存泄漏
                        Code apprenticeship
后端c++java开发语言
                        
          智能指针：使用C++11或更高版本中的智能指针（如std::unique_ptr、std::shared_ptr和std::weak_ptr）来自动管理内存。这些智能指针在超出作用域时会自动释放它们所管理的内存。RAII（ResourceAcquisitionIsInitialization）：采用RAII原则，确保资源在对象生命周期结束时被正确释放。这意味着资源的获取和释放与对象的创建和销毁同步
          
                    
          • 
                    
        • 【C++ 面试 - 内存管理】每日 3 题（九）
                        Pandaconda
#C++面试专栏c++面试后端开发语言职场和发展笔记经验分享
                        
          ✍个人博客：Pandaconda-CSDN博客专栏地址：http://t.csdnimg.cn/fYaBd专栏简介：在这个专栏中，我将会分享C++面试中常见的面试题给大家~❤️如果有收获的话，欢迎点赞收藏，您的支持就是我创作的最大动力25.Vlagrind工具的内存泄漏检测底层原理是什么？Valgrind的Memcheck工具是用于检测内存泄漏的工具，其底层原理基于动态二进制插桩技术。下面是Mem
          
                    
          • 
                                
        • rust的指针作为函数返回值是直接传递，还是先销毁后创建？
                                    wudixiaotie
返回值
                                    
           这是我自己想到的问题，结果去知呼提问，还没等别人回答， 我自己就想到方法实验了。。 
fn main() {
    let mut a = 34;
    println!("a's addr:{:p}", &a);
    let p = &mut a;
    println!("p's addr:{:p}", &a
          
                                
          • 
                                
        • java编程思想 -- 数据的初始化
                                    百合不是茶
java数据的初始化
                                    
            
1.使用构造器确保数据初始化 
     
/*
 *在ReckInitDemo类中创建Reck的对象 
 */
public class ReckInitDemo {
	

	public static void main(String[] args) {
		//创建Reck对象
		new Reck();
	}
	
	
}
          
                                
          • 
                                
        • [航天与宇宙]为什么发射和回收航天器有档期
                                    comsci

                                    
           
 
 
       地球的大气层中有一个时空屏蔽层,这个层次会不定时的出现,如果该时空屏蔽层出现,那么将导致外层空间进入的任何物体被摧毁,而从地面发射到太空的飞船也将被摧毁... 
 
       所以,航天发射和飞船回收都需要等待这个时空屏蔽层消失之后,再进行 
 
&
          
                                
          • 
                                
        • linux下批量替换文件内容
                                    商人shang
linux替换
                                    
          1、网络上现成的资料 
　　格式: sed -i "s/查找字段/替换字段/g" `grep 查找字段 -rl 路径` 
　　linux sed 批量替换多个文件中的字符串 
　　sed -i "s/oldstring/newstring/g" `grep oldstring -rl yourdir` 
　　例如：替换/home下所有文件中的www.admi
          
                                
          • 
                                
        • 网页在线天气预报
                                    oloz
天气预报
                                    
          网页在线调用天气预报

<%@ page language="java" contentType="text/html; charset=utf-8"
 pageEncoding="utf-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transit
          
                                
          • 
                                
        • SpringMVC和Struts2比较
                                    杨白白
springMVC
                                    
          1. 入口 
spring mvc的入口是servlet，而struts2是filter（这里要指出，filter和servlet是不同的。以前认为filter是servlet的一种特殊），这样就导致了二者的机制不同，这里就牵涉到servlet和filter的区别了。 
参见：http://blog.csdn.net/zs15932616453/article/details/8832343 
2
          
                                
          • 
                                
        • refuse copy, lazy girl!
                                    小桔子
copy
                                    
                 妹妹坐船头啊啊啊啊！都打算一点点琢磨呢。文字编辑也写了基本功能了。。今天查资料，结果查到了人家写得完完整整的。我清楚的认识到： 
1.那是我自己觉得写不出的高度 
2.如果直接拿来用，很快就能解决问题 
3.然后就是抄咩~~ 
4.肿么可以这样子，都不想写了今儿个，留着作参考吧！拒绝大抄特抄，慢慢一点点写！ 
  
          
                                
          • 
                                
        • apache与php整合
                                    aichenglong
php apache web
                                    
          一  apache web服务器 
 1 apeche web服务器的安装 
  1)下载Apache web服务器 
  2)配置域名(如果需要使用要在DNS上注册) 
  3)测试安装访问http://localhost/验证是否安装成功 
 2 apache管理 
  1)service.msc进行图形化管理 
  2)命令管理，配
          
                                
          • 
                                
        • Maven常用内置变量
                                    AILIKES
maven
                                    
          Built-in properties 
 
  ${basedir} represents the directory containing pom.xml 
  ${version} equivalent to ${project.version} (deprecated: ${pom.version})  
 Pom/Project properties 
Al
          
                                
          • 
                                
        • java的类和对象
                                    百合不是茶
JAVA面向对象 类 对象
                                    
          java中的类： 
  
  java是面向对象的语言，解决问题的核心就是将问题看成是一个类，使用类来解决 
  
java使用 class 类名   来创建类 ，在Java中类名要求和构造方法，Java的文件名是一样的 
  
创建一个A类： 
class A{
} 
  
java中的类：将某两个事物有联系的属性包装在一个类中，再通
          
                                
          • 
                                
        • JS控制页面输入框为只读
                                    bijian1013
JavaScript
                                    
          在WEB应用开发当中，增、删除、改、查功能必不可少，为了减少以后维护的工作量，我们一般都只做一份页面，通过传入的参数控制其是新增、修改或者查看。而修改时需将待修改的信息从后台取到并显示出来，实际上就是查看的过程，唯一的区别是修改时，页面上所有的信息能修改，而查看页面上的信息不能修改。因此完全可以将其合并，但通过前端JS将查看页面的所有信息控制为只读，在信息量非常大时，就比较麻烦。 
  
          
                                
          • 
                                
        • AngularJS与服务器交互
                                    bijian1013
JavaScriptAngularJS$http
                                    
                  对于AJAX应用（使用XMLHttpRequests）来说，向服务器发起请求的传统方式是：获取一个XMLHttpRequest对象的引用、发起请求、读取响应、检查状态码，最后处理服务端的响应。整个过程示例如下： 
var xmlhttp = new XMLHttpRequest();

xmlhttp.onreadystatechange
          
                                
          • 
                                
        • [Maven学习笔记八]Maven常用插件应用
                                    bit1129
maven
                                    
          常用插件及其用法位于：http://maven.apache.org/plugins/ 
  
1. Jetty server plugin 
2. Dependency copy plugin 
3. Surefire Test plugin 
4. Uber jar plugin 
  
  
  
  
  
1. Jetty Pl
          
                                
          • 
                                
        • 【Hive六】Hive用户自定义函数(UDF)
                                    bit1129
自定义函数
                                    
          1. 什么是Hive UDF 
Hive是基于Hadoop中的MapReduce，提供HQL查询的数据仓库。Hive是一个很开放的系统，很多内容都支持用户定制，包括： 
 
 文件格式：Text File，Sequence File 
 内存中的数据格式： Java Integer/String, Hadoop IntWritable/Text 
 用户提供的 map/reduce 脚本：不管什么
          
                                
          • 
                                
        • 杀掉nginx进程后丢失nginx.pid，如何重新启动nginx
                                    ronin47
nginx 重启 pid丢失
                                    
          nginx进程被意外关闭，使用nginx -s reload重启时报如下错误：nginx: [error] open() “/var/run/nginx.pid” failed (2: No such file or directory)这是因为nginx进程被杀死后pid丢失了，下一次再开启nginx -s reload时无法启动解决办法：nginx -s reload 只是用来告诉运行中的ng
          
                                
          • 
                                
        • UI设计中我们为什么需要设计动效
                                    brotherlamp
UIui教程ui视频ui资料ui自学
                                    
          随着国际大品牌苹果和谷歌的引领，最近越来越多的国内公司开始关注动效设计了，越来越多的团队已经意识到动效在产品用户体验中的重要性了，更多的UI设计师们也开始投身动效设计领域。 
但是说到底，我们到底为什么需要动效设计？或者说我们到底需要什么样的动效？做动效设计也有段时间了，于是尝试用一些案例，从产品本身出发来说说我所思考的动效设计。 
一、加强体验舒适度 
嗯，就是让用户更加爽更加爽的用你的产品。 
          
                                
          • 
                                
        • Spring中JdbcDaoSupport的DataSource注入问题
                                    bylijinnan
javaspring
                                    
          参考以下两篇文章： 
 
http://www.mkyong.com/spring/spring-jdbctemplate-jdbcdaosupport-examples/ 
 
http://stackoverflow.com/questions/4762229/spring-ldap-invoking-setter-methods-in-beans-configuration 
 
Sprin
          
                                
          • 
                                
        • 数据库连接池的工作原理
                                    chicony
数据库连接池
                                    
                 随着信息技术的高速发展与广泛应用，数据库技术在信息技术领域中的位置越来越重要，尤其是网络应用和电子商务的迅速发展，都需要数据库技术支持动 态Web站点的运行，而传统的开发模式是：首先在主程序（如Servlet、Beans）中建立数据库连接；然后进行SQL操作，对数据库中的对象进行查 询、修改和删除等操作；最后断开数据库连接。使用这种开发模式，对
          
                                
          • 
                                
        • java 关键字
                                    CrazyMizzz
java
                                    
           
关键字是事先定义的，有特别意义的标识符，有时又叫保留字。对于保留字，用户只能按照系统规定的方式使用，不能自行定义。 
 
Java中的关键字按功能主要可以分为以下几类： 
   （1）访问修饰符 
      public,private,protected 
      p
          
                                
          • 
                                
        • Hive中的排序语法
                                    daizj
排序hiveorder byDISTRIBUTE BYsort by
                                    
          Hive中的排序语法 2014.06.22  ORDER BY 
hive中的ORDER BY语句和关系数据库中的sql语法相似。他会对查询结果做全局排序，这意味着所有的数据会传送到一个Reduce任务上，这样会导致在大数量的情况下，花费大量时间。 
与数据库中 ORDER BY 的区别在于在hive.mapred.mode = strict模式下，必须指定 limit 否则执行会报错。
          
                                
          • 
                                
        • 单态设计模式
                                    dcj3sjt126com
设计模式
                                    
            单例模式（Singleton）用于为一个类生成一个唯一的对象。最常用的地方是数据库连接。 使用单例模式生成一个对象后，该对象可以被其它众多对象所使用。    
<?phpclass Example{    // 保存类实例在此属性中    private static&
          
                                
          • 
                                
        • svn locked
                                    dcj3sjt126com
Lock
                                    
          post-commit hook failed (exit code 1) with output: 
svn: E155004: Working copy 'D:\xx\xxx' locked 
svn: E200031: sqlite: attempt to write a readonly database 
svn: E200031: sqlite: attempt to write a 
          
                                
          • 
                                
        •  ARM寄存器学习
                                    e200702084
数据结构C++cC#F#
                                    
          无论是学习哪一种处理器，首先需要明确的就是这种处理器的寄存器以及工作模式。 
    ARM有37个寄存器，其中31个通用寄存器，6个状态寄存器。 
1、不分组寄存器（R0-R7） 
    不分组也就是说说，在所有的处理器模式下指的都时同一物理寄存器。在异常中断造成处理器模式切换时，由于不同的处理器模式使用一个名字相同的物理寄存器，就是
          
                                
          • 
                                
        • 常用编码资料
                                    gengzg
编码
                                    
          		List<UserInfo> list=GetUserS.GetUserList(11);
		String json=JSON.toJSONString(list);
		HashMap<Object,Object> hs=new HashMap<Object, Object>();
		for(int i=0;i<10;i++)
		{

          
                                
          • 
                                
        • 进程 vs. 线程
                                    hongtoushizi
线程linux进程
                                    
          我们介绍了多进程和多线程，这是实现多任务最常用的两种方式。现在，我们来讨论一下这两种方式的优缺点。 
首先，要实现多任务，通常我们会设计Master-Worker模式，Master负责分配任务，Worker负责执行任务，因此，多任务环境下，通常是一个Master，多个Worker。 
如果用多进程实现Master-Worker，主进程就是Master，其他进程就是Worker。 
如果用多线程实现
          
                                
          • 
                                
        • Linux定时Job：crontab -e 与 /etc/crontab 的区别
                                    Josh_Persistence
linuxcrontab
                                    
          一、linux中的crotab中的指定的时间只有5个部分：* * * * * 
分别表示：分钟，小时，日，月，星期，具体说来： 
第一段 代表分钟 0—59 
第二段 代表小时 0—23 
第三段 代表日期 1—31 
第四段 代表月份 1—12 
第五段 代表星期几，0代表星期日 0—6 
  
如： 
*/1 * * * *   每分钟执行一次。 
* 
          
                                
          • 
                                
        • KMP算法详解
                                    hm4123660
数据结构C++算法字符串KMP
                                    
               字符串模式匹配我们相信大家都有遇过，然而我们也习惯用简单匹配法（即Brute-Force算法)，其基本思路就是一个个逐一对比下去，这也是我们大家熟知的方法，然而这种算法的效率并不高，但利于理解。 
  
    假设主串s="ababcabcacbab",模式串为t="
          
                                
          • 
                                
        • 枚举类型的单例模式
                                    zhb8015
单例模式
                                    
          E.编写一个包含单个元素的枚举类型[极推荐]。代码如下： 
 
 public enum MaYun {himself; //定义一个枚举的元素，就代表MaYun的一个实例private String anotherField;MaYun() {//MaYun诞生要做的事情//这个方法也可以去掉。将构造时候需要做的事情放在instance赋值的时候：/** himself = MaYun() {*
          
                                
          • 
                                
        • Kafka+Storm+HDFS
                                    ssydxa219
storm
                                    
          cd /myhome/usr/stormbin/storm nimbus &amp;bin/storm supervisor &amp;bin/storm ui &amp;Kafka+Storm+HDFS整合实践kafka_2.9.2-0.8.1.1.tgzapache-storm-0.9.2-incubating.tar.gzKafka安装配置我们使用3台机器搭建Kafk
          
                                
          • 
                                
        • Java获取本地服务器的IP
                                    中华好儿孙
javaWeb获取服务器ip地址
                                    
          
        System.out.println("getRequestURL:"+request.getRequestURL());
		System.out.println("getLocalAddr:"+request.getLocalAddr());
		System.out.println("getLocalPort:&quo
          
                                
          •