APM，全称是Application Performance Management，也就是应用性能管理，这与我们平时写的业务可能并不相关，但是却承载着App线上稳定的责任。当一款App发布到线上之后，不同的用户有不同场景，一旦App出现了问题，为了避免黑盒，找不到头绪，就需要APM出马了。

对于App的性能，像CPU、流量、电量、内存、crash、ANR，这些都会是监控的点，尤其是当App发生崩溃的时候，需要回捞到当前用户的日志加以分析，找到此问题崩溃的堆栈，完成修复。否则就像是大海捞针，根本不知道哪里发生了崩溃，查找问题可能就需要找一半天。

那么对于成熟的线上APM监控，我们可能使用过Bugly、火山、Leakcanary，但其中都会有缺陷，对于一些大公司一般都会考虑自研APM，监控的对象也无非上述这些指标，那么如果让我们自己做一套APM监控，该怎么出方案呢？

1 Leakcanary为什么不能用于线上

如果有做过APM监控的伙伴，对于Leakcanary就很熟悉了，这个是一个老派的内存监控组件，但是我们在使用的时候，通常都是采用debugImplementation的方式引入，在debug环境下使用，而不是线上，这是为什么呢？

这个还需要从Leakcanary的原理说起了。

1.1 Leakcanary原理简单剖析

对于Java的引用类型，大家应该都清楚：强软弱虚，接下来我们通过一个简单的示例，看下四种引用的特性，这里我主要是介绍一下弱引用

Object object = new Object();
ReferenceQueue<Object> referenceQueue = new ReferenceQueue<Object>();
WeakReference<Object> weak = new WeakReference<Object>(object,referenceQueue);
Log.e("Test","弱引用 "+weak.get());
object = null;
System.gc();
Thread.sleep(1000);
Log.e("Test","弱引用 "+weak.get());
Log.e("Test","弱引用队列 "+referenceQueue.poll());
System.gc();
Thread.sleep(2000);
Log.e("Test","弱引用 "+weak.get());
Log.e("Test","弱引用队列 "+referenceQueue.poll());

在这里我们模拟了一次资源回收的GC操作，当一个对象被置成null之后，通过gc正常情况下是可以被回收的；这里我们需要关注的是一个ReferenceQueue引用队列，当一个对象被回收之后，就会被放在这个队列中，从而与弱引用对象产生关联。

2022-12-16 21:15:57.598 24678-24678/com.lay.mvi E/Test: 弱引用 java.lang.Object@2f8c602
2022-12-16 21:15:58.600 24678-24678/com.lay.mvi E/Test: 弱引用 java.lang.Object@2f8c602
2022-12-16 21:15:58.600 24678-24678/com.lay.mvi E/Test: 弱引用队列 null
2022-12-16 21:34:45.099 3152-3152/com.lay.mvi E/Test: 弱引用 null
2022-12-16 21:34:45.099 3152-3152/com.lay.mvi E/Test: 弱引用队列 java.lang.ref.WeakReference@7cd1b13

那么这个时候我们模拟一下内存泄漏

object Constant {
    private var any: Any? = null
    fun hold(any: Any?) {
        this.any = any
    }
}

这里有一个单例，在创建出一个Object对象之后，就持有这个引用，然后这个时候把这个对象置为空

ReferenceQueue<Object> referenceQueue = new ReferenceQueue<Object>();
WeakReference<Object> weak = new WeakReference<Object>(mObject,referenceQueue);
Log.e("Test","弱引用 "+weak.get());
Constant.INSTANCE.hold(mObject);
mObject = null;
System.gc();
Thread.sleep(2000);
Log.e("Test","弱引用 "+weak.get());
Log.e("Test","弱引用队列 "+referenceQueue.poll());

我们会发现无论如何GC，这个引用都无法被回收，因此对于内存泄漏的检测，就可以使用弱引用配个引用队列来进行关联对象的检测。

2022-12-16 21:38:47.743 5772-5772/com.lay.mvi E/Test: 弱引用 java.lang.Object@2f8c602
2022-12-16 21:38:49.744 5772-5772/com.lay.mvi E/Test: 弱引用 java.lang.Object@2f8c602
2022-12-16 21:38:49.744 5772-5772/com.lay.mvi E/Test: 弱引用队列 null
2022-12-16 21:38:51.745 5772-5772/com.lay.mvi E/Test: 弱引用 java.lang.Object@2f8c602
2022-12-16 21:38:51.745 5772-5772/com.lay.mvi E/Test: 弱引用队列 null

