大廠干掉 OOM 的套路，你知道幾個 ！

點擊關(guān)注公眾號，Java干貨及時送達??

文章來源：https://c1n.cn/5ug0H

• 前言

• OOM 問題分類

• 線程數(shù)太多

• 打開太多文件

• 內(nèi)存不足

• 總結(jié)

隨著項目不斷壯大，OOM（Out Of Memory）成為奔潰統(tǒng)計平臺上的疑難雜癥之一。

大部分業(yè)務(wù)開發(fā)人員對于線上 OOM 問題一般都是暫不處理：

• 一方面是因為 OOM 問題沒有足夠的 log，無法在短期內(nèi)分析解決。

• 另一方面可能是忙于業(yè)務(wù)迭代、身心疲憊，沒有精力去研究 OOM 的解決方案。

這篇文章將以線上 OOM 問題作為切入點，介紹常見的 OOM 類型、OOM 的原理、大廠 OOM 優(yōu)化黑科技、以及主流的 OOM 監(jiān)控方案。文章較長，請備好小板凳！

很多人對于 OOM 的理解就是 Java 虛擬機內(nèi)存不足，但通過線上 OOM 問題分析，OOM 可以大致歸為以下 3 類：

• 線程數(shù)太多

• 打開太多文件

• 內(nèi)存不足

接下來將分別圍繞這三類問題進行展開分析。

| 報錯信息

pthread_create?(1040KB?stack)?failed:?Out?of?memory

這個是典型的創(chuàng)建新線程觸發(fā)的 OOM 問題。

| 源碼分析

http://androidxref.com/9.0.0_r3/xref/art/runtime/thread.cc

void?Thread::CreateNativeThread(JNIEnv*?env,?jobject?java_peer,?size_t?stack_size,?bool?is_daemon)?{
??...
??pthread_create_result?=?pthread_create(...)
??//創(chuàng)建線程成功
??if?(pthread_create_result?==?0)?{
??????return;
??}
??//創(chuàng)建線程失敗
??...
??{
????std::string?msg(child_jni_env_ext.get()?==?nullptr??
????????StringPrintf("Could?not?allocate?JNI?Env:?%s",?error_msg.c_str())?:
????????StringPrintf("pthread_create?(%s?stack)?failed:?%s",
?????????????????????????????????PrettySize(stack_size).c_str(),?strerror(pthread_create_result)));
????ScopedObjectAccess?soa(env);
????soa.Self()->ThrowOutOfMemoryError(msg.c_str());
??}
}

pthread_create 里面會調(diào)用 Linux 內(nèi)核創(chuàng)建線程，那什么情況下會創(chuàng)建線程失敗呢？

查看系統(tǒng)對每個進程的線程數(shù)限制：

cat?/proc/sys/kernel/threads-max

不同設(shè)備的 threads-max 限制是不一樣的，有些廠商的低端機型 threads-max 比較小，容易出現(xiàn)此類 OOM 問題。

查看當前進程運行的線程數(shù)：

cat?proc/{pid}/status

當線程數(shù)超過 /proc/sys/kernel/threads-max 中規(guī)定的上限時就會觸發(fā) OOM。

既然系統(tǒng)對每個進程的線程數(shù)有限制，那么解決這個問題的關(guān)鍵就是盡可能降低線程數(shù)的峰值。

| 線程優(yōu)化

①禁用 new Thread

解決線程過多問題，傳統(tǒng)的方案是禁止使用 new Thread，統(tǒng)一使用線程池，但是一般很難人為控制， 可以在代碼提交之后觸發(fā)自動檢測，有問題則通過郵件通知對應(yīng)開發(fā)人員。

不過這種方式存在兩個問題：

• 無法解決老代碼的 new Thread

• 對于第三方庫無法控制

②無侵入性的 new Thread 優(yōu)化

Java 層的 Thread 只是一個普通的對象，只有調(diào)用了 start 方法，才會調(diào)用 native 層去創(chuàng)建線程。

所以理論上我們可以自定義 Thread，重寫 start 方法，不去啟動線程，而是將任務(wù)放到線程池中去執(zhí)行，為了做到無侵入性，需要在編譯期通過字節(jié)碼插樁的方式，將所有 new Thread 字節(jié)碼都替換成 new 自定義 Thread。

