2.android中使用锁来兼容netty客户端的写法

博客概述

在android项目开发中往往遇到多线程之间协作的场景，控制启动，控制暂停，传递参数等都是非常常见的。例如在一个activity中使用handler在主线程和子线程之间通讯。本博客要讲的是一个实战操作。场景如下，android机在与外部蓝牙设备连接成功后，会发起socket连接，socket连接是用netty实现的。因为netty客户端的惯有写法会导致在子线程中执行的socket连接不能直接获得响应，该响应决定了接下来在子线程中一些业务逻辑的执行。对于这种场景，我考虑了一种基于锁的解决方案。

具体方案

问题背景

该方法，姑且称之为LoginBiz()，触发该方法的service有2个，极端情况下可能发生并发。这是一个需要解决的问题A，然后如何灵活的获得netty监听器获得到的来自远程的数据，继续执行LoginBiz的后续方法是问题B。LoginBiz因为设计的关系不属于任何的android组件。

解决方案

解决并发问题

首先将Biz方法所在的类进行单例，单例手段不限制。然后在loginBiz方法里面，使用细粒度的重入锁，该重入锁的具体对象在类被创建时初始化。使用try-finally的最佳实践，在try方法块里面上锁，后面是具体的业务流程，finally里面解锁。这样就通过单例+重入锁的形式，保证了多终端情况下的并发问题。相当于强制串行化，但是android工控机根本不需要处理这种并发。

解决netty客户端接受消息的线程协作问题。

这个方案个人感觉解决的不是最好的。声明一个全局的静态多线程可见的变量，称之为user。当LoginBiz里面通过netty客户端发出message之后，马上调用闭锁CountDownLatch的await方法。需要注意的是，这个闭锁在LoginBiz被调用时被创建，参数为1，类型为公共的静态。这样的话，接下来的业务逻辑就会阻塞在这，因为是子线程调用BIZ，所以不用担心ANR问题。
当netty当监听器收到来自服务端当回应的时候，执行完业务逻辑，简单的理解为设置好了全局静态变量User的值，调用CountDownLatch的countdown方法，这样，阻塞在service中子线程里的loginBiz方法就会继续往下执行，从而完成这个业务逻辑。

总结

技术是死的，活学活用才是硬道理！