【转载】【Android】如何快速分析fd leaks, 文件句柄泄露.

https://blog.csdn.net/xiaolli/article/details/56012228
一篇老文章了，总结的不错。

如何快速分析fd leaks, 文件句柄泄露.
[Keyword]
FD leaks, File Description Leaks, Too many open files, error 24

[Solution]
android 默认每一个进程最多能够打开的文件数量为1024, 一旦达到预置，则会爆错 error=24, 即Too many open files.

通常的分析手法如下：

(1). 确定是哪类文件打开太多，没有关闭.
   *  fd leaks, 通常伴随着此进程会出现Java Exception, Native Exception 等. 在mtk 的AEE DB 中, 有一支文件 PROCESS_FILE_STATE 描述, 此进程的打开的所有文件.
查看此文件, 确定哪个或者哪种文件打开数量最多，即追查此类文件打开如此多, 而没有被关闭的原因.
    
   *  如果没有DB, 当发生文件句柄泄露到1024 时, 在L 版本后, 在Kernel Log 中search "FDLEAK",   在L 版本之前, 在Kernel Log 中search "FS_TAG", 即可枚举出所有的此进程所打开的文件.
    
   *  如果问题容易复现，可以直接 adb shell ls -a -l /proc/pid/fd , 直接打印出当前此process 所有打开的文件.
    
(2). 确定此类文件是在哪里打开.
    ①对于一些确定的文件, 比如/data/data/xxxx_app/yyyy 之类的文件, 通常开发者自己可以快速的确定打开文件的位置，基本上不需要debug.
    对于一些另外一些常见的场景说明如下：
    ②* 大批量的打开“anon_inode:[eventpoll]” 和 "pipe",  超过100个eventpoll, 通常情况下是开启了太多的HandlerThread/Looper/MessageQueue, 线程忘记关闭, 或者looper 没有释放. 可以抓取hprof 进行快速分析. 抓取hprof 可以参考FAQ:
         http://online.mediatek.com/Pages/FAQ.aspx?List=SW&FAQID=FAQ08893
    ③* 对于system server, 如果有大批量的socket 打开, 可能是因为Input Channel 没有关闭, 此类同样抓取hprof, 查看system server 中WindowState 的情况.
    ④* 大批量的打开“/dev/ashmem”, 如果是Context provider, 或者其他app, 很可能是打开数据库没有关闭, 或者数据库链接频繁打开忘记关闭.
    
(3). 暴力确定文件打开的位置
    MTK 有开发了fd leaks debug 功能，可以记录每次打开fd 的backtrace, 可以参考FAQ：   http://online.mediatek.com/Pages/FAQ.aspx?List=SW&FAQID=FAQ11422

----这个可惜看不到。。现在正好也在做一个类似的维测功能。
    
(4). 修正
    确认为何要频繁打开, 或者为何打开后忘记关闭, ^_^,  然后更新.