步驟如下：

public?class?ShadowThread?extends?Thread?{

????@Override
????public?synchronized?void?start()?{
????????Log.i("ShadowThread",?"start,name="+?getName());
????????CustomThreadPool.THREAD_POOL_EXECUTOR.execute(new?MyRunnable(getName()));
????}

????class?MyRunnable?implements?Runnable?{

????????String?name;
????????public?MyRunnable(String?name){
????????????this.name?=?name;
????????}

????????@Override
????????public?void?run()?{
????????????try?{
????????????????ShadowThread.this.run();
????????????????Log.d("ShadowThread","run?name="+name);
????????????}?catch?(Exception?e)?{
????????????????Log.w("ShadowThread","name="+name+",exception:"+?e.getMessage());
????????????????RuntimeException?exception?=?new?RuntimeException("threadName="+name+",exception:"+?e.getMessage());
????????????????exception.setStackTrace(e.getStackTrace());
????????????????throw?exception;
????????????}
????????}
????}
}

在編譯期，hook 所有 new Thread 字節(jié)碼，全部替換成我們自定義的 ShadowThread，這個難度應(yīng)該不大，按部就班，我們先確認 new Thread 和 new ShadowThread 對應(yīng)字節(jié)碼差異。

由于將任務(wù)放到線程池去執(zhí)行，假如線程奔潰了，我們不知道是哪個線程出問題，所以自定義 ShadowThread 中的內(nèi)部類 MyRunnable 的作用是：在線程出現(xiàn)異常的時候，將異常捕獲，還原它的名字，重新拋出一個信息更全的異常。

????private?fun?testThreadCrash()?{
????????Thread?{
????????????val?i?=?9?/?0
????????}.apply?{
????????????name?=?"testThreadCrash"
????????}.start()
????}

可以看到原本的 new Thread 已經(jīng)被優(yōu)化成了 CustomThreadPool 線程池調(diào)用，并且奔潰的時候不用擔心找不到線程是哪里創(chuàng)建的，會還原線程名。

當然這種方式有一個小問題，應(yīng)用正常運行的情況下，如果你想要收集所有線程信息，那么線程名可能不太準確，因為通過 new Thread 去創(chuàng)建線程，已經(jīng)被替換成線程池調(diào)用了，獲取到的線程名是線程池中的線程的名字。

數(shù)據(jù)對比：同個場景簡單測試了一下 new Thread 優(yōu)化前后線程數(shù)峰值對比如下圖。

對于不同 App，優(yōu)化效果會有一些不同，不過可以看到這個優(yōu)化確實是有效的。

③無侵入的線程池優(yōu)化

????public?ThreadPoolExecutor(int?corePoolSize,
??????????????????????????????int?maximumPoolSize,
??????????????????????????????long?keepAliveTime,
??????????????????????????????TimeUnit?unit,
??????????????????????????????BlockingQueue?workQueue,
??????????????????????????????ThreadFactory?threadFactory)?{
????????this(corePoolSize,?maximumPoolSize,?keepAliveTime,?unit,?workQueue,
?????????????threadFactory,?defaultHandler);
????}

線程池幾個參數(shù)：

• corePoolSize：核心線程數(shù)量。核心線程默認情況下即使空閑也不會釋放，除非設(shè)置 allowCoreThreadTimeOut 為 true。

• maximumPoolSize：最大線程數(shù)量。任務(wù)數(shù)量超過核心線程數(shù)，就會將任務(wù)放到隊列中，隊列滿了，就會啟動非核心線程執(zhí)行任務(wù)，線程數(shù)超過這個限制就會走拒絕策略。

• keepAliveTime：空閑線程存活時間。

• unit：時間單位。

• workQueue：隊列。任務(wù)數(shù)量超過核心線程數(shù)，就會將任務(wù)放到這個隊列中，直到隊列滿，就開啟新線程，執(zhí)行隊列第一個任務(wù)。

• threadFactory：線程工廠。實現(xiàn) new Thread 方法創(chuàng)建線程。

通過線程池參數(shù)，我們可以找到優(yōu)化點如下：

