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。