正文
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
在这里我们模拟了一次资源回收的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对象之后,就持有这个引用,然后这个时候把这个对象置为空
ReferenceQueuereferenceQueue = new ReferenceQueue (); WeakReference weak = new WeakReference (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进程时系统干了什么事!
当在父进程中fork子进程的时候,父进程的线程也会被拷贝到子进程当中,但是这个时候线程已经不是一个线程了,而是一个对象,任何线程的特性都不再存在,例如:
(1)父进程线程持有一个锁对象,那么在子进程中这个锁也会被复制过去,在子进程中如果想要竞争获取这个锁对象肯定是拿不到的,因为在对象头中,这个是加锁的,那么就会造成死锁;
(2)因为在进程中进行dump的时候,是需要挂起线程的,因为此时线程都不再是一个线程,即便是调用挂起suspend也无效,无法获取任何线程的返回值,子进程直接卡死。
那么KOOM是如何处理的呢,核心就在于suspendAndFork这个方法,在fork子进程之前先把所有的线程挂起,然后复制到子进程中的线程也是处于挂起的状态,就不会有卡死的这种情况发生;
然后在父进程中再次调用resumeAndWait方法,这个方法就会恢复线程的状态,虽然有一个短暂的挂起时间,但是相对于GC的频繁STW,简直不值一提了。
所以这里就有一个问题,我们知道在Android app启动的时候,通过zygote来fork出主进程,这个时候AMS与zygote进程之间通信是通过socket而不是binder,这是为啥呢?原因就在这里了,看到这儿应该就懂了吧。
3 总结
所以回到开篇那个问题,如果需要我们自己设计一套线上APM监控,对于内存这块我们是不是就已经很清楚了,首先我们需要知道什么情况下会导致OOM,然后通过系统API来完成数据化监控方案;然后针对Leakcanary等成熟的框架存在的弊端,进行优化,例如子进程dump内存快照避免主线程卡顿等,当然在面试的过程中,如果有这方面的问题,是不是也得心应手了。
以上就是Android进阶KOOM线上APM监控全面剖析的详细内容,更多关于Android KOOM线上APM监控的资料请关注脚本之家其它相关文章!