• 限制空閑線程存活時間，keepAliveTime?設(shè)置小一點，例如 1-3s

• 允許核心線程在空閑時自動銷毀

executor.allowCoreThreadTimeOut(true)

如何做呢？為了做到無侵入性，依然采用 ASM 操作字節(jié)碼，跟 new Thread 的替換基本同理。

在編譯期，通過 ASM，做如下幾個操作：

• 將調(diào)用 Executors 類的靜態(tài)方法替換為自定義 ShadowExecutors 的靜態(tài)方法，設(shè)置 executor.allowCoreThreadTimeOut(true)；

• 將調(diào)用 ThreadPoolExecutor 類的構(gòu)造方法替換為自定義 ShadowThreadPoolExecutor 的靜態(tài)方法，設(shè)置 executor.allowCoreThreadTimeOut(true)；

• 可以在 Application 類的?()?中調(diào)用我們自定義的靜態(tài)方法 ShadowAsyncTask.optimizeAsyncTaskExecutor()?來修改 AsyncTask 的線程池參數(shù)，調(diào)用 executor.allowCoreThreadTimeOut(true)；

https://booster.johnsonlee.io/zh/guide/performance/multithreading-optimization.html#%E7%BA%BF%E7%A8%8B%E7%AE%A1%E7%90%86%E9%9D%A2%E4%B8%B4%E7%9A%84%E6%8C%91%E6%88%98

| 線程監(jiān)控

假如線程優(yōu)化后還存在創(chuàng)建線程 OOM 問題，那我們就需要監(jiān)控是否存在線程泄漏的情況。

①線程泄漏監(jiān)控

主要監(jiān)控 native 線程的幾個生命周期方法：

• pthread_create

• pthread_detach

• pthread_join

• pthread_exit

hook 以上幾個方法，用于記錄線程的生命周期和堆棧，名稱等信息；當發(fā)現(xiàn)一個 joinable 的線程在沒有 detach 或者 join 的情況下，執(zhí)行了 pthread_exit，則記錄下泄露線程信息；在合適的時機，上報線程泄露信息。

linux 線程中，pthread 有兩種狀態(tài) joinable 狀態(tài)和 unjoinable 狀態(tài)。

joinable 狀態(tài)下，當線程函數(shù)自己返回退出時或 pthread_exit 時都不會釋放線程所占用堆棧和線程描述符。

只有當你調(diào)用了 pthread_join 之后這些資源才會被釋放，需要 main 函數(shù)或者其他線程去調(diào)用 pthread_join 函數(shù)。

https://github.com/KwaiAppTeam/KOOM/blob/master/koom-thread-leak/src/main/cpp/src/thread/thread_holder.cpp

②線程上報

當監(jiān)控到線程有異常的時候，我們可以收集線程信息，上報到后臺進行分析。

????private?fun?dumpThreadIfNeed()?{

????????val?threadNames?=?runCatching?{?File("/proc/self/task").listFiles()?}
????????????.getOrElse?{
????????????????return@getOrElse?emptyArray()
????????????}
?????????????.map?{
????????????????runCatching?{?File(it,?"comm").readText()?}.getOrElse?{?"failed?to?read?$it/comm"?}
????????????}
?????????????.map?{
????????????????if?(it.endsWith("\n"))?it.substring(0,?it.length?-?1)?else?it
????????????}
?????????????:?emptyList()

????????Log.d("TAG",?"dumpThread?=?"?+?threadNames.joinToString(separator?=?","))
????}

接下來介紹打開太多文件導(dǎo)致的 OOM 問題。

| 錯誤信息

E/art:?ashmem_create_region?failed?for?'indirect?ref?table':?Too?many?open?files
Java.lang.OutOfMemoryError:?Could?not?allocate?JNI?Env

這個問題跟系統(tǒng)、廠商關(guān)系比較大。

| 系統(tǒng)限制

ulimit?-n

Linux 系統(tǒng)一切皆文件，進程每打開一個文件就會產(chǎn)生一個文件描述符 fd（記錄在 /proc/pid/fd 下面）。

cd?/proc/10654/fd
ls

當 fd 的數(shù)目達到 Max open files 規(guī)定的數(shù)目，就會觸發(fā) Too many open files 的奔潰，這種奔潰在低端機上比較容易復(fù)現(xiàn)。

