In prosperity our friends know us; in adversity we know our friends.
得意时，朋友识我；失意时，我识朋友。
请问下面这段代码会发生ANR吗？
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
new Thread(new Runnable() {
@Override
public void run() {
testANR();
}
}).start();
SystemClock.sleep(10);
initView();
}
private synchronized void testANR() {
SystemClock.sleep(30 * 1000);
}
private synchronized void initView() {
}
你的答案是什么？上面的代码的确会发生ANR的哦！
本篇的标题虽然是synchronized锁与ANR，但是实际上ANR只是一个用来迷惑我们的烟雾弹而已，上面代码片段真正的坑是synchronized锁。这段代码是我的一个朋友发来问我的（也不知从哪里搞的代码）。
android的小伙伴对 ANR肯定是非常的熟悉。诺，就是那个丑陋的对话框，感受到寒意没有？咳咳，我扫了一眼代码。工作线程阻塞30s，主线程阻塞5ms，是不会触发出发ANR，于是自信的告诉他上面那段代码是不会发生ANR。但现实往往与理想是偏离的，实际上上面的代码是会发生ANR的，翻车了
回头再仔细一看原来是你synchronized。
synchronized是java中一个关键字，是一种同步锁。按关键字修饰的位置分有下面三种：
//修饰方法
private synchronized void initView() {}
//修饰静态方法
private synchronized static void initView() {}
//修饰代码块
private void initView() {
synchronized (obj) {
//do something
}
}
当一个线程执行被synchronized修饰的代码块或方法时，这段synchronized代码的锁对象就会被占用，直到执行完成synchronized修饰的代码后才会释放掉锁对象。如果某个线程执行的synchronized代码对应的锁对象正在被占用时，那么该线程将会被阻塞直到对应的锁对象被释放后。
打个比方，synchronized是一种锁，锁对象就可以理解成一把钥匙，将线程比作成一个开宝箱的人，那么上面描述的过程可以理解成以下的场景：一个人开宝箱（执行某个synchronized修饰的代码）时需要对应的钥匙（锁对象），特殊的是从开启宝箱到关闭宝箱整个过程钥匙都不能离开宝箱。当有人开宝箱时发现对应的钥匙有人正在使用时，那么他只能老老实实的等待别人使用结束后，再去竞争这把钥匙的使用权。
如上面所说synchronized锁对象就像钥匙一样的东西，那锁对象是如何确定的呢？前面synchronized修饰代码块的代码中传入了一个obj对象就是我们制定的锁对象，obj可以是任意Object实例。
private void initView() {
//将obj作为锁对象（钥匙）
synchronized (obj) {
//do something
}
}
修饰方法是锁对象默认为该方法所在类的实例，也就是默认为this。
修饰静态方法是锁对象默认为方法所在类的.Class对象。
不难看出因为修饰静态方法时锁对象是.Class，导致该类对应的所有实例都会竞争该锁。修饰方法时竞争的只是某一个实例。修饰代码块是因传入的obj不同竞争的情况也就不一样了。
最后再去看最初的那个问题，在onCreate方法中开启工作线程，主线程同时睡眠5ms，此时工作线程执行testANR获取锁对象this，并开始睡眠30s。主线程睡眠5ms结束后开始执行initView，不过此时锁对象this被占用着，主线程只能阻塞等待锁对象的释放，于是主线程被阻塞30S产生ANR。