而在Leakcanary中，就是采用这种方式进行内存泄漏的检测，但是为啥不能用于线上，伙伴们应该知道，当系统在GC的时候，是需要STW的。

当一个Activity被销毁之后，Leakcanary会在onDestory方法中进行2次GC（为啥要多次GC，其实是因为一次GC并不能保证对象被回收，可以通过上面的例子中看出），如果熟悉JVM的伙伴应该知道，只要涉及到GC，极大的概率会触发STW，那么这个时候就会卡顿，如果有使用过Leakcanary，就会经常感受到卡顿甚至测试伙伴过来告诉你有bug，好在Leakcanary检测到内存泄漏的时候会有一个全局动画，不然真不好解释了。

1.2 小结

对于Leakcanary不能应用于线上，从性能角度来说，前面我们已经介绍了，主要就是归结于线程会STW；除此之外，因为Leakcanary在发生内存泄漏的时候，需要dump内存快照，生成hprof文件。

如果我们在Android Studio上分析过内存问题，会发现dump的过程非常耗时，会有3-4s的时间，有时甚至会卡死，但放在应用程序中，3-4s的时间可能直接导致ANR，因为整个过程应用程序是无响应的，所以Leakcanary只适合在线下测试环境中分析内存问题，不适合带着上线。

2 KOOM原理分析

那么既然Leakcanary不能带到线上，那么针对线上问题该如何分析呢？bugly只能分析Crash或者ANR，所以快手团队针对这些问题，研发了KOOM线上内存监控组件。

在此之前我们思考几个问题：

（1）对于线上APM，它需要非常高的实时性吗？如果出现内存泄漏就一定要立刻dump内存快照吗？

（2）dump内存快照是否能够在子线程中执行，而不阻塞主线程；

（3）对于生成的hprof文件，是否可以进行裁剪，加快分析进程尽快定位出问题来。

所以针对以上几个问题，我们看下KOOM是如何做到的。

2.1 KOOM引入

首先我们需要引入koom的依赖。

def VERSION_NAME = '2.2.0'

implementation "com.kuaishou.koom:koom-native-leak-static:${VERSION_NAME}"
implementation "com.kuaishou.koom:koom-java-leak-static:${VERSION_NAME}"
implementation "com.kuaishou.koom:koom-thread-leak-static:${VERSION_NAME}"
implementation "com.kuaishou.koom:xhook-static:${VERSION_NAME}"

因为整个KOOM的源码都是Kotlin写的，所以接下来的源码分析都会是Kotlin为主，具体的使用如下，在初始化完成OOMMonitor，就调用startLoop方法开启内存检测。

val commonConfig = CommonConfig.Builder().build()
val oomMonitorConfig = OOMMonitorConfig.Builder().build()
OOMMonitor.init(commonConfig, oomMonitorConfig)
OOMMonitor.startLoop(clearQueue = true,postAtFront = true, delayMillis = 5000)

2.2 KOOM源码分析

首先我们先看一下startLoop方法，从这个方法名字中，我们大概就能猜到这个方法在干什么事，如果熟悉Handler源码的伙伴应该明白，这肯定是循环的意思，当执行startLoop方法的时候，就是开启一个死循环。

override fun startLoop(clearQueue: Boolean, postAtFront: Boolean, delayMillis: Long) {
  throwIfNotInitialized { return }
  /**要在主进程中开启*/
  if (!isMainProcess()) {
    return
  }

  MonitorLog.i(TAG, "startLoop()")

  if (mIsLoopStarted) {
    return
  }
  mIsLoopStarted = true

  super.startLoop(clearQueue, postAtFront, delayMillis)
  getLoopHandler().postDelayed({ async { processOldHprofFile() } }, delayMillis)
}

首先startLoop是要在主进程中开启，然后执行了父类方法的startLoop，那么我们跟进去看一下。

open fun startLoop(
    clearQueue: Boolean = true,
    postAtFront: Boolean = false,
    delayMillis: Long = 0L
) {
  if (clearQueue) getLoopHandler().removeCallbacks(mLoopRunnable)

  if (postAtFront) {
    getLoopHandler().postAtFrontOfQueue(mLoopRunnable)
  } else {
    getLoopHandler().postDelayed(mLoopRunnable, delayMillis)
  }

  mIsLoopStopped = false
}