知道了文件描述符這玩意后，看看怎么優(yōu)化。

| 文件描述符優(yōu)化

對于打開文件數(shù)太多的問題，盲目優(yōu)化其實無從下手，總體的方案是監(jiān)控為主。

????private?fun?dumpFd()?{
????????val?fdNames?=?runCatching?{?File("/proc/self/fd").listFiles()?}
????????????.getOrElse?{
????????????????return@getOrElse?emptyArray()
????????????}
?????????????.map?{?file?->
????????????????runCatching?{?Os.readlink(file.path)?}.getOrElse?{?"failed?to?read?link?${file.path}"?}
????????????}
?????????????:?emptyList()

????????Log.d("TAG",?"dumpFd:?size=${fdNames.size},fdNames=$fdNames")

????}

| 文件描述符監(jiān)控

監(jiān)控策略：?當 fd 數(shù)大于 1000 個，或者 fd 連續(xù)遞增超過 50 個，就觸發(fā) fd 收集，將 fd 對應(yīng)的文件路徑上報到后臺。

當懷疑某個文件有問題之后，我們還需要知道這個文件在哪創(chuàng)建，是誰創(chuàng)建的，這個就涉及到 IO 監(jiān)控。

| IO 監(jiān)控

①監(jiān)控內(nèi)容

監(jiān)控完整的 IO 操作，包括：

• open：獲取文件名、fd、文件大小、堆棧、線程。

• read/write：獲取文件類型、讀寫次數(shù)、總大小，使用 buffer 大小、讀寫總耗時。

• close：打開文件總耗時、最大連續(xù)讀寫時間。

②Java 監(jiān)控方案

java?:?FileInputStream?->?IoBridge.open?->?Libcore.os.open?->??
?BlockGuardOs.open?->?Posix.open

http://androidxref.com/6.0.1_r10/xref/libcore/luni/src/main/java/libcore/io/Libcore.java

package?libcore.io;
public?final?class?Libcore?{
????private?Libcore()?{?}

????public?static?Os?os?=?new?BlockGuardOs(new?Posix());
}

http://androidxref.com/6.0.1_r10/xref/libcore/luni/src/main/java/libcore/io/BlockGuardOs.java

//?反射獲得靜態(tài)變量
Class?clibcore?=?Class.forName("libcore.io.Libcore");
Field?fos?=?clibcore.getDeclaredField("os");

//?動態(tài)代理對象
Proxy.newProxyInstance(cPosix.getClassLoader(),?getAllInterfaces(cPosix),?this);

beforeInvoke(method,?args,?throwable);
result?=?method.invoke(mPosixOs,?args);
afterInvoke(method,?args,?result);

此方案缺點如下：

• 性能差，IO 調(diào)用頻繁，使用動態(tài)代理和 Java 的字符串操作，導(dǎo)致性能較差，無法達到線上使用標準。

• 無法監(jiān)控 Native 代碼，這個也是比較重要的。

• 兼容性差：需要根據(jù) Android 版本做適配，特別是 Android P 的非公開 API 限制。

③Native 監(jiān)控方案

int?open(const?char?*pathname,?int?flags,?mode_t?mode);
ssize_t?read(int?fd,?void?*buf,?size_t?size);
ssize_t?write(int?fd,?const?void?*buf,?size_t?size);?write_cuk
int?close(int?fd);

我們需要選擇一些有調(diào)用上面幾個方法的 library，例如選擇 libjavacore.so、libopenjdkjvm.so、libopenjdkjvm.so，可以覆蓋到所有的 Java 層的 I/O 調(diào)用。

open64
__read_chk
__write_chk

https://github.com/iqiyi/xHook/blob/master/README.zh-CN.md

https://github.com/bytedance/bhook/blob/main/doc/overview.zh-CN.md

https://github.com/Tencent/matrix/blob/master/matrix/matrix-android/matrix-io-canary/src/main/cpp/io_canary_jni.cc

關(guān)于 IO 涉及到的知識非常多，后面有時間可以單獨整理一篇文章。接下來看看最后一種 OOM 類型。

| 堆棧信息

