本地驗(yàn)證

實(shí)驗(yàn)一：
?觸發(fā)大量網(wǎng)絡(luò)連接（每個連接處于獨(dú)立的線程中）并保持勺鸦，每打開一個socket都會增加一個fd（/proc/pid/fd下多一項(xiàng)）
?注：不只有這一種增加fd數(shù)的方式并巍，也可以用其他方法，比如打開文件换途，創(chuàng)建handlerthread等等

• 實(shí)驗(yàn)預(yù)期：
  當(dāng)進(jìn)程fd數(shù)（可以通過 ls /proc/pid/fd | wc -l 獲得）突破 /proc/pid/limits中規(guī)定的Max open files時履澳，產(chǎn)生OOM
• 實(shí)驗(yàn)結(jié)果：
  當(dāng)fd數(shù)目到達(dá) /proc/pid/limits中規(guī)定的Max open files時，繼續(xù)開線程確實(shí)會導(dǎo)致OOM的產(chǎn)生怀跛。錯誤信息及堆棧如下：

E/art: ashmem_create_region failed for 'indirect ref table': Too many open files
E/AndroidRuntime: FATAL EXCEPTION: main
                  Process: com.netease.demo.oom, PID: 2435
                  java.lang.OutOfMemoryError: Could not allocate JNI Env
                      at java.lang.Thread.nativeCreate(Native Method)
                      at java.lang.Thread.start(Thread.java:730)
                      ......

????????圖3-5 FD數(shù)超限導(dǎo)致OOM的詳細(xì)信息
?可以看出，此OOM發(fā)生時的錯誤信息確與線上發(fā)現(xiàn)的OOM一的“Could not allocate JNI Env”吻合柄冲，因此線上上報的OOM一可能就是由FD數(shù)超限導(dǎo)致的吻谋，不過最終確定需要到線上進(jìn)行驗(yàn)證(下一小節(jié)).
?此外從ART虛擬機(jī)的Log中看出，還有一個關(guān)鍵的信息“ art: ashmem_create_region failed for 'indirect ref table': Too many open files”现横，后面會用于問題定位及解釋漓拾。

實(shí)驗(yàn)二：
?創(chuàng)建大量的空線程（不做任何事情，直接sleep）

• 實(shí)驗(yàn)預(yù)期：
  當(dāng)線程數(shù)（可以在/proc/pid/status中的threads項(xiàng)實(shí)時查看）超過/proc/sys/kernel/threads-max中規(guī)定的上限時產(chǎn)生OOM崩潰

• 實(shí)驗(yàn)結(jié)果：

1. 在Android7.0及以上的華為手機(jī)（EmotionUI_5.0及以上）的手機(jī)產(chǎn)生OOM戒祠，這些手機(jī)的線程數(shù)限制都很小(應(yīng)該是華為rom特意修改的limits)骇两，每個進(jìn)程只允許最大同時開500個線程，因此很容易復(fù)現(xiàn)了姜盈。OOM時錯誤信息如下：

W libc    : pthread_create failed: clone failed: Out of memory
W art     : Throwing OutOfMemoryError "pthread_create (1040KB stack) failed: Out of memory"
E AndroidRuntime: FATAL EXCEPTION: main
                  Process: com.netease.demo.oom, PID: 4973
                  java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Out of memory
                      at java.lang.Thread.nativeCreate(Native Method)
                      at java.lang.Thread.start(Thread.java:745)
                      ......

????????圖3-6 線程數(shù)超限導(dǎo)致的OOM詳細(xì)信息
?可以看出錯誤信息與我們線上遇到的OOM二吻合："pthread_create (1040KB stack) failed: Out of memory"
?另外ART虛擬機(jī)還有一個關(guān)鍵Log：“pthread_create failed: clone failed: Out of memory”低千，后面會用于問題定位及解釋。

2. 其他Rom的手機(jī)線程數(shù)的上限都比較大馏颂，不容易復(fù)現(xiàn)上述問題示血。但是，對于32位的系統(tǒng)救拉，當(dāng)進(jìn)程的邏輯地址空間不夠的時候也會產(chǎn)生OOM,每個線程通常需要mapp 1MB左右的stack空間（stack大小可以自行設(shè)置）难审，32為系統(tǒng)進(jìn)程邏輯地址4GB，用戶空間少于3GB亿絮。邏輯地址空間不夠（已用邏輯空間地址可以查看/proc/pid/status中的VmPeak/VmSize記錄）告喊，此時創(chuàng)建線程產(chǎn)生的OOM具有如下信息：

W/libc: pthread_create failed: couldn't allocate 1069056-bytes mapped space: Out of memory
W/art: Throwing OutOfMemoryError "pthread_create (1040KB stack) failed: Try again"
E/AndroidRuntime: FATAL EXCEPTION: main
                  Process: com.netease.demo.oom, PID: 8638
                  java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Try again
                       at java.lang.Thread.nativeCreate(Native Method)
                       at java.lang.Thread.start(Thread.java:1063)
                       ......

????????圖3-7 邏輯地址空間占滿導(dǎo)致的OOM

