背景：

实现强占式camera service，当某些应用（如手电筒）在后台打开camera后，当cameraapp open camera时可以强占被后台应用占有的camera.

注意，由于这样修改破坏了android原生的camera service规则，有可能导致某些三方apk出现异常

问题：概率性死锁

分析：

关闭：JNI--》CameraClient::disconnect(){......  :

    Mutex::Autolock lock(mLock);获取lock：mLock---->属于某camera应用：A进程空间。

   CameraService::Client::disconnect();---》要去关闭server端的client

//尚未退出所以mlock不会被释放

}

voidCameraService::removeClientByRemote(const wp<IBinder>& remoteBinder){

    int callingPid = getCallingPid();

   LOG1("CameraService::removeClientByRemote E (pid %d)",callingPid);

    // Declare this before the lock to makeabsolutely sure the

    // destructor won't be called with the lockheld.

    Mutex::Autolocklock(mServiceLock);----//获取lock：mServiceLock ---->属于某camera应用进程空间。

打开：android_hardware_Camera_native_setup（）---》        Camera::connect----》binder ----》mediaserver进程----》CameraService::connect（）{

....

Mutex::Autolocklock(mServiceLock);//获取lock：mServiceLock ---->属于mediaserver进程空间。

....

}---》        canConnectUnsafe（）

{

....

client->disconnect();----->调用CameraClient::disconnect(){Mutex::Autolocklock(mLock);}//同样也会获取lock：mLock ---->属于mediaserver应用进程空间。

小结：对于mLock与mServiceLock，也就是说关闭过程，它们属于应用进程空间。打开过程，它们属于mediaserver进程。因此，mLock 与mServiceLock 有可能死锁。

      比如：A进程在关闭camera的过程，跑到CameraService::removeClientByRemote()尝试获取lock：mServiceLock，但是进程B先运行了，且尝试去打开camera，就会跑到mediaserver进程也获取lock：mServiceLock。也就是mediaserver进程先获取了mServiceLock，再尝试去获取mLock，但是A进程先获得了mLock。