這種是最常見的 OOM，Java 堆內(nèi)存不足，512M 都不夠玩，發(fā)生此問題的大部分設(shè)備都是 Android 7.0，高版本也有，不過相對較少。

| 重溫 JVM 內(nèi)存結(jié)構(gòu)

JVM 在運行時，將內(nèi)存劃分為以下 5 個部分：

• 方法區(qū)：存放靜態(tài)變量、常量、即時編譯代碼

• 程序計數(shù)器：線程私有，記錄當前執(zhí)行的代碼行數(shù)，方便在 cpu 切換到其它線程再回來的時候能夠不迷路

• Java 虛擬機棧：線程私有，一個 Java 方法開始和結(jié)束，對應(yīng)一個棧幀的入棧和出棧，棧幀里面有局部變量表、操作數(shù)棧、返回地址、符號引用等信息

• 本地方法棧：線程私有，跟 Java 虛擬機棧的區(qū)別在于 這個是針對 native 方法

• 堆：絕大部分對象創(chuàng)建都在堆分配內(nèi)存

內(nèi)存不足導(dǎo)致的 OOM，一般都是由于 Java 堆內(nèi)存不足，絕大部分對象都是在堆中分配內(nèi)存，除此之外，大數(shù)組、以及 Android3.0-7.0 的 Bitmap 像素數(shù)據(jù)，都是存放在堆中。

Java 堆內(nèi)存不足導(dǎo)致的 OOM 問題，線上難以復(fù)現(xiàn)，往往比較難定位到問題，絕大部分設(shè)備都是 8.0 以下的，主要也是由于 Android 3.0-7.0 Bitmap 像素內(nèi)存是存放在堆中導(dǎo)致的。

基于這個結(jié)論，關(guān)于 Java 堆內(nèi)存不足導(dǎo)致的 OOM 問題，優(yōu)化方案主要是圖片加載優(yōu)化、內(nèi)存泄漏監(jiān)控。

| 圖片加載優(yōu)化

①常規(guī)的圖片優(yōu)化方式

https://juejin.cn/post/6844903986412126216

文章核心內(nèi)容大概如下：

• 分析了主流圖片庫 Glide 和 Fresco 的優(yōu)缺點，以及使用場景

• 分析了設(shè)計一個圖片加載框架需要考慮的問題

• 防止圖片占用內(nèi)存過多導(dǎo)致 OOM 的三個方式：軟引用、onLowMemory、Bitmap ?像素存儲位置

這篇文章現(xiàn)在來看還是有點意義的，其中的原理部分還沒過時，不過技術(shù)更新迭代，常規(guī)的優(yōu)化方式已經(jīng)不太夠了，長遠考慮，可以做圖片自動壓縮、大圖自動檢測和告警。

②無侵入性自動壓縮圖片

針對圖片資源，設(shè)計師往往會追求高清效果，忽略圖片大小，一般的做法是拿到圖后手動壓縮一下，這種手動的操作完全看個人修養(yǎng)。

無侵入性自動壓縮圖片，主流的方案是利用 Gradle 的 Task 原理，在編譯過程中，mergeResourcesTask 這個任務(wù)是將所有 aar、module 的資源進行合并，我們可以在 mergeResourcesTask 之后可以拿到所有資源文件。

具體做法：

• 在 mergeResourcesTask 這個任務(wù)后面，增加一個圖片處理的 Task，拿到所有資源文件

• 拿到所有資源文件后，判斷如果是圖片文件，則通過壓縮工具進行壓縮，壓縮后如果圖片有變小，就將壓縮過的圖片替換掉原圖

https://github.com/smallSohoSolo/McImage

| 大圖監(jiān)控

上文的自動壓縮圖片只是針對本地資源，而對于網(wǎng)絡(luò)圖片，如果加載的時候沒有壓縮，那么內(nèi)存占用會比較大，這種情況就需要監(jiān)控了。

①從圖片框架側(cè)監(jiān)控

很多 App 內(nèi)部可能使用了多個圖片庫，例如 Glide、Picasso、Fresco、ImageLoader、Coil，如果想監(jiān)控某個圖片框架， 那么我們需要熟讀源碼，找到 hook 點。