我们可以看到，在父类的startLoop方法中，同样是使用Handler来进行延迟消息的发送，执行的就是这个mLoopRunnable。

private val mLoopRunnable = object : Runnable {
  override fun run() {
    /**进行内存泄漏、OOM检测*/
    if (call() == LoopState.Terminate) {
      return
    }

    if (mIsLoopStopped) {
      return
    }

    getLoopHandler().removeCallbacks(this)
    getLoopHandler().postDelayed(this, getLoopInterval())
  }
}

在这个对象中，有一个核心方法call，就是用来做OOM和内存泄漏的检测

override fun call(): LoopState {
  if (!sdkVersionMatch()) {
    return LoopState.Terminate
  }

  if (mHasDumped) {
    return LoopState.Terminate
  }

  return trackOOM()
}

2.2.1 trackOOM方法分析

在call方法中，其实做的一个核心任务就是trackOOM，我们看下这个方法中主要是干了什么

private fun trackOOM(): LoopState {
  SystemInfo.refresh()

  mTrackReasons.clear()
  for (oomTracker in mOOMTrackers) {
    if (oomTracker.track()) {
      mTrackReasons.add(oomTracker.reason())
    }
  }
  /**如果追踪到了OOM，那么就会异步分析*/
  if (mTrackReasons.isNotEmpty() && monitorConfig.enableHprofDumpAnalysis) {
    if (isExceedAnalysisPeriod() || isExceedAnalysisTimes()) {
      MonitorLog.e(TAG, "Triggered, but exceed analysis times or period!")
    } else {
      async {
        MonitorLog.i(TAG, "mTrackReasons:${mTrackReasons}")
        dumpAndAnalysis()
      }
    }

    return LoopState.Terminate
  }

  return LoopState.Continue
}

首先是遍历mOOMTrackers数组，我们看下这个数组是什么

private val mOOMTrackers = mutableListOf(
  HeapOOMTracker(), ThreadOOMTracker(), FdOOMTracker(),
  PhysicalMemoryOOMTracker(), FastHugeMemoryOOMTracker()
)

这个数组其实是一些OOMTracker的实现类，就是这里大家需要思考一个问题，什么情况下会发生OOM？这里我总结一下主要可能发生OOM的场景：

（1）堆内存溢出；这个是典型的OOM场景；
（2）没有连续的内存空间分配；这个主要是因为内存碎片过多（标记清除算法），导致即便内存够用，也会造成OOM；
（3）打开过多的文件；如果有碰到这个异常OOM：open to many file的伙伴，应该就知道了；
（4）虚拟内存空间不足；
（5）开启过多的线程；一般情况下，开启一个线程大概会分配500k的内存，如果开启线程过多同样会导致OOM

所以看到这个数组中每个Tracker的名字，就应该明白，KOOM就是从这几个方面入手，随时监控可能发生OOM的风险，并发出告警信息。

for (oomTracker in mOOMTrackers) {
  if (oomTracker.track()) {
    mTrackReasons.add(oomTracker.reason())
  }
}

回到trackOOM这个方法，我们看在遍历这个数组的过程中，每取出一个Tracker，都执行了它的track方法

abstract class OOMTracker : Monitor<OOMMonitorConfig>() {
  /**
   * @return true 表示追踪到oom、 false 表示没有追踪到oom
   */
  abstract fun track(): Boolean

  /**
   * 重置track状态
   */
  abstract fun reset()

  /**
   * @return 追踪到的oom的标识
   */
  abstract fun reason(): String
}

我们看下SDK中的注释，这个方法的带有返回值的，如果返回了true，那么就表示追踪到了OOM，如果返回了false，即代表没有发生OOM；

然后如果追踪到了OOM，那么就将追踪到OOM的标识reason()塞到mTrackReasons这个集合当中。后面就会判断，如果这个集合不为空，那么就会去异步dump内存快照并分析，而不去阻塞主线程。

所以看到这里，我们肯定会想，KOOM是如何追踪到OOM标识的，是如何异步进行dump的，接下来我们着重看下我们前面提到的各种检测器。

2.2.2 HeapOOMTracker

对于每一个检测器，我们只需要关注track方法即可