線上驗(yàn)收及問題解決

?本地嘗試復(fù)現(xiàn)的OOM錯誤信息中圖[3-5]與線上OOM一情況比較吻合，圖[3-6]與線上OOM二的情況比較吻合派昧，但線上的OOM一真的時FD數(shù)目超限黔姜，OOM二真的是由于華為手機(jī)線程數(shù)超限的原因?qū)е碌膯幔孔罱K確定還需要取線上設(shè)備的數(shù)據(jù)進(jìn)行驗(yàn)證．

驗(yàn)證方法：
?下發(fā)插件到線上用戶蒂萎，當(dāng)Thread.UncaughtExceptionHandler捕獲到OutOfMemoryError時記錄/proc/pid目錄下的如下信息：

1. /proc/pid/fd目錄下文件數(shù)(fd數(shù))
2. /proc/pid/status中threads項(xiàng)（當(dāng)前線程數(shù)目）
3. OOM的日志信息（出了堆棧信息還包含其他的一些warning信息

線上OOM一驗(yàn)證
?發(fā)生OOM一的線上設(shè)備中采集到的信息：

1. /proc/pid/fd目錄下文件數(shù)與/proc/pid/limits中的Max open files 數(shù)目持平地淀，證明FD數(shù)目已經(jīng)滿了
2. 崩潰時日志信息與圖[3-5]基本一致

由此，證明線上的OOM一確實(shí)是由于FD數(shù)目過多導(dǎo)致的OOM岖是，推斷驗(yàn)證成功．

OOM一的定位與解決：
?最終原因是App中使用的長連接庫再某些時候會有瞬時發(fā)出大量http請求的bug(導(dǎo)致FD數(shù)激增)帮毁，已修復(fù)

線上OOM二驗(yàn)證
?集中在華為系統(tǒng)的OOM二崩潰時收集到的信息樣例如下实苞，（收集的樣例中包含的devicemodel有VKY-AL00，TRT-AL00A烈疚，BLN-AL20黔牵，BLN-AL10，DLI-AL10爷肝，TRT-TL10猾浦，WAS-AL00等）：

1. /proc/pid/status中threads記錄全部到達(dá)上限：Threads: 500
2. 崩潰時日志信息與圖[3-6]基本一致

推斷驗(yàn)證成功，即線程數(shù)受限導(dǎo)致創(chuàng)建線程時clone failed導(dǎo)致了線上的OOM二灯抛。

OOM二的定位與解決：
?關(guān)于App業(yè)務(wù)代碼中的問題還在定位修復(fù)中

3.4 解釋

下面從代碼分析本文描述的OOM是怎么發(fā)生的金赦，首先線程創(chuàng)建的簡易版流程圖如下所示：

圖3-8 線程創(chuàng)建流程

上圖中，線程創(chuàng)建大概有兩個關(guān)鍵的步驟：

• 第一列中的創(chuàng)建線程私有的結(jié)構(gòu)體JNIENV(JNI執(zhí)行環(huán)境对嚼，用于C層調(diào)用Java層代碼)
• 第二列中的調(diào)用posix C庫的函數(shù)pthread_create進(jìn)行線程創(chuàng)建工作

下面對流程圖中關(guān)鍵節(jié)點(diǎn)（圖中有標(biāo)號的）進(jìn)行說明：

1. 圖中節(jié)點(diǎn)①夹抗， /art/runtime/thread.cc中的函數(shù)Thread:CreateNativeThread部分節(jié)選代碼如下：

    std::string msg(child_jni_env_ext.get() == nullptr ?
        "Could not allocate JNI Env" :
        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());

????????圖3-9 Thread:CreateNativeThread節(jié)選
可知：

• JNIENV創(chuàng)建不成功時產(chǎn)生OOM的錯誤信息為"Could not allocate JNI Env"，與文中OOM一一致
• pthread_create失敗時拋出OOM的錯誤信息為"pthread_create (%s stack) failed: %s"．其中詳細(xì)的錯誤信息由pthread_create的返回值（錯誤碼）給出．錯誤碼與錯誤描述的對應(yīng)關(guān)系可以參見bionic/libc/include/sys/_errdefs.h中的定義．文中OOM二的具體錯誤信息為"Out of memory"纵竖，就說明pthread_create的返回值為12.

...
__BIONIC_ERRDEF( EAGAIN         ,  11, "Try again" )
__BIONIC_ERRDEF( ENOMEM         ,  12, "Out of memory" )
...
__BIONIC_ERRDEF( EMFILE         ,  24, "Too many open files" )
...

????????圖3-10 系統(tǒng)錯誤定義_errdefs.h

2. 圖中節(jié)點(diǎn)②和③是創(chuàng)建JNIENV過程的關(guān)鍵節(jié)點(diǎn)漠烧，節(jié)點(diǎn)②/art/runtime/mem_map.cc中函數(shù)MemMap:MapAnonymous的作用是為JNIENV結(jié)構(gòu)體中Indirect_Reference_table（C層用于存儲JNI局部/全局變量）申請內(nèi)存，申請內(nèi)存的方法是節(jié)點(diǎn)③所示的函數(shù)ashmem_create_region（創(chuàng)建一塊ashmen匿名共享內(nèi)存,并返回一個文件描述符）．節(jié)點(diǎn)②代碼節(jié)選如下：

  if (fd.get() == -1) {
      *error_msg = StringPrintf("ashmem_create_region failed for '%s': %s", name, strerror(errno));
      return nullptr;
  }