對于 Glide，可以通過 hook SingleRequest，它里面有個 requestListeners，我們可以注冊一個自己的監(jiān)聽，圖片加載完做一個大圖檢測。

https://github.com/didi/DoraemonKit/blob/master/Android/buildSrc/src/main/kotlin/com/didichuxing/doraemonkit/plugin/classtransformer/BigImgClassTransformer.kt

②從 ImageView 側(cè)監(jiān)控

上面是從圖片加載框架側(cè)監(jiān)控大圖，假如項目中使用到的圖片加載框架太多，有些第三方 SDK 內(nèi)部可能自己搞了圖片加載。

這種情況下我們可以從 ImageView 控件側(cè)做監(jiān)控，監(jiān)聽 setImageDrawable 等方法，計算圖片大小如果大于控件本身大小，debug 包可以彈窗提示需要修改。

方案如下：

• 自定義 ImageView，重寫 setImageDrawable、setImageBitmap、setImageResource、setBackground、setBackgroundResource 這幾個方法，在這些方法里面，檢測 Drawable 大小

• 編譯期，修改字節(jié)碼，將所有 ImageView 的創(chuàng)建都替換成自定義的 ImageView

• 為了不影響主線程，可以使用 IdleHandler，在主線程空閑的時候再檢測

最終是希望當檢測到大圖的時候，debug 環(huán)境能夠彈窗提示開發(fā)進行修改，release 環(huán)境可以上報后臺。

當然這種方案有個缺點：不能獲取到圖片 url。圖片優(yōu)化告一段落，接下來看看內(nèi)存泄漏。

| 內(nèi)存泄漏監(jiān)控演進

①LeakCanary

https://github.com/square/leakcanary/

debugImplementation?'com.squareup.leakcanary:leakcanary-android:2.8.1'

就能實現(xiàn)自動檢測和分析內(nèi)存泄漏，并發(fā)出一個通知顯示內(nèi)存泄漏詳情信息。

LeakCanary 只能在 debug 環(huán)境使用，因為它是在當前進程 dump 內(nèi)存快照，Debug.dumpHprofData(path); 會凍結(jié)當前進程一段時間，整個 APP 會卡死約 5～15s，低端機上可能要幾十秒的時間。

②ResourceCanary

微信對 LeakCanary 做了一些改造，將檢測和分析分離，客戶端只負責檢測和 dump 內(nèi)存鏡像文件，文件裁剪后上報到服務(wù)端進行分析。

https://mp.weixin.qq.com/s/XL55txToSCJXM8ErwrUGMw

③KOOM

https://github.com/KwaiAppTeam/KOOM/blob/master/README.zh-CN.md

| 線上內(nèi)存泄漏監(jiān)控方案

基于 KOOM 源碼分析：

①檢測時機

間隔 5s 檢測一次；觸發(fā)內(nèi)存鏡像采集的條件。

??????//->OOMMonitorConfig

??????private?val?DEFAULT_HEAP_THRESHOLD?by?lazy?{
????????val?maxMem?=?SizeUnit.BYTE.toMB(Runtime.getRuntime().maxMemory())
????????when?{
??????????maxMem?>=?512?-?10?->?0.8f
??????????maxMem?>=?256?-?10?->?0.85f
??????????else?->?0.9f
????????}
??????}

兩次檢測時間內(nèi)（例如 5s 內(nèi)），內(nèi)存使用率增加 5%。

②內(nèi)存鏡像采集

我們知道 LeakCanary 檢測內(nèi)存泄漏，不能用于線上，是因為它 dump 內(nèi)存鏡像是在當前進程進行操作，會凍結(jié) App 一段時間。

所以，作為線上 OOM 監(jiān)控，dump 內(nèi)存鏡像需要單獨開一個進程。

整體的策略是：虛擬機 supend→fork 虛擬機進程→虛擬機 resume→dump 內(nèi)存鏡像的策略。

??//->ForkJvmHeapDumper