override fun track(): Boolean {
  /**第一步：获取进程内存占用率*/
  val heapRatio = SystemInfo.javaHeap.rate
  /**利用内存占用率 与 配置文件中的阈值做比较*/
  if (heapRatio > monitorConfig.heapThreshold
      && heapRatio >= mLastHeapRatio - HEAP_RATIO_THRESHOLD_GAP) {

    mOverThresholdCount++

    MonitorLog.i(TAG,
        "[meet condition] "
            + "overThresholdCount: $mOverThresholdCount"
            + ", heapRatio: $heapRatio"
            + ", usedMem: ${SizeUnit.BYTE.toMB(SystemInfo.javaHeap.used)}mb"
            + ", max: ${SizeUnit.BYTE.toMB(SystemInfo.javaHeap.max)}mb")
  } else {
    reset()
  }

  mLastHeapRatio = heapRatio

  return mOverThresholdCount >= monitorConfig.maxOverThresholdCount
}

首先第一步：获取当前进程内存占用率；我们看到代码中很简单的一行代码，但是真正要我们自己实现，可能就是个大麻烦，怎么计算内存占用率？

首先我们需要知道内存占用率需要哪两个值去计算？如果熟悉JVM虚拟机的伙伴应该了解有两个参数：-xmx和-xms，其中-xmx代表当前进程允许占用的最大内存（例如64M或者128M），-xms代表当前进程初始申请的内存，内存占用率就是这两个值的比例。

那么如何求出-xmx和-xms呢，我们看下快手团队是如何实现的。其实也是比较简单，因为就是调用系统API，但是很多伙伴可能比较陌生。

/**当前进程最大内存，-xmx*/
javaHeap.max = Runtime.getRuntime().maxMemory()
/**当前进程初始化申请的内存，-xms*/
javaHeap.total = Runtime.getRuntime().totalMemory()
/**当前进程剩余可用内存*/
javaHeap.free = Runtime.getRuntime().freeMemory()
javaHeap.used = javaHeap.total - javaHeap.free
javaHeap.rate = 1.0f * javaHeap.used / javaHeap.max

注释已经添加，其中对于freeMemory我这里提一嘴，假设-xms为80M，freeMemory为30M，那么就说明当前进程已经占用了50M的内存，这也就是JavaHeap的used属性的结果。

private var mLastHeapRatio = 0.0f
private var mOverThresholdCount = 0
private const val HEAP_RATIO_THRESHOLD_GAP = 0.05f


if (heapRatio > monitorConfig.heapThreshold
    && heapRatio >= mLastHeapRatio - HEAP_RATIO_THRESHOLD_GAP)

当计算出内存占用率之后，我们看下面的一个判断条件，如果内存占用率超过我们设定的一个阈值（例如0.8），而且当前内存占用率跟上次比较超过了千分之5，那么mOverThresholdCount变量就会自增1。

因为检测是一个循环的过程，所以当第一次进来的时候，一定会自增1，而且会将本次的内存占用率赋值给mLastHeapRatio，当下次进来的时候，如果内存占用率较上次降低了，那么就会重置。

如此往复，当mOverThresholdCount超出我们设置的阈值（例如5次），我们就认定系统发生了内存泄漏，这个时候就需要告警，并dump内存快照分析问题。

2.2.3 ThreadOOMTracker

线程检测器跟内存检测器原理基本一致，同样也是在循环检测中，拿到线程的总数与阈值进行比较，如果超出范围那么就认为是异常，需要上报。

override fun track(): Boolean {
  val threadCount = getThreadCount()

  if (threadCount > monitorConfig.threadThreshold
      && threadCount >= mLastThreadCount - THREAD_COUNT_THRESHOLD_GAP) {
    mOverThresholdCount++

    MonitorLog.i(TAG,
        "[meet condition] "
            + "overThresholdCount:$mOverThresholdCount"
            + ", threadCount: $threadCount")

    dumpThreadIfNeed()
  } else {
    reset()
  }

  mLastThreadCount = threadCount

  return mOverThresholdCount >= monitorConfig.maxOverThresholdCount
}

这里获取系统线程总数，KOOM是通过读取配置文件的方式，如果在项目中有这个需求的伙伴，可以参考一下，注释已经加了。

File("/proc/self/status").forEachLineQuietly { line ->
  if (procStatus.vssInKb != 0 && procStatus.rssInKb != 0
      && procStatus.thread != 0) return@forEachLineQuietly

  when {
    line.startsWith("VmSize") -> {
      procStatus.vssInKb = VSS_REGEX.matchValue(line)
    }

    line.startsWith("VmRSS") -> {
      procStatus.rssInKb = RSS_REGEX.matchValue(line)
    }
    /**获取线程数*/
    line.startsWith("Threads") -> {
      procStatus.thread = THREADS_REGEX.matchValue(line)
    }
  }
}

