Looper.loop()引发的惨案

开发者全社区

共 7205字,需浏览 15分钟

 ·

2020-09-17 17:33

热文推荐:

作者:不怕天黑

来源:https://juejin.im/post/6859156343228792840



案件描述


在一个安静的下午,一妹子在RxHttp群里反馈,自己开发的app,账号被挤下线时,重新登录到首页后,发现有一个请求,代码执行了,却没有任何回调,看得出,妹子很着急。

what ??? 还有这种事?原本安静的群,一下活跃了起来,男同胞们一顿狂猜,我总结了下,如下:

  • 会不会请求代码没执行,妹子自己搞错了吧?

  • 发请求前,出现异常,代码被中断运行?

  • 请求过程伴随着页面跳转,导致页面销毁时,请求被自动关闭?

  • 请求过程出现异常,被RxJava全局异常捕获了,并吃掉了,所以收不到失败回调?

这里解释下,妹子采用RxHttp+RxJava结合的方式发请求

经过第一轮询问后,以上猜想轻而易举的被推翻了,我也大概知道了案件的细节,为此,我用代码来还原一下,为简化案件,还原时,我会适当的做出修改,但意思还是那个意思。


案件还原


妹子在首页MainActivityOnCreate方法,会并行3个请求,如下:

@Overrideprotected void onCreate(Bundle savedInstanceState) {    super.onCreate(savedInstanceState);    setContentView(R.layout.main_activity);    request1();    request2();    request3();}       public void request1() {    RxHttp.get("/service/...")        .asString()        .to(RxLife.toMain(this))          .subscribe(s -> {}, throwable -> {           });                                                            }
public void request2() { }
public void request3() {}

这段代码看起来并没有任何问题,正常登录进来后,都是正常的。

但是当账号被挤下线后(挤到登录页),重新登录到首页后,发现request1()、request2()、request3()三个请求方法都执行了,可request2()方法却迟迟收不到回调,不管成功/失败都收不到。


开始办案


以上猜想全部被推翻,接下来怎么办?很明显,我们要明确一点:

请求到底有没有发出去?服务端有没有收到这个请求?

随后,妹子用Adnroid Studio自带的Profiler工具,监控了下,发现请求并未发出来,接着,又找后台人员确认了下,后台也并未收到这个请求。

那就更奇怪了,请求代码执行了,请求却没有发出去?作为程序员的我第一反应,这怎么可能呢?妹子你用的手机有问题吧?要不换个手机试试?显然换了手机,问题一样存在,这就尴尬了。

接下来,跟妹子不断的调试,一而再,再而三的确认了,请求代码没有任何问题,然而,我却陷入了沉思之中,很绝望,很无助,甚至怀疑这是OkHttp的问题。

作为一名老鸟,最后我还是冷静了下来,重新整理了线索,发现又一条线索被遗漏了,那就是账号被挤,自动跳转到登录页面,为什么只有在账号被挤时,才会出现问题?于是乎,我调整了调查方向

  • 账号是如何被挤?又是如何跳转到登录页面的?

终于,凶手露出了水面,凶手就是Looper,原来妹子是通过OkHttp的拦截器来监听账号被挤,并通过Looper来弹出一个Toast提示,并且执行页面跳转逻辑,如下:

public class TokenInterceptor implements Interceptor {        private Context context;        
@Override public Response intercept(Chain chain) throws IOException { Request request = chain.request(); Response originalResponse = chain.proceed(request); String code = originalResponse.header("code"); if ("-1".equals(code)) { Looper.prepare(); Toast.makeText(context, "你的账号在其它设备上登录", Toast.LENGTH_LONG).show(); context.startActivity(new Intent(context, LoginActivity.class)); Looper.loop(); } return originalResponse; }}

也许你会问,这确定有问题?通过Looper在子线程弹出一个Toast,这不是很正常的一件事?经常这么干,从来没出现任何问题,为啥到你这就出问题?

我让妹子把Looper及Toast代码注释掉,if语句里面只保留一行startActivity,妹子试后开心的跟我说,好了,没问题了,这怎么解释?


开始破案


Looper一脸委屈的说道:你说我是凶手,我就是凶手了,证据呢?

ok,我们就来寻找证据,我们知道,Looper.loop()方法内部,会开启一个死循环,如下:

 public static void loop() {          for (;;) {                                                                  Message msg = queue.next();          if (msg == null) {                                                                     return;                                                             }              }      }

可以看到,queue.next()这行代码官方注释了,有可能会被堵塞,什么时候会堵塞?没有消息的时候,可见,调用Looper.loop()方法所在的线程会进入死循环。

那这个和我们的案件有什么关系呢?

这就要来说说RxJava的线程池了,上面TokenInterceptor回调所在的线程是RxJavaIO线程,而RxJavaIO线程池的配置,却仅允许一条核心线程执行任务,当任务在执行,其它任务过来时,必须等待至上一个任务结束。

IoScheduler类中可以找到静态内部类ThreadWorkerThreadWorker继承至NewThreadWorker,在该类中,我们可以找到线程池对象,如下:

public class NewThreadWorker extends Scheduler.Worker implements Disposable {    private final ScheduledExecutorService executor;
public NewThreadWorker(ThreadFactory threadFactory) { executor = SchedulerPoolFactory.create(threadFactory); } }

SchedulerPoolFactory.create方法点进去看看