??public?boolean?dump(String?path)?{
????...

????boolean?dumpRes?=?false;
????try?{
??????//1、通過fork函數(shù)創(chuàng)建子進程，會返回兩次，通過pid判斷是父進程還是子進程
??????int?pid?=?suspendAndFork();

??????MonitorLog.i(TAG,?"suspendAndFork,pid="+pid);
??????if?(pid?==?0)?{
????????//2、子進程返回，dump內(nèi)存操作，dump內(nèi)存完成，退出子進程
????????Debug.dumpHprofData(path);
????????exitProcess();
??????}?else?if?(pid?>?0)?{
????????//?3、父進程返回，恢復(fù)虛擬機，將子進程的pid傳過去，阻塞等待子進程結(jié)束
????????dumpRes?=?resumeAndWait(pid);
????????MonitorLog.i(TAG,?"notify?from?pid?"?+?pid);
??????}
????}
????return?dumpRes;
??}

注釋 1：父進程調(diào)用 native 方法掛起虛擬機，并且創(chuàng)建子進程；

注釋 2：子進程創(chuàng)建成功，執(zhí)行 Debug.dumpHprofData，執(zhí)行完后退出子進程；

注釋 3：得知子進程創(chuàng)建成功后，父進程恢復(fù)虛擬機，解除凍結(jié)，并且當前線程等待子進程結(jié)束。

//?->native_bridge.cpp

pid_t?HprofDump::SuspendAndFork()?{
??//1、暫停VM，不同Android版本兼容
??if?(android_api_?????suspend_vm_fnc_();
??}
??...

??//2，fork子進程,通過返回值可以判斷是主進程還是子進程
??pid_t?pid?=?fork();
??if?(pid?==?0)?{
????//?Set?timeout?for?child?process
????alarm(60);
????prctl(PR_SET_NAME,?"forked-dump-process");
??}
??return?pid;
}

//->hprof_dump.cpp

bool?HprofDump::ResumeAndWait(pid_t?pid)?{
??//1、恢復(fù)虛擬機，兼容不同Android版本
??if?(android_api_?????resume_vm_fnc_();
??}
??...
??int?status;
??for?(;;)?{
????//2、waitpid,等待子進程結(jié)束
????if?(waitpid(pid,?&status,?0)?!=?-1?||?errno?!=?EINTR)?{
??????//進程異常退出
??????if?(!WIFEXITED(status))?{
????????ALOGE("Child?process?%d?exited?with?status?%d,?terminated?by?signal?%d",
??????????????pid,?WEXITSTATUS(status),?WTERMSIG(status));
????????return?false;
??????}
??????return?true;
????}
????return?false;
??}
}

這里主要是利用 Linux 的 waitpid 函數(shù)，主進程可以等待子進程 dump 結(jié)束，然后再返回執(zhí)行內(nèi)存鏡像文件分析操作。

③內(nèi)存鏡像分析

?//->HeapAnalysisService

??override?fun?onHandleIntent(intent:?Intent?)?{
????...
????kotlin.runCatching?{
??????//1、通過shark將hprof文件轉(zhuǎn)換成HeapGraph對象
??????buildIndex(hprofFile)
????}
????...
????//2、將設(shè)備信息封裝成json
????buildJson(intent)

????kotlin.runCatching?{
??????//3、過濾泄漏對象，有幾個規(guī)制
??????filterLeakingObjects()
????}
????...
????kotlin.runCatching?{
??????//?4、gcRoot是否可達，判斷內(nèi)存泄漏
??????findPathsToGcRoot()
????}
????...

????//5、泄漏信息填充到j(luò)son中，然后結(jié)束了
????fillJsonFile(jsonFile)


????//通知主進程內(nèi)存泄漏分析成功
????resultReceiver?.send(AnalysisReceiver.RESULT_CODE_OK,?null)

????//這個服務(wù)是在單獨進程，分析完就退出
????System.exit(0);
??}

內(nèi)存鏡像分析的流程如下：

• 通過 shark 這個開源庫將 hprof 文件轉(zhuǎn)換成 HeapGraph 對象。

• 收集設(shè)備信息，封裝成 json，現(xiàn)場信息很重要。

• filterLeakingObjects：過濾出泄漏的對象，有一些規(guī)制，例如已經(jīng) destroyed 和 finished 的 activity、fragment manager 為空的 fragment、已經(jīng) destroyed 的 window 等。

• findPathsToGcRoot：內(nèi)存泄漏的對象，查找其到 GcRoot 的路徑，通過這一步就可以揪出內(nèi)存泄漏的原因。