2.2.4 FastHugeMemoryOOMTracker

其他类型的检测器不再过多赘述，最后主要介绍一下FastHugeMemoryOOMTracker这个检测器，从名字看也是内存检测，但是跟HeapOOMTracker还是不一样的。

override fun track(): Boolean {
  val javaHeap = SystemInfo.javaHeap

  // 高危阈值直接触发dump分析
  if (javaHeap.rate > monitorConfig.forceDumpJavaHeapMaxThreshold) {
    mDumpReason = REASON_HIGH_WATERMARK
    MonitorLog.i(TAG, "[meet condition] fast huge memory allocated detected, " +
        "high memory watermark, force dump analysis!")
    return true
  }

  // 高差值直接dump
  val lastJavaHeap = SystemInfo.lastJavaHeap
  if (lastJavaHeap.max != 0L && javaHeap.used - lastJavaHeap.used
      > SizeUnit.KB.toByte(monitorConfig.forceDumpJavaHeapDeltaThreshold)) {
    mDumpReason = REASON_HUGE_DELTA
    MonitorLog.i(TAG, "[meet condition] fast huge memory allocated detected, " +
        "over the delta threshold!")
    return true
  }

  return false
}

从track方法中，我们可以看到，当进程内存占用率超过设定的forceDumpJavaHeapMaxThreshold阈值（例如0.9），直接返回了true。

这里是为啥呢？因为HeapOOMTracker属于高内存持续监测，需要连续多次检测才会报警；但是如果我们程序中加载了一张大图片，内存直接暴涨（超过0.9），可能都等不到HeapOOMTracker检测多次程序直接Crash，这个时候就需要FastHugeMemoryOOMTracker出马了，主要进入高危阈值，直接报警。

还有一个判断条件就是，会比较前后两次的内存使用情况，如果超出了阈值也会直接报警，例如加载大图。

2.3 dump为何不能放在子线程

前面我们着重介绍了各类内存检测工具的原理，其实他们的主要目的就是为了检测是否有OOM迹象的产生，这也是dump内存镜像的触发条件，如果只要有一个Tracker报警，紧接着往下就是要dump内存镜像。

首先我们在AS中使用Profile工具dump内存快照，其实就是基于JVMTI来实现的，前面在介绍Leakcanary的时候就已经说过，这个过程是非常耗时的，因为APM线上监控对于实时性的要求并不高，因此可以直接放在子线程或者子进程中完成。

private fun dumpAndAnalysis() {
  MonitorLog.i(TAG, "dumpAndAnalysis");
  runCatching {
    if (!OOMFileManager.isSpaceEnough()) {
      MonitorLog.e(TAG, "available space not enough", true)
      return@runCatching
    }
    if (mHasDumped) {
      return
    }
    mHasDumped = true

    val date = Date()

    val jsonFile = OOMFileManager.createJsonAnalysisFile(date)
    val hprofFile = OOMFileManager.createHprofAnalysisFile(date).apply {
      createNewFile()
      setWritable(true)
      setReadable(true)
    }

    MonitorLog.i(TAG, "hprof analysis dir:$hprofAnalysisDir")
    /**核心代码 在这里完成内存镜像的dump*/
    ForkJvmHeapDumper.getInstance().run {
      dump(hprofFile.absolutePath)
    }

    MonitorLog.i(TAG, "end hprof dump", true)
    Thread.sleep(1000) // make sure file synced to disk.
    MonitorLog.i(TAG, "start hprof analysis")

    startAnalysisService(hprofFile, jsonFile, mTrackReasons.joinToString())
  }.onFailure {
    it.printStackTrace()

    MonitorLog.i(TAG, "onJvmThreshold Exception " + it.message, true)
  }
}

在KOOM的dumpAndAnalysis方法中，我们看到创建了hprofFile文件，然后接下来一个核心类ForkJvmHeapDumper，这个类主要作用就是dump内存快照。

2.3.1 ForkJvmHeapDumper分析

看下这个类中的核心方法dump，传入的参数就是hprof文件的绝对路径