public static ScheduledExecutorService create(ThreadFactory factory) {    final ScheduledExecutorService exec = Executors.newScheduledThreadPool(1, factory);          return exec;}

可以看到,这里传了个1,就是核心线程的数量,继续往下看,最终找到了创建线程池对象代码,如下:

public ScheduledThreadPoolExecutor(int corePoolSize,                                                ThreadFactory threadFactory) {    super(corePoolSize, Integer.MAX_VALUE,                                 DEFAULT_KEEPALIVE_MILLIS, MILLISECONDS,                          new DelayedWorkQueue(), threadFactory);                }

这里简单解读一下,该线程池核心线程数量为1,非核心线程数量无上限,非核心线程闲置时间超过10毫秒便会被回收,并使用了延迟队列。

注意注意,前方高能预警

用简单的话来说,该线程池,同一时间,仅会执行一个任务,也就是串行,这也就解释Looper与本案的关系,因为Looper.loop()所在线程进入死循环,该线程所在线程池收到其它任务时,便必须得等待至上一个任务执行完毕,然而上一个任务在死循环,所以下一个任务永远得不到执行,这也就是为什么请求代码执行了,请求却没发出去原因。


其它思考


到这,估计很多人会有疑问

  • RxJavaIo线程池,是串行执行的,那么它又是如何做到并行的呢?难道以前写的并行代码,其实都是串行实现的?

  • 线程池已经有任务在执行了,为啥还会拿到该线程池执行新的任务呢?

  • RxJava为啥不使用OkHttp内部的线程池配置,只要有任务来,都开启非核心线程去执行?

ok,接下来一一解答

首先,第一个,RxJava如何根据目前的Io线程池,做到并行任务?

其实很简单,在IoScheduler的静态内部类CachedWorkerPool中,维护了一个线程池队列,每次收到新任务,都会从队列里面取出一个线程池去执行任务,如果没有,则创建一个新的线程池,如下:

static final class CachedWorkerPool implements Runnable {        private final ConcurrentLinkedQueue expiringWorkerQueue    final CompositeDisposable allWorkers;                                 private final ThreadFactory threadFactory;                            ThreadWorker get() {                                                      if (allWorkers.isDisposed()) {                                            return SHUTDOWN_THREAD_WORKER;                                    }                                                                     while (!expiringWorkerQueue.isEmpty()) {                                  ThreadWorker threadWorker = expiringWorkerQueue.poll();               if (threadWorker != null) {                                               return threadWorker;              }                                                                 }                                                                                                                                                   ThreadWorker w = new ThreadWorker(threadFactory);                     allWorkers.add(w);                                                    return w;                                                         }        void release(ThreadWorker threadWorker) {                                     threadWorker.setExpirationTime(now() + keepAliveTime);                                                                              expiringWorkerQueue.offer(threadWorker);                      }                                                                 }

通过多个线程池,就达到了并行的效果;上面代码release方法中,我们注意到,被回收的线程池,存活时间为60s,在CachedWorkerPool 构造方法中,会开启一个定时任务,每间隔60s,就会去检查线程池队列,如果线程池闲置超过60s,便会将线程池关闭,并从队列中移除。

接着,回答第二个问题,线程池已经有任务在执行了,为啥还会拿到该线程池执行新的任务?

看了上面的代码,其实就很好回答了,回收线程池有两个条件会触发,一是任务正常执行完毕,这个好理解,不做解释,另外一个就是,任务被取消,比如,调用Disposable#isDisposed()方法取消任务,但是该方法不会取消线程池里的任务,这就导致了,线程池虽然被回收了,但线程池里的任务依然在执行,所以下次拿到该线程池的任务,只能等待。

最后,就是RxJava为何要如此设计线程池?

原因很简单,防止线程资源被浪费,如上面说到的,线程池虽然被回收了,但里面的线程却依然在执行任务,这样的线程多了,无疑是一种浪费,怎么办?依靠定时器,让被回收的线程池在一定时间后,关闭任务,并从队列中移除。而如果直接通过线程池去回收线程,那么被Looper.loop() 的线程,进入死循环后,将永远得不到回收。

到这,我也丢个问题给大家,RxJava在将线程池丢进缓存队列时,为啥不将线程池关闭掉?欢迎评论群留言讨论


总结


回顾下案件,从妹子反馈的问题,账号被挤,重新登录到首页后,request2()方法内的请求代码执行了,却收不到回调,线程池的原因请求压没有得到执行,故收不到回调,那为啥就request2()方法会出问题呢?其实这是一种假象,只要被回收的线程池里还有未完成的任务,那么该线程池再次执行请求,都必须得等待。如果账号在60s内重复被挤3次,那么登录到首页后,3个请求都将得不到执行,因为回收池得3个线程池都不能再执行任务了,直到60s后,被计时器强制关闭并移除。

最后,提醒大家,一定要慎用Looper,不是任何时候都适合用Looper的,像妹子遇到的这种场景,完全可以用主线程的Handler post一个消息出去,然后处理业务,亦或者通过EventBus、LiveData等发送消息到主线程,再处理相关逻辑。


如有收获,欢迎分享 

「点赞「评论 

看完本文有收获?请转发分享给更多人

  开发者全社区 

5T技术资源大放送!包括但不限于:Android,Python,Java,大数据,人工智能,AI等等。关注公众号后回复「2T」,即可免费获取!
浏览 17
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报