????????圖3-11　MemMap:MapAnonymous節(jié)選
?我們線上的OOM一的錯誤信息＂ashmem_create_region failed for 'indirect ref table': Too many open files＂靡砌，與此處打印的信息吻合．＂Too many open files＂的錯誤描述說明此處的errno（系統(tǒng)全局錯誤標(biāo)識）為24(見圖[3-10]系統(tǒng)錯誤定義_errdefs.h)．
?由此看出我們線上的OOM一是由于文件描述符數(shù)目已滿已脓，ashmem_create_region無法返回新的FD而導(dǎo)致的．

3. 圖中節(jié)點(diǎn)④和⑤是調(diào)用C庫創(chuàng)建線程時的環(huán)節(jié)，創(chuàng)建線程首先調(diào)用__allocate_thread函數(shù)申請線程私有的棧內(nèi)存(stack)等通殃，然后調(diào)用clone方法進(jìn)行線程創(chuàng)建．申請stack采用的時mmap的方式度液，節(jié)點(diǎn)⑤代碼節(jié)選如下：

  if (space == MAP_FAILED) {
    __libc_format_log(ANDROID_LOG_WARN,
                      "libc",
                      "pthread_create failed: couldn't allocate %zu-bytes mapped space: %s",
                      mmap_size, strerror(errno));
    return NULL;
  }

????????圖3-12 __create_thread_mapped_space節(jié)選
?打印的錯誤信息與圖[3-7]中進(jìn)程邏輯地址占滿導(dǎo)致的OOM錯誤信息吻合，圖[3-7]中錯誤信息＂ Try again＂說明系統(tǒng)全局錯誤標(biāo)識errno為11(見圖[3-10]系統(tǒng)錯誤定義_errdefs.h).
?pthread_create過程中画舌，節(jié)點(diǎn)４相關(guān)代碼如下：

 int rc = clone(__pthread_start, child_stack, flags, thread, &(thread->tid), tls, &(thread->tid));
  if (rc == -1) {
    int clone_errno = errno;
    // We don't have to unlock the mutex at all because clone(2) failed so there's no child waiting to
    // be unblocked, but we're about to unmap the memory the mutex is stored in, so this serves as a
    // reminder that you can't rewrite this function to use a ScopedPthreadMutexLocker.
    pthread_mutex_unlock(&thread->startup_handshake_mutex);
    if (thread->mmap_size != 0) {
      munmap(thread->attr.stack_base, thread->mmap_size);
    }
    __libc_format_log(ANDROID_LOG_WARN, "libc", "pthread_create failed: clone failed: %s", strerror(errno));
    return clone_errno;
  }

????????圖3-13 pthread_create節(jié)選
?此處輸出的錯誤日志"pthread_create failed: clone failed: %s"與我們線上發(fā)現(xiàn)的OOM二吻合恨诱，圖[3-6]中的錯誤描述＂ Out of memory＂說明系統(tǒng)全局錯誤標(biāo)識errno為12(見圖[3-10]系統(tǒng)錯誤定義_errdefs.h).
?由此線上的OOM二就是由于線程數(shù)的限制而在節(jié)點(diǎn)5 clone失敗導(dǎo)致OOM.

四. 結(jié)論及監(jiān)控

4.1 導(dǎo)致OOM發(fā)生的原因

綜上，可以導(dǎo)致OOM的原因有以下幾種：

1. 文件描述符(fd)數(shù)目超限骗炉，即proc/pid/fd下文件數(shù)目突破/proc/pid/limits中的限制照宝。可能的發(fā)生場景有：
   短時間內(nèi)大量請求導(dǎo)致socket的fd數(shù)激增句葵，大量（重復(fù)）打開文件等
2. 線程數(shù)超限厕鹃，即proc/pid/status中記錄的線程數(shù)（threads項(xiàng)）突破/proc/sys/kernel/threads-max中規(guī)定的最大線程數(shù)≌д桑可能的發(fā)生場景有：
   app內(nèi)多線程使用不合理剂碴，如多個不共享線程池的OKhttpclient等等
3. 傳統(tǒng)的java堆內(nèi)存超限，即申請堆內(nèi)存大小超過了 Runtime.getRuntime().maxMemory()
4. （低概率）32為系統(tǒng)進(jìn)程邏輯空間被占滿導(dǎo)致OOM.
5. 其他

4.2 監(jiān)控措施

可以利用linux的inotify機(jī)制進(jìn)行監(jiān)控:

• watch /proc/pid/fd來監(jiān)控app打開文件的情況,
• watch /proc/pid/task來監(jiān)控線程使用情況．

五. Demo

POC(Proof of concept) 代碼參見：https://github.com/piece-the-world/OOMDemo