• fillJsonFile：格式化輸出內(nèi)存泄漏信息。

| 小結(jié)

線上 Java 內(nèi)存泄漏監(jiān)控方案分析，這里小結(jié)一下：

• 掛起當前進程，然后通過 fork 創(chuàng)建子進程

• fork 會返回兩次，一次是子進程，一次是父進程，通過返回的 pid 可以判斷是子進程還是父進程

• 如果是父進程返回，則通過 resumeAndWait 恢復(fù)進程，然后當前線程阻塞等待子進程結(jié)束

• 如果子進程返回，通過 Debug.dumpHprofData(path) 讀取內(nèi)存鏡像信息，這個會比較耗時，執(zhí)行結(jié)束就退出子進程

• 子進程退出，父進程的 resumeAndWait 就會返回，這時候就可以開啟一個服務(wù)，后臺分析內(nèi)存泄漏情況，這塊跟 LeakCanary 的分析內(nèi)存泄漏原理基本差不多

不畫圖了，結(jié)合源碼看應(yīng)該可以理解。

對于 Java 內(nèi)存泄漏監(jiān)控，線下我們可以使用 LeakCanary、線上可以使用 KOOM，而對于 native 內(nèi)存泄漏應(yīng)該如何監(jiān)控呢？

方案如下：

• 首先要了解 native 層。

• 申請內(nèi)存的函數(shù)：malloc、realloc、calloc、memalign、posix_memalign。

• 釋放內(nèi)存的函數(shù)：free。

• hook 申請內(nèi)存和釋放內(nèi)存的函數(shù)。

那怎么判斷 native 內(nèi)存泄漏呢？

• 周期性的使用?mark-and-sweep?分析整個進程 Native Heap，獲取不可達的內(nèi)存塊信息「地址、大小」

• 獲取到不可達的內(nèi)存塊的地址后，可以從我們的 Map 中獲取其堆棧、內(nèi)存大小、地址、線程等信息

https://github.com/KwaiAppTeam/KOOM/blob/master/koom-native-leak/README.zh-CN.md

本文從線上 OOM 問題入手，介紹了 OOM 原理， 以及 OOM 優(yōu)化方案和監(jiān)控方案，基本上都是大廠開源出來的比較成熟的方案：

• 對于 pthread_create OOM 問題，介紹了無侵入性的 new Thread 優(yōu)化、無侵入性的線程池優(yōu)化、以及線程泄漏監(jiān)控

• 對于文件描述符過多問題，介紹了原理以及文件描述符監(jiān)控方案、IO 監(jiān)控方案

• 對于 Java 內(nèi)存不足導(dǎo)致的 OOM、介紹了無侵入性圖片自動壓縮方案、兩種無侵入性的大圖監(jiān)控方案、Java 內(nèi)存泄漏監(jiān)控的線下方案和線上方案、以及 native 內(nèi)存泄漏監(jiān)控方案。

大廠對外開源的技術(shù)非常多，但不一定最優(yōu)，我們在學(xué)習(xí)過程中可以多加思考， 例如線程優(yōu)化，booster 對于 new Thread 的優(yōu)化只是設(shè)置了線程名，有助于分析問題，而經(jīng)過我的猜想和驗證，通過字節(jié)碼插樁，將 new Thread 無侵入性替換成線程池調(diào)用，才是真正意義上的線程優(yōu)化。

https://github.com/lanshifu

1.?從 7 分鐘到 10 秒，Mybatis 批處理真的很強！
2.?美哭了，一款面向程序員的 Markdown 筆記應(yīng)用
3.?4種 Redis 集群方案介紹+優(yōu)缺點對比
4.?如何保證 Controller 的并發(fā)安全?
最近面試BAT，整理一份面試資料《Java面試BATJ通關(guān)手冊》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：點“在看”，關(guān)注公眾號并回復(fù)?Java?領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
PS：因公眾號平臺更改了推送規(guī)則，如果不想錯過內(nèi)容，記得讀完點一下“在看”，加個“星標”，這樣每次新文章推送才會第一時間出現(xiàn)在你的訂閱列表里。
點“在看”支持小哈呀，謝謝啦??