@Override
public synchronized boolean dump(String path) {
  MonitorLog.i(TAG, "dump " + path);
  if (!sdkVersionMatch()) {
    throw new UnsupportedOperationException("dump failed caused by sdk version not supported!");
  }
  /**第一步，调用init方法，加载so文件*/
  init();
  if (!mLoadSuccess) {
    MonitorLog.e(TAG, "dump failed caused by so not loaded!");
    return false;
  }

  boolean dumpRes = false;
  try {
    MonitorLog.i(TAG, "before suspend and fork.");
    /**第二步，fork出一个子进程*/
    int pid = suspendAndFork();
    /**第三步，在子进程中完成dump*/
    if (pid == 0) {
      // Child process
      Debug.dumpHprofData(path);
      exitProcess();
    } else if (pid > 0) {
      // Parent process
      dumpRes = resumeAndWait(pid);
      MonitorLog.i(TAG, "dump " + dumpRes + ", notify from pid " + pid);
    }
  } catch (IOException e) {
    MonitorLog.e(TAG, "dump failed caused by " + e);
    e.printStackTrace();
  }
  return dumpRes;
}

首先第一步，调用init方法，其主要目的就是加载一些相应的so文件，如果涉及到了so，那么肯定涉及到C++层代码的分析，虽然C++写的不好，但是还是能看懂一点点的

private void init () {
  if (mLoadSuccess) {
    return;
  }
  if (loadSoQuietly("koom-fast-dump")) {
    mLoadSuccess = true;
    nativeInit();
  }
}

然后第二步，调用suspendAndFork方法，这是一个native方法，看注释意思是挂起ART，然后创建一个进程去dump内存快照

/**
 * Suspend the whole ART, and then fork a process for dumping hprof.
 *
 * @return return value of fork
 */
private native int suspendAndFork();

首先如果从从到位跟到源码，应该记得在调用dumpAndAnalysis方法的时候，是在协程中也就是子线程中进行的。

async {
  MonitorLog.i(TAG, "mTrackReasons:${mTrackReasons}")
  dumpAndAnalysis()
}

子线程中不行吗？子线程也不会阻塞主线程，看起来似乎没问题，KOOM为啥要单独fork出一个单独的子进程去完成dump？

其实这样做的一个好处就是，虽然是在子线程内，但是还是会产生内存垃圾（一边采集数据，一边申请内存也不合理），还是需要GC去STW清理，如果放在单独的进程中，就不会加快主进程的GC，也是尽可能避免在dump时发生崩溃影响主进程。

除此之外，还有一个核心问题，是需要通过源码来一探究竟，dump的时候，系统底层到底做了什么？

2.3.2 C++层分析dumpHprofData

当子进程dump内存快照的时候，调用的是C++层的dumpHprofData函数，我们找下C++的源码看下。

public static void dumpHprofData(String fileName) throws IOException {
    VMDebug.dumpHprofData(fileName);
}

首先在Java层调用JNI层的代码就是VMDebug_dumpHprofData这个函数，最终是调用了Hprof的DumpHeap函数。

static void VMDebug_dumpHprofData(JNIEnv* env, jclass, jstring javaFilename, jint javaFd) {
  // Only one of these may be null.
  if (javaFilename == nullptr && javaFd < 0) {
        ScopedObjectAccess soa(env);
        ThrowNullPointerException("fileName == null && fd == null");
        return;
      }

  std::string filename;
  if (javaFilename != nullptr) {
        ScopedUtfChars chars(env, javaFilename);
        if (env->ExceptionCheck()) {
              return;
            }
        filename = chars.c_str();
      } else {
        filename = "[fd]";
      }

  int fd = javaFd;
  /**调用Hprof的DumpHeap函数*/
  hprof::DumpHeap(filename.c_str(), fd, false);
}

在Hprof的DumpHeap函数中，创建了Hprof对象，并执行Dump方法，在此之前，我们可以看到是调用了ScopedSuspendAll。

void DumpHeap(const char* filename, int fd, bool direct_to_ddms) {
      CHECK(filename != nullptr);
      Thread* self = Thread::Current();
      // Need to take a heap dump while GC isn't running. See the comment in Heap::VisitObjects().
      // Also we need the critical section to avoid visiting the same object twice. See b/34967844
      gc::ScopedGCCriticalSection gcs(self,
            1607                                  gc::kGcCauseHprof,
            1608                                  gc::kCollectorTypeHprof);
      ScopedSuspendAll ssa(__FUNCTION__, true /* long suspend */);
      Hprof hprof(filename, fd, direct_to_ddms);
      hprof.Dump();
    }

