通过ANR的堆栈分析，ANR的堆栈都是停在了linklist的contains()函数。通过源码分析，系统提供的linklist类是通过链表的方式实现的。按说应该不会有性能问题，即使一个初级程序员来实现，查询几万条记录的耗时最多也就是几十毫秒。作为Android平台的工具类，性能应该更是顶呱呱。同事通过log日志发现，系统的linklist在1000条记录情况下查询耗时在10毫秒内。自己的手机也没能复现ANR问题。
下面进入分析阶段：
由于bugly的日志上报了App所有多线程堆栈情况（这点很赞），通过堆栈分析，出问题时候，主线程和子线程都在操作linklist，并且为了线程安全，业务对所有linklist操作都增加了synchronized锁。通过多个bugly上报的规律来看，子线程和主线程也都卡在了linklist的操作上。
梳理已知信息：
1、子线程和主线程都卡在了linklist上。
2、子线程和主线程同时进入了不同方法的synchronized内。
分析：
由第一条现象可以尝试的方向是linklist是否存储的内容特别多，由于内容超多导致linklist操作耗时超长。（通过代码分析，linklist内容会定期写文件且对内容不排重，很有可能造成这种情况）
由第二条现象可以尝试的方向是单例里持有的linklist的多个同步方法（synchronized），被子线程和主线程同时执行，是否和单例创建的安全性有关。（即创建了两个单例）
追问：
为什么主线程和子线程都卡在了linklist操作上，这么巧？
原因是linklist耗时超长，所以主线程和子线程同时卡在linklist操作的概率就特别大。