也就是说，在dump之前，是需要挂起一切的，看到这里，我们可能就知道了，不管是主线程还是子线程，只要进行了dump操作，都需要STW的。

2.4 多线程场景下fork进程

因为在任意线程中dump都会导致STW，所以KOOM是通过fork进程的方式完成dump操作的

MonitorLog.i(TAG, "before suspend and fork.");
int pid = suspendAndFork();
if (pid == 0) {
  // Child process
  Log.e("TAG","父进程fork成功，子进程开始执行")
  Debug.dumpHprofData(path);
  exitProcess();
  Log.e("TAG","子进程执行完成，退出")
} else if (pid > 0) {
  Log.e("TAG","父进程fork成功，继续执行")
  // Parent process
  dumpRes = resumeAndWait(pid);
  MonitorLog.i(TAG, "dump " + dumpRes + ", notify from pid " + pid);
}

首先调用suspendAndFork创建一个子进程，如果pid == 0，说明当前进程为子进程，那么会进入代码块执行，然后紧接着进入下一个代码块，最终的日志打印就是：

父进程fork成功，子进程开始执行
父进程fork成功，继续执行
子进程执行完成，退出

这是属于正常的fork流程，但是如果是在多线程的环境下呢？

val thread = Thread{
   Log.e("TAG","do something")
}
thread.start()

MonitorLog.i(TAG, "before suspend and fork.");
int pid = suspendAndFork();
if (pid == 0) {
  // Child process
  Log.e("TAG","父进程fork成功，子进程开始执行")
  Debug.dumpHprofData(path);
  exitProcess();
  Log.e("TAG","子进程执行完成，退出")
} else if (pid > 0) {
  Log.e("TAG","父进程fork成功，继续执行")
  // Parent process
  dumpRes = resumeAndWait(pid);
  MonitorLog.i(TAG, "dump " + dumpRes + ", notify from pid " + pid);
}

这个时候，最终日志打印输出就是

父进程fork成功，子进程开始执行
父进程fork成功，继续执行

子进程被卡死了，为什么呢？这就需要了解在多线程的场景下fork进程，系统干了什么事！

因为Java或者Android天生就是多线程的，在fork进程时，我们可以在任意线程fork，在哪个线程fork，哪个线程就会被拷贝到子进程，并保留在父进程时的线程状态。 那么剩余其他的线程，将会被作为线程对象拷贝到子进程，包括线程的状态（runnable、running、wait等）。

例如在主线程中fork子进程，那么子进程中会有主线程这个真实的对象，其他线程均为虚假的，但依然还是一个对象。我们知道当系统执行dump的时候，会挂起一切线程，此时子进程中执行dump，虚假的线程是无法挂起的，此时子进程无法获取所有线程返回的结果，导致阻塞卡死。

还有一种场景：主进程中线程1持有一个锁对象，主线程和其他线程会竞争这个锁对象，那么在fork时，在子进程中这个锁也会被复制过去，在子进程中如果主线程想要竞争获取这个锁对象肯定是拿不到的，线程1已经是一个虚假的线程，无法释放该锁，就会导致主线程一直无法获取锁对象处于阻塞等待的状态；

那么KOOM是如何处理的呢，核心就在于suspendAndFork这个方法，在fork子进程之前先把所有的线程挂起，然后复制到子进程中的线程也是处于挂起的状态，就不会有卡死的这种情况发生；

然后在父进程中再次调用resumeAndWait方法，这个方法就会恢复线程的状态，虽然有一个短暂的挂起时间，但是相对于GC的频繁STW，简直不值一提了。

所以这里就有一个问题，我们知道在Android app启动的时候，通过zygote来fork出主进程，这个时候AMS与zygote进程之间通信是通过socket而不是binder，这是为啥呢？原因就在这里了，看到这儿应该就懂了吧。

3 总结

所以回到开篇那个问题，如果需要我们自己设计一套线上APM监控，对于内存这块我们是不是就已经很清楚了，首先我们需要知道什么情况下会导致OOM，然后通过系统API来完成数据化监控方案；然后针对Leakcanary等成熟的框架存在的弊端，进行优化，例如子进程dump内存快照避免主线程卡顿等，当然在面试的过程中，如果有这方面的问题，是不是也得心应手了。